It seems the flash programming algorithm is a piece of code that is downloaded into the SRAM and executes from there.
But how does it get started if there is nothing yet in the vector table at 0? If the flash is erased then everything in the vector table at zero will be 0xFFFFFFFF, so how does it start executing the algorithm in RAM? (which is at 0x20000000 for example)
I want to know because I want to be able to boot from RAM as well.
The JTAG interface allows the processor to be controlled. So the JTAG interface can manually put bytes of data into RAM. And the JTAG interface can give a suitable value to PC to make the processor run the code that was downloaded into RAM.
So no need for any reset vector when you have a JTAG adapter connected.
So no - you can't normally boot from RAM. Just that some processors have an internal boot loader that can (depending on configuration) retrieve a boot image from some non-volatile interface, like an SD card or an USB thumb drive, and copy into RAM and then have that program continue with any further startup actions.
When debugging using the Keil tools, you normally have an init file for the debugger with a line that tells the debugger what PC value to use after your program have been downloaded into RAM. So same method as used when programming the chip, but instead used to let you debug applications directly from RAM without involvement of any boot loader.
That sounds reasonable but I can't get it to work.
I have tried compiling the code so the IRAM and IROM are in the system RAM space (starting at 0x20000000) and I see that the image is built correctly with the vector table at 0x20000000 and loaded correctly by uVision (this is in simulation mode).
But I can't get the G command to work (I tried G 0x20000100, the reset vector), it seems determined to load the vector table from 0 and the G command causes a fault *** error 65: access violation at 0xFFFFFFF4 : no 'write' permission
I tried setting the VTOR register but that seems to be useless since any kind of reset resets the VTOR register so the vector table offset is immediately lost.
You can't reset your processor when debugging in RAM. Or more specifically: You can't reset it and expect it to be able to start your program a second time.
You can have the debugger set the PC to the correct start address. And you can then have your own startup code configure the VTOR (I assume it stands for something like Vector Table Offset Register for your specific processor) to tell the core exactly where the interrupt vector table is.
So as long as both code + data fits in your RAM, you can debug in RAM. But the debugger must be involved to fix an initial PC value if you try to reset the processor.
Note that not all processors allows execution from all RAM memory ranges. Some RAM may be located on a separate memory bus intended for DMA transfers to/from peripherial hardware. The processor pipeline and any code cache needs integration with used RAM regions to make sure everything works as intended.
View all questions in Keil forum