Secure Bootloader fails to start its application on SDK 15

[Prakash Rajiah]

Hi, I am using:

SDK v15 with nRF52840 chip running in soft device s140. I am Using Segger Embedded studio. 

I want to update a application( Say Blinky) thorugh DFU. I perform the following steps:

1. Erase device

2. Program SD140 using nRFgo Studio

3. Compile the bootloader with my own keyfile ( key2.pem)

4. Flashing the bootloader (device is then advertising as "DfuTarg"

5. Compiling my application

6. Copying the generated Hexfile (app.hex) to the nrfutil folder

7. Running nrfutil with: nrfutil.exe pkg generate --application blinky_pca10056.hex --key-file key2.pem --hw-version 52 --sd-req 0xA9 --application-version 0x00 output.zip

8. Transfering output.zip to my mobile phone

9. Connecting to "DfuTarg" in nRF Connect app

10. Choosing "DFU" in the upper right corner

11. Choosing the file "output.zip"

12. Progress is displayed as graph- Successful 

13. Application has been sent successfully. 

14. After "Disconnecting" is shown in the app, the device is still advertising as "DfuTarg", not running my application

 

The boot loader fails to boot the application start address and stops there as shown in the image. Can some one help me in this? I found couple of discussion in other forum and that's been unanswered. 

[Einar Thorsrud]

Hi,

Everything looks fine from the log in the screenshot, indicating that the application should have been started.

How have you verified that the device advertises as "DfuTarg"? Is the device really in bootloader DFU mode? The reason I ask is that for example iOS tends to cache the device name of peer devices and use the old name for some time even if it has changed. Have you verified with a debugger that the application is not started?

[Prakash Rajiah]

Oh sorry.!!! The bootloader program stops and freeze there and doesnt advertise nor starting application. the example was just a blinky example in the SDK 15. It was expected to blink its LEDs. The example works when i debug it in normal via debugger.   

[Einar Thorsrud]

The sensible way to understand what is going on is to use a debugger to understand what happens in the bootloader. Do you use the debug version of the bootloader also in the case there the bootloader does not start the application? If no, can you switch to the debug version? Then, please upload the log to this case (same as can be seen in the non-relevant screenshot that you uploaded in the original question). Also, can you halt the application and see what state the application is in when it should have started the application? Is it in an error handler? What is the value of the stack pointer?