hard fault after a while when connected

RE: hard fault after a while when connected

Jonas — Tue, 31 Mar 2015 13:28:50 GMT

I can confirm that using the mbed Ticker can lead to a SoftDevice Assert and a hard fault. The Ticker globally disables interrupts (for ~62us) and this can lead to a timing violation within the SoftDevice. If you encounter this problem as well, use the Nordic app_timer API instead of the mbed Ticker.

This should be solved in the mbed library, you don't want a hard fault timebomb in your code...

RE: hard fault after a while when connected

Jonas — Fri, 13 Mar 2015 14:06:58 GMT

Here is the outcome:

line_num: 0x0574 -> 1396

file_name: src\ll_lm.s0.c

SoftDevice: V7.0.0

which is according to Ulrich a known problem. Moved to Nordic support cases with this information. Thanks! :)

RE: hard fault after a while when connected

Ulrich Myhre — Fri, 13 Mar 2015 09:10:37 GMT

I am pretty sure this is a SoftDevice assert, which should call the assert callback and then produce a HardFault by doing an unaligned memory access. The parameters given to the assert callback will provide you with a file name, a line number and the current program counter. HardFaulting is intentional to stop the stack from running when in an invalid state. You could catch this by setting a breakpoint in the stack assert handler, or by writing the parameters to some transport (UART/SPI) or flash.

RE: hard fault after a while when connected

Jonas — Fri, 13 Mar 2015 06:38:18 GMT

I can confirm that with softdevice 7.1.0 the address 0x000B5E1 is causing the hard fault exception. The second device did not enter the hard-fault handler yet. Can you find out what happens there?

RE: hard fault after a while when connected

Jonas — Tue, 10 Mar 2015 14:37:15 GMT

Thanks! I haven't documented with which Softdevice Version each of these instructions were causing the hard-fault. But I will try to separate these the next days with a known softdevice version and an attached debugger. edit: I tried to catch the stack assert from mbed with a brakepoint, but it was not hit. But I will take a closer look there as well. Right now I have two devices running on a debugger, one with 7.0.0 and the other with 7.1.0. As soon as I have results I will share them to you. Thanks!

RE: hard fault after a while when connected

Ulrich Myhre — Tue, 10 Mar 2015 14:29:05 GMT

ATTN_51 will list these. CE AA D0 is an IC revision 2 chip and has support for SoftDevices up until 7.0.0, so you should be safe. 7.1.0 might also work for you if you read the migration documents carefully. There are some PANs (PAN-44, PAN-45) that required a workaround in our earlier SoftDevices, until it was removed in 8.0.0. I do not think you are affected by this.

I will try to dig up exactly what happens at those memory areas, but just to make sure: 0xB65F is for 7.0.0 and 0xB5E1 is for 7.1.0, or do HardFaults happen at both points in both SoftDevices?

Edit: I do not have easy access to the mbed library, and there is nothing interesting happening in the SoftDevice at those memory locations. Are you sure you are not receiving a stack assert? Those will produce hardfaults on purpose after firing.

RE: hard fault after a while when connected

Jonas — Tue, 10 Mar 2015 10:36:46 GMT

I opened two modules and here is what is written on the IC: N51822 CEAAD0 1422FM and another has 1423FU

Is D0 the revision? What revisions were affected?

RE: hard fault after a while when connected

Ulrich Myhre — Tue, 10 Mar 2015 09:53:31 GMT

Hi, could you please also list the IC revision or markings of the chip you are using? Our first revision had a PAN that could be the reason for this.