• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 81 subscribers
  • Views 1984 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.

Interrupt vector in the RAM: any cons using this ?

Babbeul bbeuoki
Prodigy 190 points

Hello,

In my quest to master the MSP, I recently stumbled upon an interesting feature (which i think i managed to use): relocating the interrupt vector in RAM (SYSRIVECT).


Do you, dear community, think of any cons for using the IV in the RAM ?

  • Might it be more prone to unexpected bitswaps or any kind of strange behaviour that the RAM might have that would not affect flash ?
  • Is it NOT recommended for some reasons to use IV in the RAM in the long run ?

Thank you a lot for your insights !

Cheers

  • 0
    Guru 317320 points
    The SRAM is not any less reliable than the flash. (Flash could wear out, but I doubt you'll manage that for the flash cells that store the interrupt vectors.) Additionally, reading SRAM uses slightly less power than flash.

    In practice, the biggest problem appears to be moving other data (i.e., the stack) out of the way.
  • 0
    Guru 46710 points

    >Might it be more prone to unexpected bitswaps or any kind of strange behaviour that the RAM might have that would not affect flash ?

    If you are afraid of bitswaps or any kind of strange behaviour that the RAM might have, then you shall not use RAM at all, not even for stack where return address will be stored when IRQ fires. You see what I mean? ;)

    >Is it NOT recommended for some reasons to use IV in the RAM in the long run ?

    Kinda. Moving IV into RAM needs additional code, thus more source code to write. As we all know - the more you do domething, the more chances are that you do some mistake sooner or later. Not to mention that you just possibly waste RAM, flash and your time including.

    Well.. indeed there could be some rare applications which could require as low as possible IRQ latency and/or change of IV during runtime for some strange reason.

  • 0
    Guru 58965 points
    In addition to put IV in RAM, you could also run code in RAM, or allocate constants in RAM.

    Normal practice is, you do not intentionally change IV, code, or constants. Thus you are not gaining the advantage of being able to change them intentionally, you only opened the possibility of incidentally changing them.

    However, if there is a need to change IV intentionally, there is nothing wrong with put IV in RAM. You will need code and constants to set it up thou. Those code and constants probably should not be in RAM, otherwise you get yourself a catch-22 situation.
  • 0 in reply to old_cow_yellow
    Guru 16361 points

    old_cow_yellow said:
    Normal practice is, you do not intentionally change IV, code, or constants. Thus you are not gaining the advantage of being able to change them intentionally, you only opened the possibility of incidentally changing them.

    Yes, that's a very good point.

    If you do put the interrupt vectors and/or service routines into RAM it may be worth considering using a memory layout where the stack doesn't grow towards them: http://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/

  • 0 in reply to Robert Cowsill
    Prodigy 190 points

    Thank you so much for your reviews here !

    Well i already overcame the problem cited above (namely, moving the stack away from the IV, i did it with the linker script, basically) and everything seems fine. And yeah, i was planning to move the IV to RAM so as to be able to change it in my app, and given the specific case, moving the IV to RAM looked easier, so that's perfect.

    Thanks for the insight on RAM reliability Ilmars :) that's totally true... if I don't trust RAM then i should store my stack in flash.... :D bull's eye heheh (... well i did not think enough before posting ;) my bad)

    Robert, I don't know whether it is the "best solution" but what i did was:

    • Write my IV a RAM top (what is required by the microcontroller so that SYSRIVECT works)
    • Change the top of stack address so that it does not overlap with the vector (This way, the stack should not grow towards the IV, it should grow the other way around)
    • i.e.: IV from RAM top to RAM top - sizeof(IV) and stack allocated at RAM top - sizeof(iv) -1 and will grow with decreasing addresses, so no way it can crash into the IV

    Anyway, thanks a lot everyone for your insights and interesting advice !

    Cheers !

**Attention** This is a public forum