Issue with IMU Sensor (LSM6DSV16X) Sample Rate in Sensor Hub Mode

[SaeedZadeh]

I am using an IMU sensor in sensor hub mode (LSM6DSV16X, LIS2MDL) with the FIFO interrupt interval set at 30 Hz. The data is sent over BLE. It works perfectly when using RTT, but when I disable debug mode, the sample rate drops to around 1 Hz.

Could someone please help me resolve this issue?

Thank you.

[SaeedZadeh]

Thank you for your reply. When the IMU's FIFO is full, an interrupt will occur on the interrupt pin. The interrupt rate will decrease to 1 Hz as if something changes or is missed when I disable the RTT configuration.

[Edvin]

So what triggers the IMU readings in the first place? Do you have a timer set up at 30Hz or something?

What HW are you running this on? nRF5340DK? Or do you have a custom board?

[SaeedZadeh]

Sorry for the confusion. INT1 and INT2 are the interrupts of the IMU. INT1 triggers the nRF whenever the IMU's FIFO is full, and INT2 is for special actions, such as a tap or a free fall. Here is the entire situations' conclusion:

1. In the original code where I first encountered the problem, the system worked perfectly with RTT, but when RTT was disconnected, there was a timing delay.
2. After applying your provided changes, the timing issue was resolved. However, the IMU couldn't trigger the interrupt on the nRF.
   

   CONFIG_LOG_MODE_DEFERRED=n
   CONFIG_LOG_MODE_IMMEDIATE=n

3. I have modified the overlay through trial and error. Now, INT1 (FIFO overflow) triggers correctly, but INT2 remains high and doesn't trigger.
   

   CONFIG_RTT_CONSOLE=n
   CONFIG_LOG_BACKEND_RTT=n

Additionally, I was wondering what might be changing here. I am confident that the IMU's code is correct, as it works in my original code (the one with the timing delay and RTT connected). However, things go wrong when I change the logging configuration in the overlay file. When I observe the signals on the logic analyzer, it seems like the IMU initializes but then stops functioning.

Thank you,

[SaeedZadeh]

It seems I may have accidentally closed the ticket. I want to make sure my issue is still being considered.

Thank you

[Naeem Maroof]

Hi Saeed,

Advin is out-of-office, and I will be with you for now.

I see that there has been a lot of communication and also the nature of question has been changed.

Could you summarize the current situation and the code and the setup (connections and measurements), and how can I reproduce it?

You have mentioned that "things go wrong when I change the logging configuration in the overlay file". Can you show both overlays and describe behaviors? Showing any output / logs would also be helpful.

Regards,
Naeem

[SaeedZadeh]

Hi Naeem,

I appreciate your consideration.

This project involves receiving data from the IMU and ADC and transferring it via BLE. The IMU has two interrupts: INT1 for FIFO ready and INT2 for special events like taps.

INT1 should trigger approximately every 10 ms, which it does when the RTT is connected. However, when I disconnect RTT, the trigger time significantly increases to around 170 ms. This is with the first overlay-debug.conf configuration.

I followed Edvin's advice and changed the overlay-debug.conf. After the IMU initialization, neither INT1 nor INT2 triggered, and the IMU shut down.

CONFIG_LOG=y
CONFIG_LOG_MODE_DEFERRED=n
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_PRINTK=n

# Troubleshooting
CONFIG_ASSERT=y
CONFIG_RESET_ON_FATAL_ERROR=n


CONFIG_MAIN_THREAD_PRIORITY=8

I then applied the following configuration, which allows INT1 to trigger on time even when RTT is disconnected. However, INT2 does not trigger and remains inactive.

CONFIG_LOG=y
CONFIG_LOG_MODE_DEFERRED=n
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=n
CONFIG_LOG_BACKEND_RTT=n
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_PRINTK=n

# Troubleshooting
CONFIG_ASSERT=y
CONFIG_RESET_ON_FATAL_ERROR=n


CONFIG_MAIN_THREAD_PRIORITY=8

I don't believe the issue lies with the IMU itself, as the only changes I made were to the overlay-debug.conf.

You canjust download the latest file that I uploaded here and build. Please note that the SDK version is v2.5.2.

Thank you,

[Naeem Maroof]

Are there any special things with the INT2?

I see that there are 3 modes in which  sensor could be connected,

and the role of INT1 is same for all the modes, but INT2 is different.

I have not used this sensor, but just pointing if that is something to look at.

[SaeedZadeh]

The problem doesn't seem to be with the sensor configuration since I haven't changed anything on the sensor side and get the proper result while the RTT is connected. However, changing the overlay_debug alters the sensor's behavior. I believe there might be an issue with my nRF configuration. What are your thoughts?

Thsnk you,

[Naeem Maroof]

But this:

SaeedZadeh said:

INT1 should trigger approximately every 10 ms, which it does when the RTT is connected. However, when I disconnect RTT, the trigger time significantly increases to around 170 ms.

does not make sense then, because the RTT is on the DK / MCU side, and the INT1 is generated by sensor which is already configured, right? How changing (logging) behavior can impact the sensor firing interrupt? I do not know about this sensor configurations. 

Can you print system time when interrupt is generated by the sensor, and then from there we see how much time it is taking between interrupts, so we do not see the logging time but rather interrupt firing time.

Can you show the changes you made in the overlay?

[SaeedZadeh]

Thank you for your reply. 

Naeem Maroof said:

does not make sense then, because the RTT is on the DK / MCU side, and the INT1 is generated by sensor which is already configured, right? How changing (logging) behavior can impact the sensor firing interrupt? I do not know about this sensor configurations. 

This is why I am confused, as I don't change anything in the main code or IMU, but I change the overlay_debug and have a different result.

Naeem Maroof said:

Can you print system time when interrupt is generated by the sensor, and then from there we see how much time it is taking between interrupts, so we do not see the logging time but rather interrupt firing time.

Please take a look at the image below. You'll notice that INT1 triggers a ~10 ms interrupt, while INT2 remains high, instead of being low and transitioning to high when an event occurs.

Naeem Maroof said:

Can you show the changes you made in the overlay?

I changed the following line to "n" and got the above result. 

CONFIG_RTT_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=y

Best,

Saeed

[SaeedZadeh]

Hi Naeem,

Have you had a look at my reply by any chance? Please let me know if you need any further information.

Bests,

[Naeem Maroof]

Hi Sid,

Apologies for the delayed response due to high work load.

I have used the 2 zip files that you uploaded last time (one for the NRF52DK and the other for the 5340DK)

I am using those projects as it is (without anything changing):

I can see the output on the console connected to the NRF52DK that is receiving BLE data from the NRF5340DK. I can see that LED and ADC data is printed.

Next, on the 5340DK, in the main code, I put timestamp when we are setting up the tx_ble_buffer.

I can see that LED and ADC data is received after 20ms, which matches with what you were saying and expecting.

Then I connected RTT on 5340DK (using the VS Code Extension-->Connected devices-->5340DK-->RTT)

I can see that the Interface MCU led is blinking fast, which is showing the RTT connection.

I can still see on the output that the LED and ADC data is received after 20ms. Snapshot attached where RTT is connected: