EV board reset after implemented buttonless DFU feature to hrs_freertos example

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Edvin — Tue, 07 Jul 2020 09:21:17 GMT

Hello,

Good news. I continued the debugging, and I tried with nRF Connect for iOS (initially I used nRF Connect for Desktop). I received the same hardfault as you had (I believe). As Susheel said, I set a breakpoint in HardFault_Handler() in hardfault_handler_gcc.c. After the execution stopped on 0x00000A60, I hit "continue", and it stopped in HardFault_Handler():

So step one is done.

The hardfault handler will call NVIC_SystemReset() in HardFault_c_handler() -> HardFault_process(), but as you can see, if you look at the implementation, it will try to print a lot more before that, but it doesn't have time to do so before the reset. So I changed:

/*lint -save -e14 */
__WEAK void HardFault_process(HardFault_stack_t * p_stack)
{
    // Restart the system by default
    NVIC_SystemReset();
}

TO:

/*lint -save -e14 */
__WEAK void HardFault_process(HardFault_stack_t * p_stack)
{
    // Restart the system by default
    //NVIC_SystemReset();
    for(;;)
    {
      NRF_LOG_PROCESS();
    }
}

Then this was printed in the log:

<info> app: HRS FreeRTOS example started.
<info> app: Fast advertising.
<info> app: Connected
<info> app: Received indication state 1
<error> hardfault: HARD FAULT at 0x00000000
<error> hardfault:   R0:  0x20007D8C  R1:  0x20007D84  R2:  0x00000008  R3:  0x00000000
<error> hardfault:   R12: 0x20007D90  LR:  0x0003B049  PSR: 0x60000000
<error> hardfault: Cause: The processor has attempted to execute an instruction that makes illegal use of the EPSR.
<info> app: nrf_sdh_ble_enable() err:0 ram_start:0x20002220
<info> app: HRS FreeRTOS example started.
<info> app: Fast advertising.
<info> app: Connected
<info> app: Received indication state 1

What we are looking for here is the link register: LR: 0x0003B049. NB: These numbers may differ when you compile, so check your own files.

I checked the ble_app_hrs_freertos_pca10040_s132.map file that is generated when you compile. I found the line:

 .text.nrf_dfu_set_adv_name
                0x000000000003b038       0x24 Output/ble_app_hrs_freertos_pca10040_s132 Release/Obj/ble_dfu_unbonded.o

So the hardfault occured in the function nrf_dfu_set_adv_name.

You can use the addr2line tool, which I did, if you want to find even more details:

C:\Nordic_Semiconductor\SDKs\SDK\15.3.0\examples\test\251837\pca10040\s132\ses\Output\Release\Exe>arm-none-eabi-addr2line -e ble_app_hrs_freertos_pca10040_s132.elf 0x03B049
C:\Nordic_Semiconductor\SDKs\SDK\15.3.0\components\ble\ble_services\ble_dfu/ble_dfu_unbonded.c:61

So the issue is located in

ble_dfu_unbonded.c line 61.

I tried to set a breakpoint right before the call to nrf_dfu_set_adv_name() this was hit, this was hit when I tried to perform the DFU, and then I tried to set a breakpoint on the line after, line 152 which was never hit. So the issue was the call to nrf_dfu_set_adv_name().

Now, this is an SVCI call (similar to softdevice calls), because this name is set by the application, but is used by the bootloader after the next reset. I happen to know that iOS uses the name to identify the device after reset, because the iOS doesn't allow the applications to see the advertising addresses, while Android and nRF Connect for Desktop gives the addresses. This is why I didn't see it in nRF Connect for Desktop, and you wouldn't notice this issue with Android.

What you are missing is the lines close to the beginning of main() in ble_app_buttonless_dfu:

    ret_code_t err_code = ble_dfu_buttonless_async_svci_init();
    APP_ERROR_CHECK(err_code);

I added these lines right below log_init() in your main() function, and then it worked as expected. This function will set the asynchronous SVCI calls, such as nrf_dfu_set_adv_name().

Add these lines, and your hardfault should disappear.

BR,

Edvin

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Terry — Tue, 07 Jul 2020 06:55:03 GMT

PCA10040

1.2.4

2018.16

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Edvin — Tue, 07 Jul 2020 06:52:49 GMT

What is EVB? I know it probably is short for Evaluation Board, but what type of board is it? Is it the nRF52DK?

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Terry — Tue, 07 Jul 2020 03:19:53 GMT

NO HOPE.

I did exactly the same.

After I start the DFU on iOS, the EVB reboot. The APP is running but cannot update the FW.

Seems the EVB cannot reboot to bootloader!!!devzone.nordicsemi.com/.../5315.armgcc.zip

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Edvin — Mon, 06 Jul 2020 13:23:02 GMT

