IIS3DWB Interrupt stops triggering while sampling for long periods

[JDoug.1]

I have been using the IIS3DWB evaluation board alongside TIs CC1352P2 uC to bring up software ahead of the actual hardware arriving. The SPI bus speed is 8MHz in mode 3.

The IIS3DWB is configured only sample accelerometer data on 3 axis and to store the values in the FIFO. The FIFO is configured to be in continuous mode with a FIFO watermark threshold configured to raise an interrupt when the threshold is exceeded.

Below is an outline of how I have configure the IIS3DWB:-

   /* We need to allow 10ms for the STIIS3DWB to come up */

   HAL_TIME_sleep( STIIS3DWB_STARTUP_TIME );

   /* Reset the software - this resets control registers to default condition */

   stiis3dwb_software_reset();

   /* Ensure Accelerometer is in powerdown mode*/

   stiis3dwb_write_config_mode ( STIIS3DWB_POWER_DOWN );

   /* Enable 3-axis mode */

   stiis3dwb_write_active_axis( STIIS3DWB_3_AXIS );

   /* Set the acceleration resolution */

   stiis3dwb_write_xl_resolution( STIIS3DWB_XL_RES_2G );

   /* Set the FIFO mode to Continuous Mode */

   stiis3dwb_write_fifo_mode( STIIS3DWB_CONTINUOUS );

   /* Set FIFO Watermark that will trigger interrupt */

   stiis3dwb_write_fifo_watermark_threshold( STIIS3DWB_FIFO_WATERMARK );

   /* Set the accelerometer batch rate for the FIFO */

   stiis3dwb_write_fifo_batch_data_rate( STIIS3DWB_FIFO_XL_26667_HZ );

   /* Enable Block Data Update */

   stiis3dwb_write_block_data_update();

   /* Configure FIFO interrupts i.e. */

   stiis3dwb_write_register ( STIIS3DWB_INT1_CTRL, STIIS3DWB_INT1_CTRL_INT1_FIFO_TH );

   /* Enable Accelerometer */

   stiis3dwb_write_config_mode ( STIIS3DWB_NORMAL );

The uC will then read back the number of FIFO words to read and then using SPI read the FIFO words. Note I have configured the BDU in CTRL3_C and read back the number of FIFO words by reading FIFO_STATUS1 first and then FIFO_STATUS2.

As you can see from below the FIFO threshold is triggering the interrupt correctly and the uC is reading the contents of the FIFO quickly enough to avoid any sampling lose.

  

MISO - 0

MOSI - 1

CLK - 2

CS - 3

INT1 - 4

If I allow the IIS3WB to sample for approximately 8+ mins, I’ve observed that the interrupt stops triggering and hence the uC no longer reads back any entries in the FIFO. Sometimes this test could run until 50+ mins before stopping.

On closer inspection, I noticed that the last interrupt seems to have a ‘blip’ and at that point the data being read back from the FIFO is 0s. Previously the interrupt would have remained high for longer.

  

Further debugging shows that SPI communications are functioning correctly afterwards . I can read back the contents of the WHO_AM_I register perfectly but when I read back the contents of the control registers, the values are all 0’s. It is possible to write to those registers again.

Has anyone observed anything like this previously or can suggest further steps for investigation. From the outside it almost looks as if a reset of the IIS3DWB’ config has occurred. 

I noticed something similar raised https://community.st.com/s/question/0D53W0000090yOPSAY/iis3dwb-int1-int2-stoppingstuck-at-high-after-several-watermark-events but there doesn't seem to have been any response to the questions posed.

Thanks in advance

John

[Eleon BORLINI · Accepted solution]

Hi John @JDoug.1​ ,

that's a strange behavior indeed...

You said that it looks like the device memory has been reset somehow, since all the register content is 00h... Are you sure the Vdd (and VddIO) have never dropped down below the low digital level (this could cause an hardware reset)? Could you please acquire them (or at least the VddIO signal) together with the other pins you are already monitoring, especially in the case the power supply is directly generated from the MCU?

Meanwhile, I'll try to ask internally for support for this strange event.

-Eleon

[JDoug.1]

Thanks for the suggestion @Eleon BORLINI​ 

With a scope I was able to observe some noise on the Vdd and Vddio lines (see below)

With sitting around 3.0V there are times when it could get pulled lower than the 2.1V of the IIS3DWB.

When the IIS3DWB is not sampling, the Vdd and Vddio are clean. Further investigation resulted in disabling the interrupt and reading the FIFO periodically (1 second)

When we did this test we noticed that the noise appeared for the same time as the SPI CS was low i.e. ~3.6ms

As I mentioned in the original message, this isn't the intended HW and there are wires between the IIS3DWb eval board and the target uC. For now we think we will wait until the intended HW arrives to further investigate but if you have other suggestions that would be worth trying ahead of the hardware arriving I'm willing to try them.

Thanks

John

[Eleon BORLINI]

Hi John @JDoug.1​ ,

thank you for your detailed feedback. please note that from the datasheet the supply voltage range is 2.1 V to 3.6 V.

Did you placed the decoupling capacitance on Vdd and VddIO lines, as illustrated in the datasheet p. 24 and, for example, on the STEVAL-MKI208V1K schematic?

-Eleon

[JDoug.1]

Hi @Eleon BORLINI​ 

We did notice that in the STEVAL-MKI208V1K but we assumed that the decoupling capacitor was already fitted?

Have we assumed wrong and this could be the problem?

Thanks

John

[Eleon BORLINI]

Hi John,

but are you using the steval board?

-Eleon

[JDoug.1]

Hi @Eleon BORLINI​ 

Yes, we are using the STEVAL-MKI208V1 along with the STEVAL-MKIGIBV2 adapter board.

Thanks

John

[Eleon BORLINI]

Hi @JDoug.1​ ,

did you make some progression trying to add decoupling capacitors?

-Eleon

[JDoug.1]

Hi @Eleon BORLINI​ 

We received the target hardware at the end of last week and I ran a soak test for 2+ hrs and the IIS3DWB didn't lock up at all i.e. the interrupt fired as expected. Previously it would have typically failed in under 10 minutes.

Thanks for the support during the early development phase.

John

[Eleon BORLINI]

Glad to hear it from you John :smiling_face_with_smiling_eyes:

-Eleon