LIS2DW12: FIFO-Threshold-Interrupt Jitters at 1.6kHz

[Loris Wyss]

Hello ST-Community!

When I'm using the LIS2DW12 at ODR=1.6kHz, the Interrupt for reaching the FIFO-Threshold is jittering with 1/ODR, but only if the threshold is greater than 12. If it's less or equal, everything is working fine.

The buffer-Mode is set to FIFO-Mode, but this behaviour also occurs in Continous-Mode.

The Power-Mode is set to High-Performance/Low-Noise.

The Interrupt is routed to the INT1-Pin

The two images show the rising edge on the pin INT1. The time between the two cursors "a" and "b" is 624us (almost 625us), which would equal to 1/ODR (1/1600 = 625E-6)

As written, this only happens if ODR is set to 1.6kHz and the FIFO-Threshold is greater than 12.

Does anyone have some further informations regarding this issue?

Thanks in advance for your answers!

Greetings,

Loris

[Eleon BORLINI]

Hi @Loris Wyss​ , 12 FIFO samples are 3-axis ACC + 3-axis GYRO data (2 bytes each), so it is a single data refresh. You can try to enable the BDU before setting the configuration of the FIFO (CTRL2 (21h) register, BDU bit). This means that the data are not refreshed until they are not read, or stored in the FIFO... So the data are updated in blocks and this could maybe stabilize the threshold and reduce the jitter. Regards

[Loris Wyss]

Hi @Eleon BORLINI​ , thanks a lot for your answer!

So, if I read your answer correctly, it would mean that I completely misunderstood how the FIFO in the LIS2DW12 works...

From the informations provided by the datasheet I thought, the FIFO would contain only the acceleration data.

Additionly I assumed, that a FIFO-threshold of 12 meant that there is an Interrupt when I have 12 Samples (each consisting of 3 Axis * 2 Bytes/Axis) in the FIFO, which would result in a total of 72 bytes of data.

So... are my thoughts regarding this completely wrong?

Regarding your suggestion, the BDU bit was already set and my issue is still here, no matter if block data update is activated or not...

Thanks and regards,

Loris

[Eleon BORLINI]

I'm sorry, the gyro part doesn't make sense :) I was confused from a parallel thread on iNemo FIFO.

Basically you well interpreted the documents, the threshold refers to the complete filling of the 6x12 bytes.

So the BDU has no effect... This is btw a strange behavior and I will check it with our experts. Are there other interrupts enabled except of FIFO threshold one in CTRL4_INT1_PAD_CTRL (23h) register? To try to overcome this unwanted effect, you can maybe try to act on the INT parameters (pulsed/latched, bit LIR of CTRL3 (22h) register)... Regards

[Loris Wyss]

Ah ok, so I understood that part correctly...

No, there are no other interrupts enabled in the CTRL4_INT1_PAD_CTRL register.

Setting the interrupt to latched mode doesn't help, the issue is still present.

Thanks alot for checking with your experts!

If I can help you with some further tests, just let me know...

Regards,

Loris

[Loris Wyss]

Hi Eleon

Thanks for your answer. i attached the .bin file to this answer.

Regarding the Capacitors:

I've seen this as well while checking and we will probably change with the next redesign, but I also assumed, that this isn't the problem.

I will prepare the PCB for shipping and will send it to you tomorrow.

Thanks and regards,

Loris

[Loris Wyss]

Hi Eleon

The PCB was shipped today, so it will probably arrive by the end of the week.

If you have any questions, just let me know.

Regards,

Loris

[Eleon BORLINI]

​Just at the beginning of the Christmas holidays ;) ok, let's see what we can do

Regards

[Loris Wyss]

Yeah, I know.

Timing at it's best... ;)

Thanks for your efforts!

[Eleon BORLINI]

Hi Loris, just received your board, thank you for your effort. I have some other question about the issue you are facing:

• you are acquiring data at 1.6kHz, filling the FIFO at that speed, and when the FIFO is full you read the data together, checking the interrupt and its jitter. At which speed do you read the data (e.g. SPI 1Mbit)?
• are you using the FIFO stop filling mode (FMode[2:0] 001 in FIFO_CTRL (2Eh))? There can be the possibility that, if this mode is not selected, the FIFO updates while you are emptying it and the interrupt raises not after 12 new samples but after only 11 samples (the 1st samples already in FIFO during you are reading it, so the interrupt raises only after ODR*11 seconds). I don't know if I made myself be understood...
• can you try to do the same test at higher SPI speeds and/or lower ODR, and maybe with the STOP filling enabled, and check in time if the jitter is still there?

Regards

[Loris Wyss]

Hi Eleon

Regarding speeds:

• The SPI clock speed was set to 7.5 MHz
• Due to the clock configuration in the STM32, I can't increase the SPI speed and also decreasing it doesn't help
• When decreasing the ODR to 800 MHz or lower, the Jitter is gone as well

