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.

[Jandyman]

How do I figure out what that "known address" is (for SD130)? From the map file of the app, I would guess the address is 0x1b000, which is the beginning of the FLASH section. The contents of location 0x1b000 is 0x800020. However, there is no executable code at 0x800020, and this doesn't correspond to any symbols in the .text section of the app makefile. So I have to conclude that the "known address" is not 0x1b000. This is all on the version of the code that works properly. Unless I can figure out how this works on the code which works properly, it is going to be hard to figure out why the non-working code is different. Is this documented anywhere?

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

[Jandyman]

Excellent. Thanks so much. The code now makes sense and I see that the destination is the Reset_Handler of the app. Now if could just get the Eclipse debugger to display little endian in memory window!