ColdFire/68K Microcontrollers and Processorsのトピックvector table in FLASH (MCF5282)

vector table in FLASH (MCF5282)

SVC1 — Tue, 27 May 2008 23:21:27 GMT

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

Re: vector table in FLASH (MCF5282)

JimDon — Tue, 27 May 2008 23:58:45 GMT

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.

Re: vector table in FLASH (MCF5282)

SVC1 — Wed, 28 May 2008 05:13:39 GMT

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

Re: vector table in FLASH (MCF5282)

JimDon — Wed, 28 May 2008 06:20:14 GMT

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.

Re: vector table in FLASH (MCF5282)

admin — Wed, 28 May 2008 15:01:26 GMT

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

Re: vector table in FLASH (MCF5282)

SimonMarsden_de — Wed, 28 May 2008 16:43:08 GMT

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.

Re: vector table in FLASH (MCF5282)

JimDon — Wed, 28 May 2008 22:39:08 GMT

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).

Re: vector table in FLASH (MCF5282)

SVC1 — Mon, 09 Jun 2008 22:39:24 GMT

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