It took me whole yesterday of pain to get into using I2C Debugger as slave device in Proteus v7.9.
Situation: My uC communicates using I2C with periphery (slave device) I don't have model of. I connected I2C Debugger which is able to act as slave device and response to master requests. There is a couple of bugs in Proteus 7.9 (and older versions) I2C Debugger.
If you want the I2C Debugger in ISIS to act as a slave, you must fill the 'Address byte 1' field. Here is the first bug. The program expect 1 Byte hexadecimal value, but the form accepts only decimal number between 1 and 255. But the program interprets the decimal number incorrectly. The walk around this error is to left 'Address byte 1' empty and enter parameter in 'Other Properties' window:
Where 'EE' is 7 bit address of the I2C slave device you want the I2C Debugger to simulate (LSB in the Byte is ignored, notice the format without 0x or xxh). When you click on the 'OK' button, ISIS "consumes" the property and fill it in the form field. But when you open the form window again, there is 'EE' in editbox 'Address byte 1' and ISIS doesn't let you confirm the dialog again. So you have again to delete 'EE' from 'Address byte 1' and write the property to 'Other Properties' window. That's the reason for 'ADDRESS3' property. You can just make a copy of this property and correct nr. 3 to nr. 1.
Start the simulation and check a log if the address of I2C debbuger is correct. Now, you can write the slave responses in the 'Queued Sequences' window. Every time, the master expects a response, I2C debugger send a signal from the queue. Look in the attached screenshot. On the third line you can see actual communication of uC with the I2C debbuger. Queued sequence is 'A 0xA1 0xA2'. So the communication step-by-step:
- master starts the communication by sending 'S' bit and writes the address of slave device with LSB bit set to 1 -> reading ('EF' in this example).
- slave device (I2C debugger) recognizes its address ('EE' or 'EF' - only first 7 MSB are used for the address) and sends acknowledge 'A',
- slave sends Byte '0xA1',
- master sends acknowledge 'A',
- slave sends second Byte '0xA2',
- master is satisfied so sends not acknowledge 'N' and stops the communication 'P'.
You can prepare the slave responses for the I2C debugger in text file and fill the name of the file in the parameter 'Sequence File' in 'Advanced Properties'. But be aware of another dangerous bug! The file is read when and only when you open the design. If you make the simulation and change the text file with new responses and start the simulation again, ISIS overwrites your file with old version. Thus, every time you change your text file, you have to close and reopen your design. If you won't, ISIS overwrites your text file with a last used version.
Yes, and a parameter 'Queue stored sequences at startup' is ignored if you read the sequences from a file.
Otherwise the I2C Debugger is GREAT tool and I love this software very much!
Situation: My uC communicates using I2C with periphery (slave device) I don't have model of. I connected I2C Debugger which is able to act as slave device and response to master requests. There is a couple of bugs in Proteus 7.9 (and older versions) I2C Debugger.
If you want the I2C Debugger in ISIS to act as a slave, you must fill the 'Address byte 1' field. Here is the first bug. The program expect 1 Byte hexadecimal value, but the form accepts only decimal number between 1 and 255. But the program interprets the decimal number incorrectly. The walk around this error is to left 'Address byte 1' empty and enter parameter in 'Other Properties' window:
Rich (BB code):
{ADDRESS1=EE}
{ADDRESS3=EE}Start the simulation and check a log if the address of I2C debbuger is correct. Now, you can write the slave responses in the 'Queued Sequences' window. Every time, the master expects a response, I2C debugger send a signal from the queue. Look in the attached screenshot. On the third line you can see actual communication of uC with the I2C debbuger. Queued sequence is 'A 0xA1 0xA2'. So the communication step-by-step:
- master starts the communication by sending 'S' bit and writes the address of slave device with LSB bit set to 1 -> reading ('EF' in this example).
- slave device (I2C debugger) recognizes its address ('EE' or 'EF' - only first 7 MSB are used for the address) and sends acknowledge 'A',
- slave sends Byte '0xA1',
- master sends acknowledge 'A',
- slave sends second Byte '0xA2',
- master is satisfied so sends not acknowledge 'N' and stops the communication 'P'.
You can prepare the slave responses for the I2C debugger in text file and fill the name of the file in the parameter 'Sequence File' in 'Advanced Properties'. But be aware of another dangerous bug! The file is read when and only when you open the design. If you make the simulation and change the text file with new responses and start the simulation again, ISIS overwrites your file with old version. Thus, every time you change your text file, you have to close and reopen your design. If you won't, ISIS overwrites your text file with a last used version.
Yes, and a parameter 'Queue stored sequences at startup' is ignored if you read the sequences from a file.
Otherwise the I2C Debugger is GREAT tool and I love this software very much!
