Sleep tracing causes ISR queue overflow

[maxgerhardt]

Description

• target: NUCLEO_L476RG (STM32L476RG)
• toolchain: GCC
• mbed-os version: 5.12
• special configuration: "target.tickless-from-us-ticker": false to use LPTIM for the tickless RTOS in order to do deepsleep

I'm currently trying to trace the deep sleep usage (or rather, why it's not being used) in a big firmware. To search for the culprit, I've defined the macro MBED_SLEEP_TRACING_ENABLED as it is described in the documentation.

However, doing so will shortly crash the microcontroller in mbed_error() with the error being "CMSIS-RTOS error: ISR Queue overflow"

The firmware is fairly complex and uses a number of peripherals (SPI, UART @ 921600 baud), threads and EventQueue objects (for LoRaWAN, internal events, ..) so it's hard to give a minimal, reproducible example. So my question is:

• has anyone encountered this behaviour before with sleep tracing?
• how can the source for the ISQ queue overflow be found?

By debugging the sleep code, I've noticed that the tickless RTOS often decides to start a microsecond-resolution timer in case the ticks it would have to wait is smaller than wakeup delay for the LPTIM. Also, the attached LoRa radio surely fires some interrupts at the start which the driver needs to handle. But I'm unsure whether this is the cause for the sleep tracing to crash. It may simply be that it switches sleep states too many times per second and can't print it that fast? (though the debug UART is already at 921600 baud)

Any help's appreciated.

Stacktrace

(gdb) where
#0  custom_mbed_error_hook () at ./src/main.cpp:142
#1  0x08021fa6 in handle_error () at ./mbed-os/platform/mbed_error.c:189
#2  0x080220a2 in mbed_error () at ./mbed-os/platform/mbed_error.c:271
#3  0x08023370 in osRtxErrorNotify () at ./mbed-os/rtos/TARGET_CORTEX/mbed_rtx_handlers.c:64
#4  0x080253fe in osRtxThreadSwitch () at ./mbed-os/rtos/TARGET_CORTEX/rtx5/RTX/Source/rtx_thread.c:435
#5  0x0802501e in osRtxTick_Handler () at ./mbed-os/rtos/TARGET_CORTEX/rtx5/RTX/Source/rtx_system.c:137
#6  0x08023566 in SysTick_Handler () at irq_cm4f.S:159
#7  <signal handler called>
#8  osKernelStart () at ./mbed-os/rtos/TARGET_CORTEX/rtx5/RTX/Source/rtx_kernel.c:594
#9  0x08023306 in mbed_rtos_start () at ./mbed-os/rtos/TARGET_CORTEX/mbed_rtos_rtx.c:116
#10 0x0802319e in software_init_hook () at ./mbed-os/rtos/TARGET_CORTEX/TOOLCHAIN_GCC_ARM/mbed_boot_gcc_arm.c:52
#11 0x080001f6 in _start ()

Output up to crash

LOCK: mbed_rtx_idle.cpp, ln: 111, lock count: 1
Sleep locks held:
[id: mbed_rtx_idle., count: 1]
UNLOCK: mbed_rtx_idle.cpp, ln: 133, lock count: 0

Issue request type

[X] Question
[ ] Enhancement
[ ] Bug

[0xc0170]

Thanks for referencing this issue. We will look at 11497 and hopefully we find out what is going on there and might help here as well.

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.

[0xc0170]

@maxgerhardt This was set as question. In case this is a bug, please reopen with full bug report.

Have you resolved this btw?