Call to bt_nus_send creates data access violation

RE: Call to bt_nus_send creates data access violation

miket.create — Wed, 28 Sep 2022 17:19:14 GMT

Modifying prj.conf, I was able to confirm that the stack size was the issue with the application. However, in my modified code above, I believe the call to bt_nus_send() was happening on the main thread, rather than the separate ble_write_thread as defined in the original example.

So my application was still crashing when increasing the value of CONFIG_BT_NUS_THREAD_STACK_SIZE, but when I added CONFIG_MAIN_STACK_SIZE to prj.conf the application ran as expected, and messages were sent to the connected peer.

Thank you again for your response, this was still very helpful and informative!

RE: Call to bt_nus_send creates data access violation

Maria Gilje — Wed, 28 Sep 2022 11:39:44 GMT

Hello,

The short answer is that the stack size for ble_write_thread needs to be increased. You can check the stack usage with the Thread analyzer.

Now to the more detailed answer.

[quote user=""]00> [00:02:50.019,897] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0[/quote]

This log message shows the the reason for your error is a stack overflow. The stack size is one of the parameters used to define a thread, e.g. in the unmodified peripheral_uart sample, ble_write_thread is defined with

K_THREAD_DEFINE(ble_write_thread_id, STACKSIZE, ble_write_thread, NULL, NULL,
		NULL, PRIORITY, 0, 0);

STACKSIZE from above is defined to be CONFIG_BT_NUS_THREAD_STACK_SIZE, which is set in the sample's Kconfig or prj_minimal.conf, depending on which configuration file you are building with. The default value 1024 is set in Kconfig, while the value set in prj_minimal.conf is 512. You can increase the stack size by adding a line in your prj.conf where you set CONFIG_BT_NUS_THREAD_STACK_SIZE to a larger value.

The new value for the stack size should not be excessively large. You can find a suitable value for the stack size by first setting it higher than you think you will need. Then you can use the Thread analyzer to see how much stack your threads actually use. The Thread analyzer will give a report at set intervals or when the application calls the print or run functions for Thread analyzer.

[quote user=""]The same code runs as expected on an earlier version of nRF Connect (1.9.1)[/quote][quote user="miket.create"]I noticed that the modified example also works for nRF Connect versions 2.0.0 and 2.0.2, and the data access violation also occurs for 2.1.0-rc1 and rc2.[/quote]

Now, the reason for versions 1.9.1 and 2.0.x working with the modification while 2.1.0 does not likely boils down to changes in the sample which results in a slight increase of stack use for 2.1.0 compared to earlier versions. The extra increase of stack used from your modification will then result in the overflow you experienced.

I hope you find this helpful, and don't hesitate to ask if anything is lacking or unclear.

Kind Regards,

Maria

RE: Call to bt_nus_send creates data access violation

robmacl — Tue, 27 Sep 2022 20:23:37 GMT

Additional context for this error. I randomly hit on a workaround for this problem which worked in the older nrfconnect. I noticed that our code worked when programmed on a NRF52dk board, but not on our target board (I derived the board definition from NRF52dk). I read the dev board memory using the programmer and wrote it into our target. Now it worked! Even when I wrote new code using "west flash".

Also, the nrf52dk stopped working with our bluetooth code when I did "nrfjprog --recover", but started working again when I wrote the saved flash image back to the board.

To me it seems very likely that we are missing some config flag which causes something to be programmed. Could this have to do with the flash data partition used by the bluetooth code? I copied the memory map from NRF52dk device tree without knowing what that is doing.

RE: Call to bt_nus_send creates data access violation

miket.create — Tue, 27 Sep 2022 17:21:07 GMT

Thank you for taking the time on this, Maria. It is much appreciated.

Just a little bit of additional info from further testing: I noticed that the modified example also works for nRF Connect versions 2.0.0 and 2.0.2, and the data access violation also occurs for 2.1.0-rc1 and rc2.

RE: Call to bt_nus_send creates data access violation

Maria Gilje — Tue, 27 Sep 2022 15:11:16 GMT

Hello,

I am looking into your case, but I need some time to be able to answer you thoroughly. Thank you for your patience.

Kind Regards,

Maria