The Sensor is running in FIFO-Mode (FMode[2:0] 001), so that doesn't solve the problem. But as far as I understand the Datasheet, in FIFO Mode the Sensor stops collecting Data as soon as there are 32 unread samples in the FIFO. But for me It's not really clear if this happens as well when the FIFO Threshold is reached (In my case 24).

I hope this helped you.

Regards,

Loris

[Loris Wyss]

Hi @Eleon BORLINI​ 

Have you got any Updates for me?

Were you able to put the board in operation?

Thanks and Regards

Loris

[Eleon BORLINI]

Hi @Loris Wyss​ , unfortunately not yet, or, better, I'm still not able to reproduce the jitter failure...

Let me check again other configurations before coming back to you

Regards

[Loris Wyss]

Ok, thanks for the update.

Just for clarity: Can you see the described behaviour with the Hardware i sent you?

Regards

[Loris Wyss]

Hi @Eleon BORLINI​ 

Have you found out anything regarding this Issue?

And have you been able to reproduce the described behaviour with the PCB i sent you?

Regards

[Eleon BORLINI]

Hi @Loris Wyss​ , I'm very sorry to come back to you without a news on your PCB... But I can ship back it to you, if you want. Btw, can you please check if your issue is somehow related to this other thread? Regards

[Loris Wyss]

Hi @Eleon BORLINI​ , thanks for your answer.

Ok, so here is a step-by-step instruction to reproduce the jitter on the PCB I sent you:

1. Supply the Board with +24V
2. Flash the software I sent (STM32F4.bin) you on the MCU
3. Connect the probe of the Oscilloscope to INT2
4. Trigger the Oscilloscope on rising Edge at INT2
5. When Triggering at Edge n, then Edge n+1 has a jitter of ca. 625us

If it didn't work, please try to flash software with the free Keil uVision Evaluation version (Available here: https://www.keil.com/demo/eval/arm.htm)

When you follow these instructions step by step, the issue should occur.

Could you please check, if that works for you?

I will check, if my issue is related to the one described in the other thread.

Thanks and regards

Loris

[Eleon BORLINI]

Hi @Loris Wyss​ , what I can see following this procedure is that I can see the interrupt on INT1 (instead of on INT2 as you reported.. I tried to trigger the shot on the INT2 signal but it is always at 0V, see the blue line), and this interrupt is flickering in DURATION of about the quantity you reported. This could cause the jitter. But the distance between the rising edge of two consecutive interrupt pulses seems the same (cursor measure of 15.60ms)...

Single shot screen:

Multiple shots screen:

Did you set the interrupt duration (for example in the INT_DUR (33h) or in the WAKE_UP_DUR (35h) registers?

Regards

[Loris Wyss]

Hi @Eleon BORLINI​ 

Thanks for your feedback, You're right I mixed up the interrupt pins in my instruction-post.

It's strange that you don't see the Jitter on the rising edges. I just tried it again and I can still see the exact same behaviour as described/shown in the first post.

Could you try zooming in at the rising edge, which follows the one you triggered on? If you let the measurement run, you should be able to see that the rising edge is jumping between two positions...

[Loris Wyss]

Hi @Eleon BORLINI​ 

Can you give me an update about this issue?

I still don't know if you were able to reproduce this behaviour on the HW I sent you...?

Regards

Loris

[Eleon BORLINI]

Hi Loris, you are fully tight... it is a subject that grieves me because Milan and Italy in general is in lock down since two months and the lab activity is only partially ongoing. So, to recap, basically I tested the devices in stand-alone mode (HW involved: STEVAL-MKI109V3 + STEVAL-MKI179V1) and didn't find any issue, but I didn't perform test with your platform :( I would like to make up for lost time as soon as the lockdown is over. Regards

[Loris Wyss]

Hi @Eleon BORLINI​ 

I hope you're doing well!

Have you been able to return to the lab?

Can you give me a time frame in which I can expect some test results from you?

We've basically got an entire Project on hold right now due to this issue.

Thanks and Regards

Loris

[Eleon BORLINI]

Hello @Loris Wyss​ , you are fully right and I'm here in lab to try to test the board, but the USB connector seems damaged (maybe due to the soldering of the GND wire), so I cannot plug the USB easily.

Since in these days I'm pretty alone in lab, what I can suggest you is to ask for support to the ST regional sales offices/representatives and FAE. I may send them your PCB, if you open your OLS request. Regards

[Loris Wyss]

Hello @Eleon BORLINI​ 

Thanks alot for your answer!

Well, the USB-Port isn't needed to put the Board in operation, it's only for Logging/Debug Purposes.

The PCB is powered through the GND/+24V-Pins.

Regarding your suggestion for further Support:

-I'd like to get a confirmation from you that the issue is present before taking any further steps.

Thanks and Regards, Loris