How to resolve SPI/I2C conflict in H3LIS100DL/IIS2DLP - shared bus with external flash?

[cphelan]

Greetings. I am sharing a SPI bus between a H3LIS100DL, a IIS2DLP and an external flash chip. When communicating with external flash, I get corrupted bytes after certain byte sequences. I’ve chased the issue down to the fact that these two accelerometers have optionally i2c and SPI communication capabilities – and this capability is enabled using the chip select line (high = i2c, low = SPI). Of course, since this is a shared bus, we need to assert the chip select line on devices we are not communicating to (via SPI) – which, in the case of these accelerometers, means they are in i2c mode. It seems that the accelerometers are misinterpreting SPI commands as i2c commands, they then respond (talking over the SDA line – which happens to also be the MOSI line), and this response corrupts the SPI data.

The specific SPI byte sequences that create the issue just so happen to align with the i2c addresses of the parts – not too surprising.

Besides moving the accelerometers to an unshared SPI bus, is there a recommended method to avoid this problem? The IIS2DLP has a register setting which disables the i2c interface – however we’ve found that this does not resolve the problem (even with the H3LIS100DL disconnected from the bus). The H3LIS100DL does not have such a register setting.

[Eleon BORLINI]

Hi @cphelan​ ,

if I well understood, all the 3 devices (H3LIS100DL, IIS2DLP and the flash memory), share the same SPI lines except from the CS, right?

I have some further questions to try to narrow down the issue.

Which VddIO and SPI clock frequency are you using? For example, is it >1MHz, so that you will be above the I2C clock speed?

That's a bit strange, since the SPI and the I2C protocols are very different. Do you have a screen of a scope with the I2C output of the device lines while communicating SPI with the flash memory?

This request in order to understand what the device are getting in output and whether this is cross talk noise or valid data.

-Eleon

[cphelan]

Yes, the H3LIS100DL, IIS2DLP and flash all share the same SPI line except for CS. We currently run SPI at a 500kHz frequency since we are running our MCU at 1MHz, however we did boost the MCU up to 2MHz and we tried SPI at 1MHz to see if that resolved the issue. It did not.

Below is a plot that demonstrates the issue – note that there is a 10k series resistor between the shared bus and each of the accelerometers (allowing us to see what is happening at the device vs. on the bus). MOSI@LG ACC is the MOSI line at the IIS2DLP and MOSI@HG ACC is the MOSI line at the H3LIS100DL. You can see that, after 0x33 is written on the shared bus, the H3LIS100DL tries to pull the bus low – however the 10k resistor is large enough that the shared bus is not affected.

Note that, in SPI mode, this additional series resistance does not impact communications with either accelerometer. So, additional series resistance may be an inexpensive solution to the problem – however the preference is to prevent the accelerometers from even listening to the MOSI line when CS is high. We’ve implemented a tri-state buffer in the meantime, which works well, but does have a parasitic current penalty.

I am open to other suggestions to resolve this - thanks!

[cphelan]

I did just test at a 4MHz spi rate using a board without any series resistance in the MOSI line - the issue persists.

[Eleon BORLINI]

Hi @cphelan​ ,

thank you for sharing the details.

You wrote:

>> So, additional series resistance may be an inexpensive solution to the problem

This might be a solution helping to shaper the signal in the right way, but could you check the parasitic on your SPI lines? What if you keep the H3LIS100DL and the IIS2DLP in power down while you are communicating with the flash memory, so that they cannot respond even if stimulated in some way?

-Eleon

[cphelan]

Thanks, we did try using the power down state, but we still have the same issue.

[Eleon BORLINI]

Hi @cphelan​ ,

did you check whether the issue is solved with additional additional series resistance?

-Eleon