Workaround for Anomaly 198 doesn't seem to fix issue

I have a LIS2DW12 accelerometer connected to nrf52840 SPIM3, and I am seeing an intermittent failure.  In some instances while collecting accel data during a data ready interrupt, the address written to the bus is 0x0 instead of the address specified in the request.  Unfortunately, this causes the accelerometer to go into a strange state and become unresponsive.  The issue usually appears within a minute of operation. SPIM3 is configured to run at 2MHz. The accelerometer is operating at 50 Hz.  I am working with the Zephyr RTOS and nRF Connect SDK version 2.7.0.

I have enabled the workaround for anomaly198 because that issue sounds similar to my scenario, but I am still seeing the failure. Is there something more I need to do to workaround this issue, or do you think this is a different issue?  Should I avoid using SPIM3?

Parents
  • Hi,

    As you have attemted the workaround it would be interested to see if the problem could be something else. Can you stry another SPIM instance and see if the issue is resolved in that case (if you do not have any available, it would still be intersteing to free one up in order to test)?

    SPIM3 has several issues that are not present on other SPI instance, so unless you need high speed SPI (which doest not seem to be the case here), or the other peripheral instances are allready used, it makes sense to avoid using SPIM3.

Reply
  • Hi,

    As you have attemted the workaround it would be interested to see if the problem could be something else. Can you stry another SPIM instance and see if the issue is resolved in that case (if you do not have any available, it would still be intersteing to free one up in order to test)?

    SPIM3 has several issues that are not present on other SPI instance, so unless you need high speed SPI (which doest not seem to be the case here), or the other peripheral instances are allready used, it makes sense to avoid using SPIM3.

Children
Related