Need to solve excessive thread-unblock latency on nrf9160 + zephyr SDK

RE: Need to solve excessive thread-unblock latency on nrf9160 + zephyr SDK

Susheel Nuguru — Thu, 31 Aug 2023 07:45:09 GMT

How are you disabling the power management? The default behavior is tickless idle enabled in Zephyr which disables RTC tick in sleep triggered in idle_task. If you can see how long your idle task is running, then probably that will give you a hint of how long your system is sleeping. If you have disabled power management then check in the systemview that the idle task is running as less as possible.
Which GPIO number is this? you can set a breakpoint in the GPIOTE interrupt handler and see the registers of this peripheral to find out which GPIO pin config is causing this. There are suggestions in the documentatation on how to avoid spurious interrupts from GPIO or port events.

RE: Need to solve excessive thread-unblock latency on nrf9160 + zephyr SDK

jpnorair — Thu, 31 Aug 2023 00:53:48 GMT

It's not variance in the timer handler. It is variance in the task that the timer handler unblocks. We use the segger tools and couldn't find any thread causing problems, but I think there are two possibilities. Maybe you can advise.

1. we think we are disabling power-management features in Zephyr, but Zephyr is not confidence-inspiring. It could be the case that it is going into low power modes despite our best efforts.

2. There is an oscillating GPIO ISR. Again, we don't think we are enabling any of these, but Zephyr is so opaque.

Can System view give information about either of these?

thanks

RE: Need to solve excessive thread-unblock latency on nrf9160 + zephyr SDK

Susheel Nuguru — Tue, 29 Aug 2023 09:27:41 GMT

It seems like you need a tracing solution like Segger Systemview to find out what other contexts are causing that variance in triggering your timer handler.

Since all contexts are organized into time axis, you will see if this variance is caused by other high priority context masking your timer handler.