NCS: Central UART Sample

RE: NCS: Central UART Sample

Sourabh_DevZone — Thu, 22 Feb 2024 10:48:57 GMT

Hi,

I was also getting same error with NCS-v2.5.2, It looks like there may be a stack overflow in the main thread. Please try to double the stack size by adding "CONFIG_MAIN_STACK_SIZE=2048" to the prj.conf file and see if you still get the same error after.

Best regards,

Sourabh

RE: NCS: Central UART Sample

dejans — Fri, 13 Jan 2023 12:22:34 GMT

Hi,

Thank you for your input and for letting us know that the issue is no more present.

Best regards,
Dejan

RE: NCS: Central UART Sample

Anthony W — Thu, 12 Jan 2023 16:04:11 GMT

I want to point out this issue is still occurring in the sample. I've used an nRF52-DK as well as a BMD-350 EVK, same issue in both, whether debugging or not. If I step through the code, it fails at bt_enable with a HardFault:

Level,Function,Stack Frame,Source,PC,Return Address,Stack Used
0,<HardFault Exception>,32 @ 0x20005188,fault_s.S:80,0x00019190,[0x200051A0]: 0x11B35B2A,32
0,Top of stack - return address out of range: 0x11B35B2A,,,,,

Edit: I upgraded NCS to 2.2.0 and this seems resolved. So maybe a non-issue now.

RE: NCS: Central UART Sample

dejans — Thu, 28 Jul 2022 07:13:01 GMT

Hi,

I am glad I was able to assist you.

Best regards,
Dejan

RE: NCS: Central UART Sample

pfishburn — Wed, 27 Jul 2022 16:20:32 GMT

Thank you for investigating. I will follow up if I find any more information on why the sample is being finicky on my boards.

RE: NCS: Central UART Sample

dejans — Wed, 27 Jul 2022 08:29:34 GMT

Hi,

I have tested the sample. I have not encountered continuous rebooting as you described it. I have seen only one reboot while "stepping over" using debugger and this was when the hard fault appeared. In addition, I have not observed any difference between just erasing, and erasing and flashing the board.

Best regards,
Dejan

RE: NCS: Central UART Sample

pfishburn — Tue, 26 Jul 2022 20:39:29 GMT

dejans Any idea why the sample reboots continually unless it is loaded after a previous SDK version of the same example?

RE: NCS: Central UART Sample

pfishburn — Tue, 26 Jul 2022 15:26:23 GMT

Hi,

Yes, I am aware debugging can sometimes cause a hardfault by slowly stepping through the code. The issue is still present when the board is erased, flashed and rebooted. This is noticed from the log output displaying

*** Booting Zephyr OS build v3.0.99-ncs1 ***
*** Booting Zephyr OS build v3.0.99-ncs1 ***
*** Booting Zephyr OS build v3.0.99-ncs1 ***
*** Booting Zephyr OS build v3.0.99-ncs1 ***
*** Booting Zephyr OS build v3.0.99-ncs1 ***
*** Booting Zephyr OS build v3.0.99-ncs1 ***

...

The initial boot log is repeatedly shown since the board is repeatedly hitting a hardfault and rebooting.

RE: NCS: Central UART Sample

dejans — Tue, 26 Jul 2022 14:48:57 GMT

Hi,

Hard fault can appear at some point when you debug Bluetooth samples due to broken timing requirements of the SoftDevice Controller. In order to avoid breaking these requirements, you should consider logging instead of debugging.

Best regards,
Dejan

RE: NCS: Central UART Sample

pfishburn — Tue, 26 Jul 2022 00:54:37 GMT

Here's the most perplexing part of all and why I thought it was fixed initially:

When the dk52 board is erased and loaded with the ncs v2.0.0 version of central_uart sample, there is a repeated hardfault and reboot on bt_enable(). If the board is erased and loaded with the ncs v1.7.0 version of central_uart then the sample runs successfully.

However, if the ncs v2.0.0 central_uart is flashed (NOT erased and flashed) back to the board after running the v1.7.0 central_uart then the v2.0.0 central_uart runs successfully.

Erasing and flashing the v2.0.0 central_uart re-causes the board to hardfault reboot as described in the original post.