Hello,

Sorry, I didn't notice that it was attached.

So I tested your project (compiled with SES) in SDK15.3.0 with an unmodified bootloader, running on a DK. I was not able to reproduce the issue.

Can you try to unzip the project that you attached in the path "test\251837" (create this folder) in the examples folder in the SDK, and compile it.

Then generate your own private.key and dfu_pulbic_key.c in the default location, and run the following .bat script from SDK15.3.0\examples\dfu\secure_bootloader\pca10040_ble\armgcc:

devzone.nordicsemi.com/.../test.bat

Then try to perform the DFU with the file generated in:

SDK15.3.0\examples\dfu\secure_bootloader\pca10040_ble\armgcc\fikes\dfu_test.zip

Does that start advertising on a DK, or not? If you don't use a DK, can you try to run it on a Nordic DK?

BR,

Edvin

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Terry — Mon, 06 Jul 2020 11:46:59 GMT

Hi Edwin,

Thanks.

I have already attached my project in the 1st thread and you can find it there.

I just perform the DFU using the iOS nordic APP. After I press "start",the problem occurs.

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Edvin — Mon, 06 Jul 2020 09:44:37 GMT

So it never hits any of the breakpoints in app_error_fault_handler() or HardFault_c_handler()?

Due to holiday season in Norway, we are really low on capacity. Is there any way for me to reproduce this issue? If so, can you give me a detailed description, and zip your project so I can easily reproduce it, preferably with an unmodified bootloader from the SDK and your project. Perhaps I can see where the hardfault handler is pointing to.

For your sake, I will be looking at the SP (stack pointer) and see what functions in the .map file it points to in 0xa60 and 0xa80, so if you want to give this a go, you can try this as well.

Best regards,

Edvin

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Terry — Fri, 03 Jul 2020 02:54:15 GMT

[quote userid="26071" url="~/f/nordic-q-a/62905/ev-board-reset-after-implemented-buttonless-dfu-feature-to-hrs_freertos-example/257818"]So does the application still stop on 0x0A60?[/quote]

Yes.

[quote userid="26071" url="~/f/nordic-q-a/62905/ev-board-reset-after-implemented-buttonless-dfu-feature-to-hrs_freertos-example/257818"]Does it still stop on 0x0A60 after you place those breakpoints? If so, press "continue" (F5) and not "Step into". What happens then?[/quote]

Yes. Break at 0x0A60 first. After pressing F5, break at 0x0A80. Then pressing F5 again, the system reboot.

Does that means the system cannot reboot to bootloader?

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Edvin — Wed, 01 Jul 2020 12:05:09 GMT

[quote user="terrychan"]After I setup the breakpoints on app_error_fault_handler() and HardFault_c_handler(), the FW could not be triggered by those breakpoints.[/quote]

So does the application still stop on 0x0A60?

The ble_evt_handler() is likely to be called when you start performing a DFU process. It doesn't mean that the issue is related to the first ble event.

Does it still stop on 0x0A60 after you place those breakpoints? If so, press "continue" (F5) and not "Step into". What happens then?

BR,

Edvin

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Terry — Mon, 29 Jun 2020 02:08:44 GMT

Hi Susheel,

After I setup the breakpoints on app_error_fault_handler() and HardFault_c_handler(), the FW could not be triggered by those breakpoints.

Then, I checked the .map file and then setup a breakpoint on ble_evt_handler(). The FW stopped when I started the DFU process on the mobile phone.

Please find the captured screens.

Then, press 'Step Into'

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Susheel Nuguru — Fri, 26 Jun 2020 07:26:38 GMT

0XA60 is the Hardfault handler in the MBR. Please do the following

Put a breakpoint in the app_error_fault_handler in your project and also one brekpoint in HardFault_c_handler
Run your program again in the debug mode so that you have a hit at the breakpoint and the program pauses at 0xA60 (like the snapshot you provided)
Press F5 or continue the program from this point so that the MBR calls the softdevice hardfault handler and that in turn calls your application HardFault_c_handler.
you should get the context of the hardfault or the softdevice assert from there to be able diagnose the problem.

/Susheel

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Terry — Fri, 26 Jun 2020 06:20:50 GMT

Hi Susheel,

I have setup all breakpoints where NVIC_SystemReset is calling.

However, this problem occurred without triggering any breakpoint.

Please find the attached screen capture.

RE: EV board reset after implemented buttonless DFU feature to hrs_freertos example

Susheel Nuguru — Thu, 25 Jun 2020 09:23:31 GMT

Hi Terry

Have you attempted to get the context of the reset? the reset can only happen to a call to NVIC_SystemReset and you can check in your code where you have these and put a breakpoint there. Run your code in debug mode and to get some context on why this reset happens. If you can get the context of the reset, I would try to assist you further.