This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex M0 Vector Table and Bootloading

Hi guys,

Does the M0 always default to 0x0 when an interrupt triggers? I understand VTOR is not available in M0 for relocation of the tables.

Can I copy the application vector table just the vector table to beginning of SRAM and remap the SRAM to 0x0 so that during interrupts it will always go to the SRAM to fetch the vectors? Is that the right way to relocate the vector?

If I understand it correctly the REMAP is mainly used for

1. Power up fetch of first MSP and Reset Vector

2. After powerup --- allows interrupt vectors (assume M0 always goes to 0x0 to fetch vectors) to be fetched from the REMAPed addresses.

3. It masks out accesses to the actual memory located on physical 0x0 on the bus.

It is not really useful for actual application program because the PC can be explicitly controlled with branching/jump instructions.

Hypothetically, if I do not place any memory blocks on 0x0 and then use REMAP to switch some other blocks at say 0x1 or 0x2 into 0x0 as needed, would this be a good way to switch the location of the vector table?

For example

SRAM at 0x1

FLASH at 0x2 ((Bootloader (at beginning)+ application Prog))

At power up Remap FLASH to 0x0 -- Run bootloader Vectortable + code; copy AppProgram Vector table to SRAM.

REMAP SRAM to 0x0 (application vector table active), jump to Application at FLASH (now mapped to 0x2)

and so on.

It would seem possible to run the MCU and use the REMAP in this way, but would appreciate any feedback from more experienced designers.

Initial thoughts were obtained from this thread regarding relocating vector tables

community.arm.com/.../36527

  • So a simple way of doing the bootloader is to put your vector table for the bootloader in flash at 0x00, then the vector table for your main application at some known flash address like 0x2000, ie the start of of your application code in flash memory. 

    When you boot into the bootloader you set an SRAM flag/variable to indicate you are in bootloader. Then when you exit the bootloader you set the flag to indicate you are not in bootloader, and then you set stack and jump to the app reset vector. 

    For your exception handlers in the bootloader you check the flag to see if you are in bootloader. If you are not in bootloader you get the exception vector from the application vector table and branch to that code and run that exception handler.  This adds a few cycle of latency to each exception handler but will work.   This is the way we did bootloaders before processors had VTOR type of features. 

    Note also that you can check the IPSR register to see which interrupt is active that you can write a generic exception handler to handle all the exceptions you do on not explicitly use in the bootloader.  Basically in the generic handler you use the IPSR to get exception number and then using that get offset into the application exception table to find the correct application exception handler to call.   

    This method basically allows you to remap your vector tables in firmware.