How does the SoftDevice transfer control to the app at startup?

[Jandyman]

Hello,

I started with example apps and have got one working with the supplied makefiles, gcc, and Eclipse. I'm able to debug my code without trouble, and have succeeded in creating multiple BLE characteristics.

So I wanted to create an Eclipse "managed project" which creates its own makefile, and very carefully attempted to duplicate the behavior of the supplied makefile. I can successfully build, and the map file for the two projects is very similar. Not completely the same, because the build process is slightly different and the version of a couple gnu libs is newer than the other version (I am using the same linker scripts, though).

The problem is that when I try to run my code in the debugger, I can't even get to the breakpoint that gdb sets at main. I disabled the "continue" option in the debugger configuration so I could see the startup sequence more clearly. When the debugger starts up, the PC is set to 0x6d0, which seems to be in the SoftDevice, so it appears that the softdevice must transfer control to the app. But I have quickly realized that without an understand of how the softdevice (SD130) initially transfers control to the app, I can't get very far.

I consulted the softdevice documentation but I don't see this described anywhere.

Can someone shed some light on all of this?

[RK]

When the soft device finishes init it looks at the application vector table which is at a known address (depending on the actual softdevice) and jumps to the reset handler. That simple.

[RK]

the known address is the start of the flash section for that softdevice, so probably 0x1b000 in your case, depends on the exact version of the exact softdevice you're using and it's in the release notes. The reset handler isn't the first 4 bytes of the vector table, that's the stack address (which in your case is 0x20008000, little endian remember). The reset handler address is the NEXT 4 bytes.