Feed back to improve i2c simulation on a pic

[TimBox100]

Hi,

I find the VSM invaluable and greatly speeds up the development work. Occasionally I spot discrepancies in the VSM to real life. Considering how complex the CPUs you are simulating deviations from reality are inevitable. Overall the they are very few and far between (like almost zero)

I have though come across a discrepancy in the slave i2c implementation on the 16F and 18F devices I have tried it on.

The issue is that in the VSM on receiving an address and generating an interrupt says the SSPBUF buffer is empty. So if you are masking SSPSTAT to tell what state the process is in you find it you get the wrong state.
In reality the buffer does have data in it (the address maybe?) so in my code I have to have a conditional compile to correct for the discrepancy.

Thanks

Tim

[Ettore]

I hope I did understand your question, but if I did then it does not work that way to me.

You may look at the following screen shot.

Immagine 2023-03-08 143407.jpg (436.21 KiB) Viewed 967 times

On the second interrupt request (the first one is triggered by the Start of transaction) the SSPBUF is not empty but contains the address which the slave responds to, in such the case is 0x30. In such the test, SSPBUF is copied to the PORTD if Start and BF flags are both true.

The next two bytes are then transferred and in such the case are 0x2F and 0x15 in the first transaction and 0x3A and 0x2A for the second one.
If memory still serves to me (age made me a little less brilliant) I tested this one on hardware.

I attach the full test with XC8 source (I don't use Proton for such kind of test).

Test.pdsprj

(15.27 KiB) Downloaded 492 times

[TimBox100]

Hi Ettore

The issue is that SSPSTAT is not reflecting that the buffer has data in it

bit 0 BF: Buffer Full Status bit (Receive mode only)

In my code I mask the SSPSTAT reg to enable me to make a state machine

Code: Select all

    ' There can be 5 possible i2c states, SSPSTAT register relevant bits
    Symbol ci2cSTATE1 = $09          ' D_A=0,S=1,R/W=0,BF=1. Master Tx, slave addr
    Symbol ci2cSTATE2 = $29          ' D_A=1,S=1,R/W=0,BF=1. Master Tx, Data
  $ifdef SIM
    Symbol ci2cSTATE3 = $0C          ' D_A=0,S=1,R/W=1,BF=0. Master Rx, slave addr+1      $0C
  $Else
    Symbol ci2cSTATE3 = $0D          ' D_A=0,S=1,R/W=1,BF=0. Master Rx, slave addr+1      $0C
  $Endif
    Symbol ci2cSTATE4 = $2C          ' D_A=1,S=1,R/W=1,BF=0. Master Rx, Data with ACK
    Symbol ci2cSTATE5 = $28          ' D_A=1,S=1,R/W=0,BF=0. Master Rx, Data with NACK

bi2cCASE_SWITCH = SSPSTAT & %00101101

What is happening in the VSM SSPSTAT.0 is not being set on receiving the right address but in real life it is.
The code could be rewritten to ignore the bit and it would work fine, it just so happens I use it in my mask

I will try and run the example you posted and check your VSM

If need be I can make an example

[Ettore]

Hi Tim,
If you look at my test - specifically the Conformance Analysis graph above - you will see that after the first interrupt - which is because of Start condition detection enabled - there is a second interrupt on Address receiving (approx. at 300u). This is shown on SSPIF trace. In coincidence with that interrupt the BF flag is set high. You see that on BF trace. The source code then reads the SSPBUF (which has address value in) and this clears the BF flag. This is again shown on BF trace. All the sequence is that reported at the datasheet for slave mode operation.

[TimBox100]

I will make a VSM with code to show what I'm seeing

[TimBox100]

To recap

On a read following the Address the BF in SSPSTAT is not being set

Attached is a demo and the source for the files

I also show it in the images. The first one is after a i2c write and it is set and the read it is not set

When I write my code I have to add a conditional compile to account for this. In real life the Pic does set the flag.

Thanks

Tim
Just a correction on notes above I had the read and write mixed
On a write is not being set on a read it is, sorry about that!

i2c VSM Write.png (56.97 KiB) Viewed 908 times

i2c VSM Read.png (53.86 KiB) Viewed 908 times

[Ettore]

....
Tim
Just a correction on notes above I had the read and write mixed
On a write is not being set on a read it is, sorry about that!

A relatively old Microchip application note, the AN734 (DS00734B), has shed some light on this particular issue.
When PIC18 lines were introduced for the first time, the I2C protocol was the same of PIC16. This was true for PIC18C452 Family (PIC18C242/252/442/452), PIC18C458 Family (PIC18C248/258/448/458), PIC18C601/801, PIC18F4431 Family (PIC18F2331/2431/4331/4431) and PIC18F8720 Family (PIC18F6520/6620/6720/8520/8620/8720).

For such the old devices the SSPSTAT status bits were as the follows:
State 1 : S=1, D/$A=0, R/$W=0, BF=1
State 2 : S=1, D/$A=1, R/$W=0, BF=1
State 3 : S=1, D/$A=0, R/$W=1, BF=0
State 4 : S=1, D/$A=1, R/$W=1, BF=0
State 5 : S=1, D/$A=1, R/$W=0, BF=0 (logic reset by NACK from master)

The newer PIC18s - those not explicity listed above - implement a different definition of the State 3 and 5 as per the follow:
State 3 : S=1, D/$A=0, R/$W=1, BF=1 -> the BF is set after address is received and then SSPBUF needs to be read for BF being cleared.
State 5 : the R/$W bit remains set while the state machine tests the CKP bit, expecting it to be set.

However Proteus PIC18 model implements the same older protocol for all the simulated PIC18 devices, icluding the newer ones.
I agree this must be fixed. I will try to fix it for the next 8.16 service pack.

[TimBox100]

Hello Ettore


Thanks for going to the effort to find the issue. It must be really hard to develop the VSM models. When they work (99% of the time) they are a fantastic tool.

Tim