Identifying a High-Frequency ISR in SystemView

RE: Identifying a High-Frequency ISR in SystemView

Andrea Verdecchia — Thu, 13 Feb 2025 10:38:09 GMT

I ran some tests and discovered that the new error is still caused by the call to the bt_hci_cmd_send_sync function (this time in the hci_vs_init function), which returns ENOBUFS. So, I further increased the value of CONFIG_BT_BUF_CMD_TX_COUNT=20. This time, I didn’t get any errors. However, the problem is that when I try to establish a Bluetooth connection, the application freezes. At this point, I tried the modification in kernel.h that you posted, removing the previous configurations and leaving only that change

CONFIG_TRACING=y
CONFIG_SEGGER_SYSTEMVIEW=y

# CONFIG_BT_BUF_EVT_RX_COUNT=20
# CONFIG_BT_BUF_EVT_RX_SIZE=255
# CONFIG_BT_BUF_CMD_TX_COUNT=20
# CONFIG_BT_BUF_CMD_TX_SIZE=255
# CONFIG_BT_RX_STACK_SIZE=2048
# CONFIG_BT_HCI_TX_STACK_SIZE=2048

Now, everything seems to be working. Are there any downsides to keeping this modification in kernel.h? Thanks a lot!

Regarding the ISR from my initial question, I’ve filtered it for now, but it’s still present. I’ll look into it further, but for now, I can manage.

RE: Identifying a High-Frequency ISR in SystemView

Elfving — Thu, 13 Feb 2025 08:24:48 GMT

[quote user="Thoraz"]Does the fix you sent me apply to my case? I'm working with NCS 2.9.0[/quote]

I don't think it's included. You could cherry pick that if you want to, but if the buffer modification works I guess it's fine.

[quote user="Thoraz"]If you have any suggestions regarding the new error, they are more than welcome.[/quote]

I'm not 100% sure here. But just to start with "Vendor HCI extensions not available", as that also might've affected everything else, do you know what HCI extensions in your app it could be referring to?

Regards,

Elfving

RE: Identifying a High-Frequency ISR in SystemView

Andrea Verdecchia — Wed, 12 Feb 2025 18:51:33 GMT

Yes, exactly. After replying to you, I went to look for the source of the error and arrived at the function bt_hci_cmd_send_sync (specifically net_buf_alloc). At this point, after searching online, I added these configurations

CONFIG_BT_BUF_EVT_RX_COUNT=10
CONFIG_BT_BUF_EVT_RX_SIZE=255
CONFIG_BT_BUF_CMD_TX_COUNT=10
CONFIG_BT_BUF_CMD_TX_SIZE=255
CONFIG_BT_RX_STACK_SIZE=2048
CONFIG_BT_HCI_TX_STACK_SIZE=2048

The issue related to net_buf_alloc seems to be resolved, but now a new error appears in the logs:

*** Booting My Application v0.0.10-31b40401242e ***
00> *** Using nRF Connect SDK v2.9.0-7787b2649840 ***
00> *** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
00> [00:00:00.023,101] <wrn> bt_hci_core: Vendor HCI extensions not available
00> [00:00:00.023,132] <wrn> bt_id: Failed to read public address
00> [00:00:00.023,223] <wrn> bt_id: Read Static Addresses command not available
00> [00:00:00.023,742] <err> bt_id: Unable to set random address
00> [00:00:00.023,742] <wrn> ble_connection: Ble_Connection_Ready returned err -105

I don’t have the device with me right now, but I will run more tests tomorrow. Thanks in the meantime for confirming the possible solution with CONFIG_BT_BUF_CMD_TX_COUNT. If you have any suggestions regarding the new error, they are more than welcome.

Does the fix you sent me apply to my case? I'm working with NCS 2.9.0.

RE: Identifying a High-Frequency ISR in SystemView

Elfving — Wed, 12 Feb 2025 15:44:30 GMT

No problem 🙂

[quote user="Thoraz"]By the way, do you know anything about the ENOBUFS error that the Ble_Connection_Ready() function returns when I use it in bt_enable()? The problem only appears if I enable tracing.[/quote]

Must have missed that question in the OP. It is out of buffer space. Tracing requires a bit more resources, so it does make sense that it can affect things. Does increasing the buffer size help? Use CONFIG_BT_BUF_CMD_TX_COUNT.

This does look a bit similar to this recent issue..., What NCS version are you using?

Regards,

Elfving

RE: Identifying a High-Frequency ISR in SystemView

Andrea Verdecchia — Wed, 12 Feb 2025 09:49:39 GMT

Thanks for the links you sent me. I'll check them and see if I can solve the issue. Thanks. By the way, do you know anything about the ENOBUFS error that the Ble_Connection_Ready() function returns when I use it in bt_enable()? The problem only appears if I enable tracing.

void Ble_Connection_Ready( int err )
{
    if ( err )
    {
        LOG_WRN( "Ble_Connection_Ready returned err %d", err );
        return;
    }

    k_sem_give( &bluetoothReady );
}

[...]

if ( bt_enable( Ble_Connection_Ready ) != 0 )
{
	return SYSTEM_ERROR;
}

if ( k_sem_take( &bluetoothReady, K_SECONDS( 5 ) ) != 0 )
{
    return SYSTEM_ERROR;
}

You can find my configuration prj.conf in the previous post.

Or would it be better to open another topic?

RE: Identifying a High-Frequency ISR in SystemView

Elfving — Tue, 11 Feb 2025 14:41:29 GMT

Hi Andrea,

It is hard to immediately say what is causing this, though this interrupt definitely could be from the softdevice. One question is if you are you seeing this on just your application, on all samples, or maybe just the BLE ones.

[quote user=""]How can I determine which ISR it is? Is it possible to assign names to ISRs when tracing?[/quote]

There should be some info on how to do this here.

[quote user=""]Why don't I see the Zephyr RTOS tick ISR?[/quote]

The blog mentions that you need to explicitly enable logging for specific interrupts, eg. sysview_irq_log( RTC1_IRQn, true );

Regards,

Elfving