interrupt behavior in RAM vs. CONSOLE_RAM targets in CodeWarrior for ColdFire 6.4 for M52233DEMO

[regehr]

This question is regarding interrupts behaving differently in the RAM and CONSOLE_RAM compilation targets with CWCF6.4 when targeting an M52233DEMO board.

Starting with the "hello world" app I wrote very simple code to generate an interrupt when PIT0 is reset.

When I use the RAM compilation target, the interrupt handler fires as expected (periodically blinking an LED on the demo board).  However, when using the CONSOLE_RAM target, my application throws a bus error when the interrupt fires.

But here is the odd bit:

To link in my interrupt handler I pointed vector119 in mcf5xxx_vectors.s to my handler.  When I use the CONSOLE_RAM target, it seems that this vector table is not even being linked into my application: I can enter a function that does not exist for vector119 and no linker error is signaled.  Using the RAM compilation target, I get a linker error as expected if a vector refers to a function that does not exist.  And furthermore, as I said, my handler is in fact the one that fires when PIT0 expires, when I use the RAM option.

My question is: Is there something obvious I am missing about the CONSOLE_RAM compilation target, where it grabs the vector table from somewhere other than mcf5xxx_vectors.s?  If so, where is it getting vectors from?  If not, is this a bug?

Thanks,

John Regehr

[mjbcswitzerland]

Hi John

If the build causing problem is not using mcf5xxx_vectors.s it will be using vectors in SRAM - this is usually defined as __VECTOR_RAM (look in the linker script file used for the build because this will declare the array to be positionen at the start of RAM (0x2000000).

This RAM is generally primed with an error exeption handler for every vector entry.
It is then up to the user to enter each vector at run time (this can also be changed on-the-fly, which is not possible when fixed in mcf5xxx_vectors.s).

Search __VECTOR_RAM also in the library files and you should find a routine which is used to enter the interrupt vectors.
The uTasker project uses this technique and the routine is more or less identical:

Code:

// Enter a vector in the vector table in SRAM, returning old value//static unsigned char *fnSetIntHandler(int iVectNumber, unsigned char *new_handler){    extern unsigned long __VECTOR_RAM[];    unsigned char *old_handler;        old_handler = (unsigned char *)__VECTOR_RAM[iVectNumber];    __VECTOR_RAM[iVectNumber] = (unsigned long)new_handler;    return old_handler;     }

 

Regards

Mark

[regehr]

Mark -- thanks, your code works like a charm.

Summarizing for the benefit of subsequent readers of this thread: Dynamically installing the handler using Mark's code above works with both the RAM and CONSOLE_RAM compilation targets.  No need to modify mcf5xxx_vectors.s at all.

John Regehr