Systemview broken on SDK 2.8.0/Kernel 3.7.99

[anthony32086]

With the recent release of SDK 2.8.0 enabling tracing with Segger Systemview locks up the system.

The offending issue is buf = net_buf_alloc(&hci_cmd_pool, K_FOREVER); which will block forever waiting for a buffer that will never become available. I am not sure if this is a NRF related change on other parts or a Zephyr but as I am using NCS I felt to report here first.

The following command builds on 2.8.0 and 2.7.0 without fail.

west build -b nrf5340dk/nrf5340/cpuapp --pristine=always nrf/samples/bluetooth/peripheral_bms

However only with 2.8.0 when tracing and systemview are enabled the LED no longer blinks and in Ozone I can trace and see it is stuck in the above line waiting.

west build -b nrf5340dk/nrf5340/cpuapp --pristine=always nrf/samples/bluetooth/peripheral_bms -- -DCONFIG_TRACING=y -DCONFIG_SEGGER_SYSTEMVIEW=y

[Susheel Nuguru]

Just compiled this for nrf5340dk_nrf5340_cpuapp and running the debugger shows that it is not stuck at the shown function call that you pointed out.

Tested on v2.8.0,  Not sure what is different on your end by try increasing the main stack size in case the 1024 bytes might be a border without enabling trace and systemview and when you enable it, it might cross that usage and causing some stack corruption.

Add this in your prj.conf and pristine build it.

CONFIG_MAIN_STACK_SIZE=2048

[anthony32086]

I've tried increasing the stack to 2048, and even 8192 for botth system workq and main stack both without success.I've also tried CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=8192 and CONFIG_SEGGER_SYSVIEW_RTT_BUFFER_SIZE=8192 which did not work.

Interestingly I now get it to fail at k_fifo_put(&bt_dev.cmd_tx_queue, net_buf_ref(buf)); instead.Specifically the system is not locked up but when bt_tx_irq_raise() submit's it's work the system is stuck in endless idle waiting for something to complete.

Replacing sys_port_trace_k_fifo_put_enter and sys_port_trace_k_fifo_put_exit with empty macros resolves the issue completely which makes me agree that sysview is doing something weird with buffer overruns corrupting the stack.