SPI communication of ISM330DLC with microcontroller fails

[Ponmani]

SPI communication of ISM330DLC with microcontroller fails rarely and randomly. Most of the time, it is observed when it is on a vibrating source. Could you pls give us some idea to know more about this issue and solving it.

[TDK]

Sounds like noise could be affecting the signals. How are the chips connected? Perhaps try a slower clock speed an/dor use LVDS signaling if there is significant distance between the two chips. Better shielding may also help.

[Andrew Neil]

More details needed about your setup, environment, etc.

What, exactly, is the nature of the "failures" ?

---

@Ponmani wrote:

Most of the time, it is observed when it is on a vibrating source. .

---

Loose connections?

---

@Ponmani wrote:

 Could you pls give us some idea to know more about this issue and solving it.

---

So what testing/debugging/investigations have you done so far?

Add diagnostics - eg, UART output - to give insights into what is going on ...

[Andrew Neil]

---

@TDK wrote:

 if there is significant distance between the two chips. 

---

@Ponmani remember that SPI is not designed for going over significant distances - it's designed for comms between chips on a single PCB.

[Ponmani]

Thanks for the response. We have proper shielding with metal conduits for the SPI lines. I doubt if it can be noise, because, if the failure happens it continuously fails for 2 to 3 hours. Then, it auto- fixes itself.

[Ponmani]

This is observed when installed on a remote place, (where i dont have the ability to scope the signals). It behaved very well in the lab environment.

No loose connections expected as the device is perfectly sealed

[Ponmani]

Will try a slower clock

[Andrew Neil]

@Ponmani wrote:

We have proper shielding with metal conduits for the SPI lines. I doubt if it can be noise, because, if the failure happens it continuously fails for 2 to 3 hours. Then, it auto- fixes itself.

---

How long are these SPI lines? Again, SPI is not designed for going over significant distances

@Ponmani wrote:

I doubt if it can be noise, because, if the failure happens it continuously fails for 2 to 3 hours. Then, it auto- fixes itself.

---

I don't think that follows.

@Ponmani wrote:

This is observed when installed on a remote place, (where i dont have the ability to scope the signals)

---

So what about UART logging? Or logging to RAM?

@Ponmani wrote:

It behaved very well in the lab environment

---

Well, of course it did - in the nice, clean sanitised conditions of a lab!

Did you do any "stress" testing?

Test at extremes of voltage, temperature, etc?

Test resilience against disruption of comms?

etc, etc, ...

[TDK]

Suppose master/slave become out of sync by 1 bit due to noise. How are you synchronizing data between master and slave? Examining the data and looking for bit shifts would be my first option.

Really feels like a noise issue.

[Andrew Neil]

---

@TDK wrote:

Really feels like a noise issue.

---

Indeed it does.

Words like "fails rarely and randomly" and "behaved very well in the lab environment" point that way ...