HARDFAULT handler call

RE: HARDFAULT handler call

Mikael — Wed, 10 Feb 2021 08:37:40 GMT

Thanks you Sigurd,

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

regards

Mikael

RE: HARDFAULT handler call

Mikael — Wed, 10 Feb 2021 08:32:17 GMT

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

RE: HARDFAULT handler call

Aubin — Wed, 10 Feb 2021 08:19:32 GMT

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

RE: HARDFAULT handler call

Sigurd — Wed, 20 Jan 2021 14:35:03 GMT

Hi,

[quote userid="97139" url="~/f/nordic-q-a/70661/hardfault-handler-call/290289#290289"]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?[/quote]

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.

RE: HARDFAULT handler call

Mikael — Wed, 20 Jan 2021 14:07:06 GMT

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?

RE: HARDFAULT handler call

Mikael — Wed, 20 Jan 2021 12:43:33 GMT

maybe the most dangerous one are those located in timer.c file :

/Application/Protocol/lora/system/timer.c:CRITICAL_SECTION_BEGIN();
/Application/Protocol/lora/system/timer.c:CRITICAL_SECTION_END( );
/Protocol/lora/system/timer.c:CRITICAL_SECTION_END( );
/Protocol/lora/system/timer.c:CRITICAL_SECTION_BEGIN( );
/Application/Protocol/lora/system/timer.c:CRITICAL_SECTION_END( );
/Application/Protocol/lora/system/timer.c:CRITICAL_SECTION_END( );

void TimerStart(TimerEvent_t *obj)
{
    uint32_t elapsedTime = 0;

    CRITICAL_SECTION_BEGIN();

    if ((obj == NULL) || (TimerExists(obj) == true))
    {
        CRITICAL_SECTION_END( );
        return;
    }

    obj->Timestamp = obj->ReloadValue;
    obj->IsStarted = true;
    obj->IsNext2Expire = false;

    if( TimerListHead == NULL )
    {
        RtcSetTimerContext();

        // Inserts a timer at time now + obj->Timestamp
        TimerInsertNewHeadTimer( obj );
    }
    else
    {
        elapsedTime = RtcGetTimerElapsedTime();
        obj->Timestamp += elapsedTime;

        if( obj->Timestamp < TimerListHead->Timestamp )
        {
            TimerInsertNewHeadTimer(obj);
        }
        else
        {
            TimerInsertTimer(obj);
        }
    }
    CRITICAL_SECTION_END( );


}

void TimerStop( TimerEvent_t *obj )
{
    CRITICAL_SECTION_BEGIN( );

    TimerEvent_t* prev = TimerListHead;
    TimerEvent_t* cur = TimerListHead;

    // List is empty or the obj to stop does not exist
    if( ( TimerListHead == NULL ) || ( obj == NULL ) )
    {
        CRITICAL_SECTION_END( );
        return;
    }

    obj->IsStarted = false;

    if( TimerListHead == obj ) // Stop the Head
    {
        if( TimerListHead->IsNext2Expire == true ) // The head is already running
        {
            TimerListHead->IsNext2Expire = false;
            if( TimerListHead->Next != NULL )
            {
                TimerListHead = TimerListHead->Next;
                TimerSetTimeout( TimerListHead );
            }
            else
            {
                RtcStopAlarm( );
                TimerListHead = NULL;
            }
        }
        else // Stop the head before it is started
        {
            if( TimerListHead->Next != NULL )
            {
                TimerListHead = TimerListHead->Next;
            }
            else
            {
                TimerListHead = NULL;
            }
        }
    }
    else // Stop an object within the list
    {
        while( cur != NULL )
        {
            if( cur == obj )
            {
                if( cur->Next != NULL )
                {
                    cur = cur->Next;
                    prev->Next = cur;
                }
                else
                {
                    cur = NULL;
                    prev->Next = cur;
                }
                break;
            }
            else
            {
                prev = cur;
                cur = cur->Next;
            }
        }
    }
    CRITICAL_SECTION_END( );
}

RE: HARDFAULT handler call

Mikael — Wed, 20 Jan 2021 12:36:19 GMT

Hi,

softdevice S112 v17.0.2

no timeslot but lot of critical CRITICAL_SECTION_BEGIN/END in protocol lora stack. (mac, timer, radio,...)

RE: HARDFAULT handler call

Sigurd — Wed, 20 Jan 2021 11:56:38 GMT

Hi,

What SoftDevice version and variant are you using ? Is it S112 v.7.2.0?

If yes, then it seems to be the same type of assert that is discussed in e.g. this post, devzone.nordicsemi.com/.../assert-fault-using-softdevice

Are you using the timeslot feature in the SoftDevice ?

Do you have critical regions in your code which temporarily disable interrupts globally?