DFU not jumping to Application

RE: DFU not jumping to Application

Hung Bui — Wed, 16 Nov 2016 08:55:57 GMT

@mcau1:

When you update the softdevice, the application will be erased to get space for the softdevice image. You need to re-update your application. You can have a look at my presentation here. It's for older DFU bootloader but the principles are the same.

Edit: Sorry for the buttonless part, It was for another case. It's possible to update the softdevice and application at once. They won't be send in the same DFU process, but the DFU master will try to update the softdevice first and then update the application after that.

RE: DFU not jumping to Application

mcau1 — Tue, 15 Nov 2016 23:40:22 GMT

I tried creating an application plus softdevice and it seemed to work use this command rfutil pkg generate --hw-version 52 --sd-req 0x8C --softdevice SD.hex --application-version 4 --application ble_det_blue_v2_AppOnly.hex --key-file Key2.pem DetBlueSD.zip However I am not sure that the softdevice updated or not.

RE: DFU not jumping to Application

mcau1 — Tue, 15 Nov 2016 23:29:44 GMT

Ok I did not know this detail. On the Visual GDB the default is to generate the output with the softdevice in the one hex file. After removing the softdevice from the hex file it all worked well. If I want to update the softdevice to generate the package do I use this command? nrfutil pkg generate --hw-version 52 --sd-req 0x8C --softdevice SD.hex --key-file Key2.pem DetBlueSD.zip (It did not seem to work, It generated a package but after uploading it my device was stuck in bootloader mode which makes me think that I corrupted the application.) Also can I update the application and the softdevice all at once?

RE: DFU not jumping to Application

Hung Bui — Tue, 15 Nov 2016 13:53:01 GMT

@mcau1: What do you have in the blinky.hex ? Seems that you merge the softdevice with the application ?

"Application" means application, not application + softdevice.

The blinky.bin is not encrypted, it simply binary file, generated from the .hex file, since it's binary you can't "read" it using text editor.

RE: DFU not jumping to Application

mcau1 — Mon, 14 Nov 2016 21:30:09 GMT

Stuff.zip Hi, I put the blinky project in here also the package and the hex for the bootloader. The bootloader does a whole lot of LED flashing which is to help me debug it but otherwise is pretty straight and standard. It runs on the PCA10040 board. The Blinky project works but it does the same as my project when I bootload it in. I used this command line to generate the package. nrfutil pkg generate --hw-version 52 --sd-req 0x8C --application-version 4 --application Blinky.hex --key-file Key2.pem BlinkyDFU.zip The bootloader is compiled with the same key. As you can easily see the binary in the package is encrypted or corrupted. Really appreciate any help on this.

RE: DFU not jumping to Application

Hung Bui — Mon, 14 Nov 2016 09:45:32 GMT

I don't think the binary would be encrypted. Have you double check ? You can use a hextobin.exe or fromelf.exe

I would suggest you to test with the blinky example. If you can reproduce the issue, you can send me your .hex, .zip and the bootloader to analyse.

RE: DFU not jumping to Application

mcau1 — Mon, 14 Nov 2016 08:10:18 GMT

It seems like when I create the package it takes the hex input file and creates 3 files in the zip. 1 file is Binary (seems to be encrypted, I thought it was just going to be signed.) This is done by nrfutil. However after bootloading when I readback the device I see the encrypted data not decrypted. Is the problem nrfutil call or the bootloader?

RE: DFU not jumping to Application

mcau1 — Mon, 14 Nov 2016 03:27:19 GMT

Not sure why but it seems like the actual address of the reset handler is corrupted somehow. If I have a look at what my program wants at address 0x1f004 I see 0x12911 in the file generated by my compiler but after programming the package this has changed to an out of bounds 0x1exxx value. Not sure if it is the bootloader or nrfutil or what is causing this but will get to the bottom of it soon. Still appreciate any help if someone else has encounted the same issue?

RE: DFU not jumping to Application

Hung Bui — Fri, 11 Nov 2016 10:14:42 GMT

@mcau1: Have you try to run your application in debug mode and see if the PC actually jump to the reset handler in your application ?

You can also try to test with some simple example for example blinky project. Just to check if the bootloader manages to branch to the application.

RE: DFU not jumping to Application

Roger Clark — Fri, 11 Nov 2016 08:48:48 GMT

OK Your tags show as 130 110 dfu ota not S132

RE: DFU not jumping to Application

mcau1 — Fri, 11 Nov 2016 07:38:59 GMT

I am using the SDK12.1 the softdevice version is listed as S132 in the toolchain but not sure if that is correct. According to this page developer.nordicsemi.com/.../a00102.html The application can start at 0x18000 however it seems that the softdevice I am using goes up to about 0x1e740 so the address I have does make sense.

I also checked with readback that the application is loaded which it is.

Also that the softdevice is still intact. Still not sure why the code does not run at this point.

RE: DFU not jumping to Application

Roger Clark — Fri, 11 Nov 2016 05:19:22 GMT

Which SDK version are you using ? SDK 12.01 ? SD 2.x ?

Do you mean that you code is jumping to the application at address 0x1f000 ? i.e is that were you loaded your application binary (this isnt the normal address for S130 binaries is it ?)