Jumping Between Applications

RE: Jumping Between Applications

AnhLe — Fri, 29 Jul 2022 08:20:23 GMT

Hi Hung Bui,
Thanks for your reply, I think I don't need to change the vector_table_base anymore I only need to put the new application to the application start address that match the memory layout (for s140 is 0x27000) so I think it will be fine.

Best regards,

AnhLe

RE: Jumping Between Applications

Hung Bui — Tue, 26 Jul 2022 10:33:22 GMT

Hi Hai Anh,

sd_softdevice_vector_table_base_set() should only be called in a bootloader. Unless you start your application as a bootloader (by writing the address to UICR /MBR ), you won't be able to use the function if the softdevice already started by the MBR.
Please create a new case if you have follow up questions.

RE: Jumping Between Applications

AnhLe — Tue, 26 Jul 2022 03:20:28 GMT

Hi Hung Bui,
In case of not using softdevice is there anyway that I could change the vector table ????( I mean the softdevice and mbr are still there but I don't want to use the softdevice api)
I'm thinking like after jumping to application and the application will do the sd_softdevice_vector_table_base_set.

RE: Jumping Between Applications

Wasil — Wed, 06 Mar 2019 15:27:54 GMT

Hi Ashlesh,

I am struggling with s322 and DFU. Can you tell me what should be the target settings? I can debug that after after dfu it say jumping to : 0x0029000 but doesn't start application. Thanks

RE: Jumping Between Applications

Hung Bui — Wed, 08 Nov 2017 09:41:09 GMT

Hi AmbystomaLabs, The main vector table is still point into the softdevice vector table. Normally the softdevice will forward those interrupt that's available to the application to the application vector table, which is located at the start address of the application. sd_softdevice_vector_table_base_set() can change that and change the forward address to the address set in the call. Using this you can branch directly to the reset handler of the 2nd application you want to run.

This is the same mechanism we used to jump from application to bootloader and vice versa in our legacy bootloader. (Check bootloader_app_start() function in the bootloader or bootloader_start() in buttonless application in SDK v11)

RE: Jumping Between Applications

AmbystomaLabs — Tue, 07 Nov 2017 17:37:15 GMT

Everyone has been discussing whether or not the vector tables work out.

So just to be clear, you are saying that Ashlesh can call sd_softdevice_vector_table_base_set(SECOND_APP_START); Then do a software driven reset and everything will work out, correct?

It looked to me that all the ISR vectors are driven off of offsets from the base application start. But, if anything isn't driven from an offset and is instead set to an actual address then this method won't work.

RE: Jumping Between Applications

Hung Bui — Tue, 07 Nov 2017 12:26:28 GMT

Yes, you can do that.

RE: Jumping Between Applications

Ashlesh — Mon, 06 Nov 2017 20:18:51 GMT

dear , yes i am using a softdevice(s332) and also a DFU. so basically i can use the same function the bootloader uses to jump to the application for my application ?

RE: Jumping Between Applications

Hung Bui — Mon, 06 Nov 2017 14:57:45 GMT

@Ashlesh: Please provide more information that you use the softdevice or not. If you use softdevice, you can refer to our bootloader example in the SDK for a reference.

RE: Jumping Between Applications

Hung Bui — Mon, 06 Nov 2017 14:57:16 GMT

@Turbo: However it's possible to tell the softdevice to forward the interrupts to the application vector table using sd_softdevice_vector_table_base_set()

RE: Jumping Between Applications

Turbo J — Sun, 05 Nov 2017 16:04:24 GMT

can i just directly jump to one application to another

Yes.

But the softdevice and interrupts can make this task a lot more difficult - only the first application will handle interrupts by default, and you cannot simply set VTOR (the vector table offset register) to another address once the softdevice is running.

RE: Jumping Between Applications

AmbystomaLabs — Sun, 05 Nov 2017 15:58:21 GMT

The nRF devices just have ARM processors at their core, so functionally you can always look up the opcode for moving the PC to where ever you want and put the opcode in your application code. In this manner, you can easily switch from one application to another.

Based on the product spec they do not provide a way to permanently change the boot vector. Likely because this could get messy since the SD and MBR always sit at 0x0.

I would suggest you just nestle the two applications together. In C this is pretty straightforward since most programs operate as a series of handlers calling various functions. Having the programs together as one will make your life easier down the road as all the nordic apps are geared around 1 SD, 1 app, 1 DFU/bootloader.

If you don't like the idea of putting them together in one C project, then concatenate them after compilation and just allocate the memory yourself using the ROM settings in the compiler. Then it is still one app and the first app just switch boots to the second.