BL_SD_APP update

[Nir Barniv]

Hi.

I am trying to update soft_device version 6.0.0 to 7.0.1.

I read that because of the major version change (from 6 to 7), i must update the bootloader as well.

I created a zip file using the nrfutil, containing the same bootloader hex file with the new SD version and the application.

The problem: when the entire download process is finished (SD_BL+APP), the bootloader try to jump to the new application but get a reset instead.,

something is wrong with the application address. After the system wakes up from the reset, everything works fine.

I add the following log describing the software update while debugging the bootloader:

1. First of all, the SD_BL.hex is downloaded.

2. When download is finished the device shuts down.

3. Bootloader wakes up  and reach the sd_bl_activate().

4. The activation is success and the device is shut down.

5. bootloader wakes up and waits for the application to be downloaded.

6. application download is finished and the device is shut down.

7. bootloader wakes up and reach the app_activate().

8. the activation is success and the device is shut down.

9. bootloader wakes up and tries to jump to the valid application and a reset occurs instead.

10. after reset the device wakes up and the application loads successfully.

My question is, why the jump operation fails in step #9 ? 

Each time of ACTIVATION_SUCCESS and inside the dfu_observer in case of both NRF_DFU_EVT_DFU_COMPLETED and NRF_DFU_EVT_DFU_ABORTED,

We are using the NRF_POWER->SYSTEMOFF = 0x1; command to be able to wake up automatically (we don't want to reset the GPIOs because we

use the LDO pin - for the voltage regulation in the circuit).

Each time we get an unplanned reset, our device doesn't wake up automatically and we must turn it on manually.  

Thank you,

Nir Barniv

[Sigurd]

Hi,

Nir Barniv said:

9. bootloader wakes up and tries to jump to the valid application and a reset occurs instead.

Do you have any log output from the application ? It could be that you are entering the app_error_handler with an error-code in the application.

Set DEBUG as a preprocessor symbol (e.g by using the Debug configuration in SES):

You should also check the content of the RESETREAS register.

[Nir Barniv]

A few more questions:

1. When debugging the bootloader it gets a reset the the BL_SD is finished downloading (probably because of the reset after). It there a way to overcome it and continue with the debugging?

2. While updating the files in the application regarding SD version 7.0.1, the bootloader project stayed untouched. Is this a problem? After the BL_SD is finished downloading reset occurs and the same BL wakes up with a newer SD device version (we upgraded from 6.0.0 to 7.0.1) and waits for the application to be downloaded too. How is it possible that the bootloader works with a newer SD device without updating its related files? 

3. Is is possible to initiate a conference call?

Thank you,

Nir.B

[Sigurd]

1)

Nir Barniv said:

It there a way to overcome it and continue with the debugging?

You should be able to continue debugging through the reset. Did the debugger halt the CPU when it happened?

2) I don't think it should be an issues. If you take a look at the s140_nrf52_7.0.1_migration-document.pdf, in SDK16_folder\components\softdevice\s140\doc, there are not a lot of required changes. But to be sure, you can re-compile the bootloader with the SD 7.0.1 API header files.

3) Generally no.

You might also want to take a look at the table here:

https://github.com/NordicSemiconductor/pc-nrfutil#usage (The table that show support for different combinations, you might need to scroll a bit down).