HARD FAULT during xTaskResumeAll after ending a DFU session and disabling the Softdevice

Hello Rafalino,

Did you try enabling the softdevice again before you resume the rest of the threads? Does that change anything?

Best regards,

Edvin

Hello Edvin,

We did not try enabling the Softdevice after we disabled it. 

Our Application uses the RADIO all the time so we can't have the Softdevice running while we run our application.

We make sure that the Softdevice is disabled by checking the Softdevice state using  NRF_SDH_STATE_OBSERVER.

Rafalino.

Hello Edvin,

We did not try enabling the Softdevice after we disabled it. 

Our Application uses the RADIO all the time so we can't have the Softdevice running while we run our application.

We make sure that the Softdevice is disabled by checking the Softdevice state using  NRF_SDH_STATE_OBSERVER.

Rafalino.

Oh, sorry. I thought you said you were using the softdevice in your application, but I see that you are not using the softdevice in the application. Only the Radio.

So your DFU procedure: When this issue occurs, is it after a successful DFU? Or was the DFU aborted? What bootloader are you using? Background DFU or "normal" DFU (where the transport happens in the bootloader)? Does the error happen after you reset the device as well, or only directly after a DFU? 

BR,
Edvin

Hi Edvin,

Let me clarify 

Our application uses the chip's RADIO to send BLE beacons at times that we want to control so during that part of the application we do not enable the Softdevice.

Since we have several chips in our setup , we wanted to use Nordic's DFU service to upgrade one chip from another one over the air.

Let's say chip A has version 3 and chip B has version 2.

So we send a command from chip A to chip B to move to bootloader (a special BLE beacon).

Then chip B reboots and stays at bootloader while chip A disables our primary application (by suspending most of its freeRTOS tasks and also the scheduler itself by calling vTaskSuspendAll ) and then enables the Softdevice in order to send application version 3 OTA to chip B.

Up until this part, everything works smoothly and we are able to send all the application over to chip B.

The problem occurs on chip A after we finish the OTA and we disable the Softdevice , resume our tasks and call xtaskresumeall to resume the scheduler.

During xtaskresumeall  we get Hard fault : 

Do you have any suggestions what can cause that ?

Ah, I see. Thank you for clarifying

Can you reproduce it once more (reproduce it with your latest build, so that the addresses from the log are correct), and see what is found at the address that the log is claiming contains the hardfault. In your original post, that would be 0x00029350.

Then, make sure that the tool arm-none-eabi-addr2line is in the environment path on your computer. In my case, it is found in C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3\bin\arm-none-eabi-addr2line.exe, so I added "C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3\bin\" to my environment path. To check whether it is in your environment path or not, you can use the command "where arm-none-eabi-addr2line". If it replies with the destination, that is fine. If it is not found, you need to install it and/or add it to your path. It is part of the GNU ARM embedded toolchain.

Then, go to your build folder for your application. I see that you are using Segger Embedded Studio, so that would be the "Output" folder, and locate the .elf file. Using the ble_app_uart example for demonstration, you can use this command to find out what function that is located at the Hardfault address:

arm-none-eabi-addr2line -e Output\Release\Exe\ble_app_uart_pca10056_s140.elf 0x00029350

Does it point to list.c: 193? If so, can you try to set a breakpoint there to see what happens right before the hardfault?

Hello Edvin,

As you can see from the screen shot that I attached (that has the Call stack):

it is coming from list.c  and it was called from timer.c : 

/* The timer is in a list, remove it. */
( void ) uxListRemove( &( pxTimer->xTimerListItem ) );

I suspect some timer was not stopped/cleared by the Softdevice but I can't figure out which one.

Rafalino

Please make sure that you are handling all the return values correctly from the API especially app_timer_stop