vector table in FLASH (MCF5282)

[SVC1]

Hi,

Is there a reason why in all examples I have seen, the vector table is copied
into RAM (either internal SRAM or external SDRAM)?

Can’t we leave the vector table in internal flash (CFM)?

If so, what are the pros and cons of having the vector
table in RAM or ROM?

SVC

[SVC1]

Thanks.

On the same topic, let's say I opt for keeping the vector table in flash, and would like my application to be at address 0x8000, how do I set up the VBR to this address (since the lower 20 bits are not implemented)?

Simon

[admin]

Hi SVC,

I believe the pros have not been mentioned. I can think of one advantage only: vector table in flash saves you about 1KB of RAM, which can be significant in some applications.

Regards,
- scifi

[SimonMarsden_de]

Having the vector table in Flash works fine, but Jim is correct to say that copying it to RAM is more flexible.

However, one other advantage of leaving the table in Flash : a rogue program cannot corrupt the vector table by scribbling over it.

[JimDon]

---

However, one other advantage of leaving the table in Flash : a rogue program cannot corrupt the vector table by scribbling over it.

---

That is a good point - however the rouge program will then be scribbling on your variables. You can say one is better/worse that the other, but that is a tough call. A bug is a bug, and will bite you in the end. A least if you scribble the vector table, good chance your program will crash sooner (like while still in development). This might sound like an odd thing to say, but crashing sooner in an obvious way is better than later (after 10,000 units have shipped) in some tricky way that is hard to notice.

One thing I do is set it up so exceptions will print on the uart, and then leave it hooked up to a terminal program during development. I have already found some bugs that way that I might have never noticed.
Like spurious interrupts - it was harmless, but still undesired (I was resetting up a timer, and I cleared the pending bit after the interrupt controller had already seen the interrupt, then when the iack cycle comes the interrupt has already been cleared, so the module does not acknowledge it).

[JimDon]

I like it ram, so when I call a routine to initialize a module it can put it's vector in. Also, I sometimes use a different handler.
And, if you are re-burning flash and interrupt could cause a crash.
Having said that, I know of no reason it will not work in flash, you will just have adjust the start up code.

[SVC1]

Thanks Jim, but I don't understand your first comment.

I like it ram, so when I call a routine to initialize a module it can put it's vector in. Also, I sometimes use a different handler.

Can you please elaborate a little bit more?

Thanks,

Simon

[JimDon]

Sure, I have code that say initializes a DMA Timer channel. The initialization code sest up the module and puts the vector in the interrupt table, upon initialization. If I don't use that module, then the vector stays pointed to the default handler.
It' just a nice to encapsulate code so that when you use it no worries about the vector. I pass in a pointer to a "user" function that will actually handle the interrupt, again so I don't have to think about how you acknowledge it. Kinda of a little framework so once you figure things out you don't need to think about it again.
When you use that code again in a different program, you don't have to modify the exception table.

Some times you may wish to change to interrupt handlers to a different routine, so you can just change where the vectors points.