I2C - two slaves - slave 1 traffic kicks slave 2 to repeat

Troubleshooting
21 
static void HAL_I2C_SoftwareReset(void)
{
    /* Disable the I2C peripheral */
    I2C_Cmd(I2C1, DISABLE);

    /* Reset all I2C registers */
    I2C_SoftwareResetCmd(I2C1, ENABLE);
    I2C_SoftwareResetCmd(I2C1, DISABLE);

    /* Enable the I2C peripheral */
    I2C_Cmd(I2C1, ENABLE);

    /* Apply I2C configuration after enabling it */
    I2C_Init(I2C1, &I2C_InitStructure);

    /* Reset I2C buffers */
    rxBufferIndex = 0;
    rxBufferLength = 0;
    txBufferIndex = 0;
    txBufferLength = 0;

    /* Reset transmitting flag */
    transmitting = 0;
}

@UMD I’ve added the clearing of the buffers and Tx flag to the SW reset routine based on v0.4.4 firmware. Please give these binaries a try:
https://dl.dropboxusercontent.com/u/41117656/system-parts_044_i2c.zip

Flashing via the local DFU-UTIL method

can be applied to offline devices locally over USB using dfu-util

  • Put the device in DFU mode (flashing yellow LED)
  • open a terminal window, change to the directory where you downloaded the files above, and run these commands:

Photon:

dfu-util -d 2b04:d006 -a 0 -s 0x8020000 -D system-part1_044_i2c.bin
dfu-util -d 2b04:d006 -a 0 -s 0x8060000:leave -D system-part2_044_i2c.bin

Then flash your app as usual. If you want to revert to v0.4.4 firmware, you can put your Photon in DFU mode and run particle update from the command line if you have the CLI installed.

22

@BDub, loaded system-part1_044_i2c.bin and system-part2_044_i2c.bin as instructed. But no change, issue still in hand, but....

@bko, @ScruffR and @BDub, guess what? My theory needs to change....

I noticed something very curious - data was output on Slave B before SendData() was called.

So, I removed the call to SendData() altogether, and now get a single set of repeating data, "HELLO", ie

HELLO [delay] HELLO [delay] HELLO [delay]

(I had changed the data string prior from "ONCE")

Conclusion: I2C Slave B is buffering the data, and is for some reason, repeating the dump of its buffer.

@BDub, no doubt given this new understanding, it changes the focus.....

Q1. Is there a low level I2C "resend" instruction or similar that could explain the Slave B resending its data?

Q2. Why does the work around fix the issue?

I understand fully that another line of investigation is

"Q3. Is there an issue with Slave B firmware/hardware?". To start on this I removed all calls to the Slave A (OLED display) and it worked fine, ie only the single output of data as expected. Can dig in further as need be.

Best wishes @UMD

23

Updated title to reflect new findings.

24

Time for the:
#can of worms sorter outer
http://www.ebay.com/bhp/usb-logic-analyzer :smile:

2 Likes
25

Am laughing! Good advice!

We do have a Digital Oscilloscope, but it’s faulty…

Good thing is that I have the magic work around in the interim.