DFU not jumping to Application

[mcau1]

Hi,

I have a DFU issue. Using Visual GDB IDE and gcc tool chain.

I Can get my signed application generated into zip then DFU it into the device which all works. Once I get that far I expect it to jump to the application. It passes CRC etc then goes to jump but the application will not start. The address it uses is MAIN_APPLICATION_START_ADDR is = 0x1F000 nrf_bootloader_app_start(MAIN_APPLICATION_START_ADDR);

Without the DFU I know that my application starts so it is compatible with the softdevice. Is there something I need to add to my make file? In my application It has placed the ISR_Vector at 0x1f000 which I think should be correct for the DFU.

Thank you

[Roger Clark]

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 ?)

[mcau1]

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.

[Roger Clark]

OK Your tags show as 130 110 dfu ota not S132

[Hung Bui]

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

[mcau1]

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?