"I just need to implement a bootloader" he said, unaware of the fact that the Cortex M0 core lacks a vector table offset register, making switching between two user programs a lot harder 🫠
@cato Hm, how does it work though? Is there already a small shim in the application that redirects execution from the vector table in flash to SRAM? Think that would be my preferred solution if I did not have VTOR available.
Or does the MCU in question have some type if hardware address translation/remapping capabilities that can be used to map some SRAM where the vector table would be?
@Toble_Miner the linker script says "place vector table in sram" because that's where the MCU expects it, so the internal startup code handles copying it from flash to sram when I jump to the reset vector
@cato Oh, that is pretty interesting. Is there a second copy of the vector table in flash for initial startup to fetch top of stack and reset vector? Guess the SRAM would usually not be initialized at that point.
@Toble_Miner that's the point I haven't quite understood yet. The datasheet says the vector table is in ROM (actual ROM, not User Flash) at 0x00000000 but is remapped to the start of SRAM, except the stack pointer and reset vector, which are at the start of User Flash. So I guess at the very start it starts off in user flash and the reset vector points to the startup code that copies the vector table to SRAM. Not quite sure how the ROM plays into this
Turns out :D if you just branch to the reset handler of the application code :D it already loads the vector table into RAM :D and sets up everything :DDD I don't need to do the whole "manually edit the vector table" thing :DDD
@cato When you're exporting the symbol table from your compiler along with the binaries only to live-patch your code before executing -- then things get messy x)
Add comment