Hi. The LIS3DHTR. I want to use the Stream-to-FIFO mode and interrupt on 'high' events to capture the 32 samples leading up to the trigger.

[FPGA_bloke]

Am I right in saying that to make this work consistently, after each interrupt and reading out the data, you have to select Bypass mode in FIFO_CTRL_REG, and then put it back into 'Stream-to-FIFO' mode? This seems to make it work, but there's no mention of it in text, maybe a hint in Figure 30 of the app note. Can you confirm?

Also, the description of Stream-to-FIFO mode in the app note (9.3.4), says that FIFO content after the trigger will be 30 samples before the trigger, the sample when the trigger was generated and one sample after. That's not what I see: I get the very last sample having the only acceleration higher than the threshold. IS this because something is wrong in device setup, or a feature of using the DURATION of zero,... or just a typo in the docs?

Finally, I saw on another manufacturers forum, that the part can interpret certain states of SPC and SDI as I2C activity, when you want SPI mode. We use SPI mode, and there are multiple slaves on the bus. When we are not accessing the LIS3DHTR, its CS will be high, but the SPC and SDI lines WILL be active when accessing other devices. If what I've read is true, there's a danger of the LIS3DHTR driving the SDI line and contending an SPI access to another slave. Can you confirm, one way or the other please? Is there a fix? This one could be a show-stopper, .... the part really shouldn't be 'demanding' that it has a dedicated SPI bus all to itself!

Cheers for now.

[Eleon BORLINI]

Hi @FPGA_bloke​ , you mean you are not able to read the 30 samples stored in FIFO before the interrupt is raised? The AN reports that if FIFO isn’t yet full (initial transient), it continues filling until it is full (OVRN_FIFO = “1�?) and then, if the trigger is still present, it stops collecting data. Can you set the duration of the interrupt long enough (32*ODR max) to be sure the interrupt is still high when the FIFO is full?

About the SPI question, if the CS is high, there is no worry about undesired SPI communication... at least from my validation experience, where we use multiple socket board. Regards

[FPGA_bloke]

Hello Eleon.

No, I didn't mean that. I get all 32 samples, as expected. But it looks as if it is the very last sample that caused the trigger. The app note says it should be the sample before the last one, that's all. It just seems odd that it ALMOST works as described.

Re the unwanted I2C response: I've since heard from someone else in ST, that this CAN be a problem.... but there IS a fix. There's a bit in an undocumented register that you can use to turn off the i2c slave!

Cheers.