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]

Thank you for your attention, Edvin! To clarify, please take a look at the system's block diagram. There are two DK boards.

Also, to be more intuitive, I'm trying to toggle a pin in a while(1) loop every 20ms. I've noticed that the timing significantly increases when the RTT is not connected but normalizes once I connect the RTT. I've attached a video for your reference.

	while (1) {

		ret = gpio_pin_toggle_dt(&signal_pin);
		if(ret < 0){
			return 0;
		};
		k_msleep(20);
		//k_sleep(K_FOREVER);
	}

Best,

[Edvin]

Hello,

SaeedZadeh said:

please take a look at the system's block diagram. There are two DK boards

Yes. I used nRF Connect for Dekstop -> Bluetooth Low Energy as my central. 

Please zip a project that replicates the issue with the sensor simulation set to true, and RTT logging enabled, and try to unzip it to check that it still replicates the issue using nRF connect for Desktop as the central. If it only reproduces with your specific central application, please upload that as well.

Then upload the zipped application that requires no modifications to reproduce the issue.

Best regards,

Edvin

[SaeedZadeh]

Thank you Edvin! I have followed your advice but even with the nRF Connect for Desktop the problem is there. I have uploaded both files here.

Best,

Saeed

8664.nrf5340_imu_adc_led_ble.zip5584.central_uart.zip

[Edvin]

Are you able to build the application from the zip folder that you sent? I tried (in an unmodified nRF Connect SDK v2.2.0, but I can't make it build without changing stuff. Can you please try the same?

BR,
Edvin

[SaeedZadeh]

Hi Edvin,

I use SDK v2.5.2, and there is no problem.

Bests,

[SaeedZadeh]

Hi Edvin,

I tried to build it with SDK v2.2.0, but I couldn't make it.

As I mentioned above, I use SDK v2.5.2, and there is no problem. 

Do you have SDK v2.5.2 by any chance?

Bests,

[Edvin]

Ah, sorry. I didn't see any mentions of versions other than a reference to 2.2.0 from the beginning of the ticket. But that was not by you. I am sorry.

Ok, so now I am actually able to see what you are seeing. 

I have not seen behavior like this before, but it turns out that it was the deferred logging that caused this issue. So basically these two:

CONFIG_LOG_MODE_DEFERRED=n
CONFIG_LOG_MODE_IMMEDIATE=y

When the log is not read out, then the logging is blocking. I didn't test combinations of these, but deferred logging turned off makes the logging blocking, and I guess that something timed out allowing the CPU to continue every 178ms. 

So turn on deferred logging, unless you need it, and intend to read the log. Turning off the logging also works.

Best regards,

Edvin

[SaeedZadeh]

Thank you, Edvin. Your solution resolved the problem, but afterwards, the IMU stopped working for some reason. Therefore, I kept those lines unchanged and made the following adjustments, and everything worked perfectly. However, the IMU's INT2 doesn't work in this situation. Do you have any idea?
Best,

CONFIG_RTT_CONSOLE=n
CONFIG_LOG_BACKEND_RTT=n

[Edvin]

I don't know what the IMU's INT2 is used for. I assume it is an interrupt pin, but what do you mean by "doesn't work"? Does it not trigger, or does the nRF not detect it?

Best regards,

Edvin

[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,