This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

EV board reset after implemented buttonless DFU feature to hrs_freertos example

Hi,

I added the feature of the 'buttonless dfu' to the 'hrs freertos' using the SDK v15.3.0.

After programmed the built image to the EV board PCA10040, it could run normally.

However, when I started the DFU process using 'nRF Connect' APP, the EV board reset itself.

The attached zip file is my changes made.

Thanks!

ble_app_hrs_freertos_dfu_evboard.zip

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

    1. Put a breakpoint in the app_error_fault_handler in your project and also one brekpoint in HardFault_c_handler
    2. 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)
    3. 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.
    4. you should get the context of the hardfault or the softdevice assert from there to be able diagnose the problem. 

    /Susheel

  • 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'

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

     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

  • So does the application still stop on 0x0A60?

    Yes.

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

    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?

  • 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

  • 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.

  • 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:

    make -j9
    mkdir files 
    
    del files\freertos_app.hex
    copy ..\..\..\..\test\251837\pca10040\s132\ses\Output\Release\Exe\ble_app_hrs_freertos_pca10040_s132.hex files\freertos_app.hex
    
    nrfutil settings generate --family NRF52 --application files\freertos_app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 --key-file ..\..\..\..\dfu\private.key files\bl_settings.hex
    
    nrfjprog -e
    nrfjprog --program ..\..\..\..\..\components\softdevice\s132\hex\s132_nrf52_6.1.1_softdevice.hex
    nrfjprog --program _build\nrf52832_xxaa_s132.hex --verify
    nrfjprog --program files\freertos_app.hex --verify
    nrfjprog --program files\bl_settings.hex --verify
    nrfjprog --reset
    
    nrfutil pkg generate --application files\freertos_app.hex --application-version 2 --hw-version 52 --sd-req 0xB7 --key-file ..\..\..\private.key files\dfu_test.zip

    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

Reply
  • 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:

    make -j9
    mkdir files 
    
    del files\freertos_app.hex
    copy ..\..\..\..\test\251837\pca10040\s132\ses\Output\Release\Exe\ble_app_hrs_freertos_pca10040_s132.hex files\freertos_app.hex
    
    nrfutil settings generate --family NRF52 --application files\freertos_app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 --key-file ..\..\..\..\dfu\private.key files\bl_settings.hex
    
    nrfjprog -e
    nrfjprog --program ..\..\..\..\..\components\softdevice\s132\hex\s132_nrf52_6.1.1_softdevice.hex
    nrfjprog --program _build\nrf52832_xxaa_s132.hex --verify
    nrfjprog --program files\freertos_app.hex --verify
    nrfjprog --program files\bl_settings.hex --verify
    nrfjprog --reset
    
    nrfutil pkg generate --application files\freertos_app.hex --application-version 2 --hw-version 52 --sd-req 0xB7 --key-file ..\..\..\private.key files\dfu_test.zip

    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

Children
  • 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!!!5315.armgcc.zip

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

  • 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

Related