HARDFAULT handler call

[Mikael]

Hello,

we've got a quite unpredictable issue with a hardfault call : actually this is in this function call : app_error_fault_handler (in app_error_weak.c file)

We use SDK 17.02 and bootloader.
this is a custom board.

The issue appears when : BLE is advertising and lora data is sent (but not every time, this is a necessary but not enough condition).
We use as well timer to mange uart transfer from another device which send the data to lora, timer for ble and a timer tick.
All of these timers are created with app_timer_create() function.

Actually, as the issue is not easy to reproduce I suspect that the issue is something linked with a timing issue of one or many of this timer (it is not a code that I have developped, so not so easy to give more details).

When the issue occured, then we are in __WEAK void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info), with the following :

- id = 1  so this mean NRF_FAULT_ID_SD_ASSERT : NRF_LOG_ERROR("SOFTDEVICE: ASSERTION FAILED");

- pc = 0x00012976 ==> seems in soft device part

- info : 0

hereunder the cpu registers, sp is 0x2000fd70

hereunder the stack :

the word 0xCAFEBABE seems to be a magic number to maybe help you to debug critical issue?

the callstack is not really help me :

last, the SCB arm registers contains this : where 0xE000ED2C address contains value 0x40000000 which means in "ARMv7-M Architecture
Reference Manual" page 612 HardFault Status Register, HFSR, Purpose Shows the cause of any HardFault.

FORCED, bit[30] Indicates that a fault with configurable priority has been escalated to a HardFault exception,
because it could not be made active, because of priority or because it was disabled:
0 No priority escalation has occurred.
1 Processor has escalated a configurable-priority exception to HardFault.

Hope I give you enough details to help me in my research to find the root cause issue.

Many thanks

Regards

Mikael

[Mikael]

one more things,

I've done another test :

seems like we were in a critical section and then after this the hardfault happens :

C630 is the new pointer issue

0x27F6d is critical section ends

What do you think about this? could it be the root cause ? Waiting for sx126 wakeup in critical section, quite long, then a soft device interrupt occurred too much time and then escalates an hardfault?

[Sigurd]

Hi,

Mikael said:

What do you think about this? could it be the root cause ? Waiting for sx126 wakeup in critical section, quite long, then a soft device interrupt occurred too much time and then escalates an hardfault?

Yes, that seems likely. You mentioned that you are advertising when this happens. You could e.g. stop the BLE advertising before you call SX126xWakeup(), then start the advertising again when SX126xWakeup() is done. Another option could be to make this SX126xWakeup()/SX126xWaitOnBusy() interrupt driven instead, i.e. trigger a GPIO interrupt when the chip is ready.

[Aubin]

Hi,

I recently faced the same "SOFTDEVICE: ASSERTION FAILED" error when using both BLE and LoRa on an ISP4520 chip (based on nRF52832 and SX1261 chip).

The problem came from the CRITICAL_SECTION which mask both peripheral and SoftDevice IT resulting in "SOFTDEVICE: ASSERTION FAILED".

This is thus caused by a conflict between the BLE SoftDevice and the way LoRa is implemented in the module ISP4520. I think BLE SoftDevice and LoRa stack are not meant to be used together.

The LoRa stack CRITICAL_SECTION should not mask SoftDevice IT. A solution is to replace:

void BoardCriticalSectionBegin(uint32_t *mask)

{

    *mask = __get_PRIMASK( );

    __disable_irq( );

}

void BoardCriticalSectionEnd(uint32_t *mask)

{

    __set_PRIMASK( *mask );

}

By:

#include "app_util_platform.h"

static uint8_t __CR_NESTED = 0; 

void BoardCriticalSectionBegin(uint32_t *mask)

{

    app_util_critical_region_enter(&__CR_NESTED);

}

void BoardCriticalSectionEnd(uint32_t *mask)

{

    app_util_critical_region_exit(__CR_NESTED); 

}

in the file board.c provided by Insight SiP for module ISP4520.

Using that, SoftDevice IT are not masked, and SoftDevice does not fall in "SOFTDEVICE: ASSERTION FAILED".

I hope this will help you solve your problem,

Have a nice day,

Aubin

[Mikael]

Hi Aubin,

Thank you very much for this valuable information !

Actually we were working as well with ISP4520.

We will use your solution.

Thanks again.

Mikael

[Mikael]

Thanks you Sigurd,

following support from Aubin is very interesting and will probably resolved my issue.

regards

Mikael