This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Redirection Vector Table on msp430f6779

Hi,

Is there any register on msp430 for redirection vector table easily? I mean some ARM processors have a register who call Base Vector Register. And this register point us where vector table starts. So we can easily change vector table adress. Is there any register like that on msp430 mcus?

Best Regards 

  • Thanks for answer, It was very usefull for me. But I wonder is this safe that relocate vector table on ram? For example  when mcu has sleep mode, what happens relocated vector table? It is makes me worry about that a little bit. Can I relocate vector table on flash memory with same methode?

    Best Regards.. 

  • If ram content is lost during LPMx.5, then all variables are gone too but the MSP also restarts and therefore the vectors are mapped again to flash. Then the cod estarts with the reset vector, so you can copy the vector table anew. If ram is powered (during normal sleep) it will keep the vectors as well as the variables. The main risk is your code, which might accidentally overwrite the vectors and crash. But then you’re already having a big problem with your code J

    BTW: the reset vector is always taken from flash. So in case of a reset, watchdog timeout or corrupted ram, the application will still be restarted.

  • Thanks for your answer Jens. It has many explaination for me. I wonder one more thing about that. TI has a document about bootloader. Here is the link:

    http://www.ti.com/lit/an/slaa600a/slaa600a.pdf

    In this document which include source code, It relocates vector table on another flash area and they call it proxy vector table. I wonder which one is the more safety for my application. Relocate flash or relocate on ram ? and why ? Can you describe that for me?

    Best Regards.. 

  • I don’t know when this ‘proxy vector table’ idea was added to the document, but I developed it (independently) about 4 years ago and discussed it a lot in an old thread back then (about custom BSLs) and several times since then.

    Basically, the original vector table points to fixed code stubs which then do a jump to the final ISR using the information from the application’s real vector table.

    So the NMI vector at 0xFFFC points to a function at 0xFE00. This ‘function’ may check where to go, or it could simply be an indirect jump, e.g. BR&0xFDFC. The application has its vector table at 0xFD80 to 0xFDFF, where it is replaced together with the application, while the area from 0xFE00 to 0xFFFF remains untouched and is never erased or updated, and it contains the ‘real’ vector table, an array for the proxy jumps, and the BSL code that is always started when the chip is reset (and usually just proceeds to the application whose ‘start address’ it gets from 0xFDFE (while the real reset vector points to the BSL code)

    Now this was for the case that the application is loaded from somewhere to low memory whenever the application is updated/switched.
    If you want to run different applications from flash without copying, then a simple indirect jump isn’t good enough. You’ll need to determines for each interrupt vector which application to call and then make an indirect jump to the proper local interrupt vector table (which then may contain 20/32 bit addresses and the ISRs can be everywhere)

**Attention** This is a public forum