• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 486 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

430F2274 interrupt vectors

Giuseppe Lio
Prodigy 120 points

Hi to All

I'm designing a dedicated bootloader and application Fw using a 430F2274 micro with a radio module for communications with the PC. In order to operate for the bootloader, I need at least two interrupts regarding serial port and one timer. Once the bootloader has downloaded the applcation Fw (via radio) and transferred the control to the application, I need the serial and timer interrupt vectors to point to the application Fw routines. Each time the system is switched on the bootloader takes the control for some time (in order to verify if a new update request is coming up from the PC) and after that transfers control to the application. Obviously I cannot cancel and write the flash memory where interrupt vectors are located each time I switch on the system! Do you have any suggestions ? It is possible to have int. vectors in Ram?

Thank you

Giuseppe Lio

  • 0
    Genius 3020 points

    Hi Giuseppe,

    Do you need to use interrupts in your BSL?  Could you get away with polling? 

    Barry

  • 0 in reply to blb
    Prodigy 120 points

    Hi Barry

    Thank you for your suggestion. I developed my own radio protocol that is time critical during normal data exchange but maybe that I can "relax" time constraints during BSL operation and in this way use polling instead of interrupts. I have to think about it.

    Thanks again

    Giuseppe

  • 0 in reply to Giuseppe Lio
    Guru 227245 points

    Besides using the interrupts only in one application and polling in the otehr, you can also use a forwarder.
    Example, you put the applicaiton ISR address toa known position (our own private vector table), and set a global variable. The ISR that is in the real vector table checks this variable and either jumps to the other ISR or does its job, depending on this global setting.

    I use this for my own BSL. It resides in the same 512 bytes as the vector table (and teh 512 bytes below). The application vector table is located below this (at 0xfd80). All interrupts I don't need in my BSL point to a jump table that does an indirect juump on this secondary vector table. The ones that I need point to my BSL where it checks whether the BSL is active or not, and if not, proceed to the addresses in the secondary vector table. This way, I never have to update the upper 1k of flash and still the application doesn't need to know about the BSL existence. (except for a frew additional clock cycles of ISR latency, due to the forwardign jump).
    All that's needed is to move the position of the vector table in the linker script file, to create an unused 'hole' where the real vector table and the BSL code are.

  • 0 in reply to Jens-Michael Gross
    Prodigy 120 points

    Dear Jens-Michael, your solution is "elegant". In similar way I thought about an approach where the real Vector table is in Ram, in other words the BSL, before enabling interrupts creates a jump table for its ISRs in a fixed position of the Ram and in the same way the application fw once running and before enabling again interrups, creates in the same Ram position its own jump table. In this way the flash vector table has to be filled only once with the pre-defined ram vector table position. In this case the overhead is one additional jump instead of one test + one jump.

  • 0 in reply to Giuseppe Lio
    Guru 227245 points

    Giuseppe Lio said:
    I thought about an approach where the real Vector table is in Ram

    Teh 5x/6x family offers a control bit that makes the CPU expecting the vector table at the end of ram (where usually the stack is placed).
    However, after a reset, the ROM tabel is used, so at least the reset vector there must point to the code that manages teh secondary table. Also, a vector table in ram is of course vulnerable.
    However, this option doesn't exist for any other family.

**Attention** This is a public forum