I found this pretty old post devzone.nordicsemi.com/.../switching-between-apps-with-dual-bank . Currently I am building two different zephyr projects and selecting between them at boot time, using this code. The code handles interrupt reset conditions which I really don't think I care about, but it's not hurting anything, so no big deal. There is also some bare metal ARM boot code in this.
Essentially the code uses the offsets provided to pull the stack and reset pointer for each program. I am pretty sure that the initialization of a zephyr program holds no expectation to the state of the CPU other than it has to be in the initial boot mode.
I was curious, I don't know if this is a fair question since in is really about zephyr, however there is involvement of the BLE libraries. I am wondering if there are any specific assumptions (that I can know about of course) being made about the state of the processor when a Nordic Bluetooth Program is involved?
Why am I doing this? It's simple and I understand it. I came across a better way to handle this, but I will stick with this in the short term.
To simplify, the question is: " Are there any specific assumptions (that I can know about of course) being made about the state of the processor when a Nordic Bluetooth Program starts from reset? Can I just relocate them and jump to them?"
I understand if this is too esoteric a question to answer. I have been deliberating for a week if I should even bring it up.
Enclosed the code because it isn't exactly secret information.