SAM3X8E ROM "Boot Program" question..

(Outside the context of the Arduino IDE..) I'm trying to use the SAM3X8E "Boot Program." I'm able to XMODEM my program to SRAM (with "S,#"). But when I try to run it (with "G#"), it just hangs.

I'm compiling my program with YAGARTO.

I've done this sort of thing (with the Atmel ROM boot program) many times in the past: with the Netduino (AT91SAM7X512) and the MiniBox picoSAM9G45 (AT91SAM9G45). And I've built Cortex M-3 bootloaders for the Netduino 2 (STM32F205).

A LONG time ago, I remember (though, for the life of me, I can't remember WHERE) reading some sort of "principles of operation" for the boot program. I seem to remember (?) that the "Go" command does a lot more than just jump to the specified address. (But I may be confusing the 7X's (and 3X's) "boot program" with the 9G's NVM boot program.) I was hoping that my program could "pick up" from where the boot program "left off" (i.e., clocks setup, stack setup, PIO PINs setup, UART setup, ...).

Can anyone comment on what the 3X ROM boot program REALLY does? And are things different for the 3X (than, e.g., the 7X), because of the (old) ARM vs the (newer) Cortex M-3 architectures? For example, do I need to "Go" to "+1"?

And what're the minimal "setup/initialization" steps my software has to do "out of the gate"?

Thanks,

Tom

Answering my own question...

The problem is that the "target" (address) of the SAM-BA G(o) command is not a code address.. or a Thumb2/CM3 "address+1." The Go target has to be an SP-PC pair (where the PC is the address+1).

k2tom:
Answering my own question...

The problem is that the "target" (address) of the SAM-BA G(o) command is not a code address.. or a Thumb2/CM3 "address+1." The Go target has to be an SP-PC pair (where the PC is the address+1).

Thanks HEAPS k2tom. You pointed me in the right direction!
To clarify though...
The 'target' of the G(o) command is intended to be the base address of the chosen EXCEPTION TABLE.
(The first entry in the table is the initial stack pointer and the second entry is the reset-handler address).
Given your post above, I spent a while doing stuff like:
G20088000,000801EF#
(In this case, 000801EF was the 'pc+1' address of my 'reset' function.
However, I finally tried using:
G00080000#
(where 00080000 is the address of the vector table in Flash. It works beautifully now!)

P.S.
The reason I wanted to do this at all was to grab a copy of the SAM-BA boot rom code.
It seems that when I used the '-b' flag of BOSSAC to get the CPU to boot from flash, the CPU was also mapping the flash over the top of the internal CPU boot ROM at 0x00000000.
By leaving out the -b BOSSAC flag (thereby still booting into SAM-BA mode), my code is still in flash at 0x00080000 with the SAM-BA rom code sitting nicely at 0x00000000-0x00001FFF. (It's noteworthy to mention that the boot rom code looks to be repeated every 0x2000 bytes (8k)
With a simply G00080000# command, I could fire up my code that sends back all of the SAM-BA boot rom code!

EDIT:
Having now 'dis-assmbled' the first few entries in the ROM vector table, I can now see that they all point to code at 0x0010XXXX
Soooo, looking at the datasheet (yet again!), I now notice that the internal ROM is always visible at this base address... D'Oh! The 'boot flag' in the GPNVM bits simply determine which code is mapped onto address 0x00000000.
(However, please don't forget errata 49.2.1.3 which has a small issue if you're booting from the SECOND bank of flash!)

Accidental duplicate... Sorry