NCS: Central UART Sample

[pfishburn]

Hi,

I had previously posted this as an issue and self-resolved but it has re-occurred so I am re-opening the issue.

The central_uart sample hardfaults when bt_enable(NULL) is entered. I can use the debugger and step over the first couple lines but stepping over bt_enable causes a hardfault. In my uart output window all I see is: 

*** 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 ***
*** 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 ***
*** 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 ***
*** Booting Zephyr OS build v3.0.99-ncs1 ***

I am using nRF Connect SDK v2.0.0 on nrf52dk_nrf52832. I have had no issues with any other examples in the mesh examples or the peripheral uart example.

Curiously, the connect sdk v1.7.0 version of central uart appears to be working correctly.

Is there a bug in the sample for NCS v2.0.0?

Thanks,

Phillip

[pfishburn]

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.

[dejans]

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

[pfishburn]

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.

[pfishburn]

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

[dejans]

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

[pfishburn]

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