cancel
Showing results for 
Search instead for 
Did you mean: 

Issues with 3 LSM6DSV16X on the same SPI bus

Nico5
Associate

Hello,

 

I am trying to interface a TI MCU with three LSM6DSV16X sensors using SPI communication on the same bus.

 

My setup consists of 3 chip select lines with a 10 kΩ pull-up resistor (on all sensor boards), POCI (MISO) with a single 10 kΩ pull-up resistor (on 1 sensor board), PICO (MOSI) and the CLOCK line with nothing, with a long distance shown on the schematic (attached file). All sensors are powered with 3.3V.

 

I am facing an issue that I can't solve. This setup seems to be unreliable, as I can't consistently read all three chips correctly.

 

My flow is as follows:

  • Configure MCU to communicate in SPI mode 3 with 1MHz frequency
  • Global reset of the device (writing 0x04 to FUNC_CFG_ACCESS)
  • Wait 100ms (more than the application note, for some reason 30ms doesn't work every time)
  • Read the WHO_AM_I register

 

For some reason, most of the time I can read 0x70 on two chips, but the third one shows different behaviors. The most frequent responses I get are 0x00, 0x60, or sometimes 0x70.

 

To address this anomaly, I have experimented with multiple things, but all seem to have the same results as before:

  • Added resistors on CLOCK, MOSI, and MISO lines, which did not work except for reducing signal noise.
  • Tried disconnecting the MISO line from the non-working sensor and directly reading the signal with an oscilloscope but got the same results.
  • Tried changing the CLOCK frequency from 1MHz to 200kHz, but this did not affect the signals.

 

I should mention that I have tested all of the chips independently, and they work perfectly even with around 2 meters of cables, using the same flow as explained above.

 

Additionally, we have used an oscilloscope to observe the signals, and all signals are correct in the sense that they are synchronized, the voltages are correct, signal noise is very low, and no misalignment could be identified. What I read on the oscilloscope from the sensor board matches what I read and send with the microcontroller.

 

Do you have any ideas of what could cause this issue and how it could be fixed?

4 REPLIES 4
Federica Bossi
ST Employee

Hi @Nico5 ,

Welcome to ST Community!

Maybe can be an interference on the communication, have you checked that no other CS are enabled when communicate with third device?

Do you check on pinout linking? Micro pin are correctly linked to pin CS, SCL, SDA also for third device?

If you wait some ms between the communication with the other 2 sensor and the third one, the response continue to be unstable?

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
AScha.3
Chief III

Hi,

first idea with your setup: hardware problem. (EMI, bad GND...etc.)

Try connecting with a screened cable, maybe a CAT5 patch cable ;

screen is GND , 8 lines : clk, miso, mosi , 3x CS , 2 x VCC (3.3V ) ; so no other gnd or vcc wires to the modules.

Maybe just 3 patch cables , one to every sensor; connected at master/cpu ; (then could be only one CS in every cable).

And to avoid ringing or reflections, dont drive the lines with (master cpu) pin-high-speed-setting or/and insert some 51...100 ohms resistors in all lines at the master.

Try...

If you feel a post has answered your question, please click "Accept as Solution".

SPI really isn't designed for long distances like this - it's intended for communication between chips on the same bord.

 

Depends...same holds for all communication lines. :)

Usually -e.g.- on serial  you have a driver/transceiver, and then the line (same for all others also).

If no transceiver , then you always have the problems : EMI/spikes coming in + producing EMI(if using unscreened lines).

btw In my experience with STM cpus the I2C is the bad guy. Never works without problems and errors.

SPI :  i have running on 50cm CAT5 cable (sceened) at 24Mbit, no problem.

If you feel a post has answered your question, please click "Accept as Solution".