CodeWarrior and interrupts

[MH]

I started using the 5474LITE board with a small program that I had written that communicated via RS232 using interrupts. This was downloaded into SDRAM using the resident dBUG program and worked fine.

I wanted to investigate using CodeWarrior and so started with the stationery for the CF_M5475EVB (C). After testing that it worked I added in all the files for my existing program and made any necessary changes for it work with the new compiler (such as using __declspec(interrupt) to indicate an interrupt routine). I eventually had a version that would compile using the UART SDRAM target and I downloaded it using the P&E cable (printer port version). I can single step through the program and it appears to work except for the interrupts. I took the S19 file that CodeWarrior produced and downloaded it via RS232 into dBUG and the program works correctly, interrupts and all. On searching the Help I found that I should have changed the CF Interrupt under Debugger in the Target Settings Panel but this doesn't seem to have any affect on the problem.

According to the About box, I am using CodeWarrior IDE version 5.7.0 Build 1984. When I click on Installed Products it tells me I am using CodeWarrior Development Studio for ColdFire Architectures Version 6.3 (Preview Release).

Can anybody tell me how to go about getting interrupts to work when using the debugger? I know the code is ok since it works when not using the CodeWarrior IDE so it must be something that the debugger is preventing.

Thanks,

Malcolm

[alsuren]

I'm in the middle of sorting out the opposite problem (as in I can get interrupts working when I flash the board using a BDM interface, but I can't get them working with the dBUG interface.

I downloaded the source code for the monitor (very useful! It's on the coldfire site for every development board there is, if you search around a bit)

The way interupts seem to be handled by dBUG is it sets up a vector table in ROM (vectors.s, starting at address 0) and that position is full of pointers to a function called _asm_isr_handler, defined in mcf5xxx_lo.s, which *does something* to figure out which vector caused it to be called puts it on the stack, then calls isr_execute_handler, which is a C function defined in isr.c. This function then *searches* an array for the vector number, and presumably calls it. I don't understand how my code should go about registering an interrupt though.

Suffice it to say that exceptions are a lot more complicated under dBUG than when you use a bare board. When you're using a bare board, all you have to do is find out where the vector table is (pointed to by the VBR core register) and put a 32 bit pointer to your ISR function in the appropriate place (coldfire manual will tell you the interrupt source, and you add 64 to it to get the vector number, then index off the VBR (*4 and add) and you're set)

If I work out how to do interrupts under dBUG tomorrow (23rd aug) I will post, but if anyone knows how to register interrupts(or even point me to a good dBUG user reference manual), I would be very grateful.

[alsuren]

Just to correct myself. Turns out that you *can* simply override the dBUG interrupts by putting your code into the vector table. It's just a case of finding it. The way I did it is to look at address 0 (in the ROM), and see what that looks like. In my case, it looked like a vector table. I had initially assumed that dBUG didn't copy that table into RAM (which would have meant that you *would* have to register your ISRs with dBUG), but it turns out that it does copy it into RAM, and update the VBR accordingly. I couldn't find a way to print the VBR (I don't know wheter there *is* one) so I had to use md to scan through RAM for a block that was the duplicate of the vector table in ROM.

A point of note: if you *want* to register an ISR with dBUG, I don't think it's possible to do it as a client program, because the function isr_register_handler (defined in isr.c) is *not* referenced in any of the linker files (as far as a text search in Eclipse can tell), so there's no way to know what address it's located at to call it, unless your program is compiled along with the dBUG source, and is included in the linking (which would involve re-flashing the entire dBUG monitor each time you do a compile-test cycle).

Sorry if I caused any confusion. I'm in the same boat as you.

[marc_paquette]

Use the Interrupt settings panel to turn *off* interrupts.

Have you tried setting a breakpoint in the interrupt routine?

Marc.

[MH]

Hi Marc,

The only panel I can find that refers to interrupts is called "CF Interrupt" where there is a check box labelled "Mask Interrupts" and below that a drop-down selection box labelled "Interrupt Level". I have unchecked the "Mask Interrupts" box but interrupts do not work. I have also tried putting a breakpoint in the interrupt routine and it is never reached. Is it critical at what point in the debug process I change the setting or is the changed setting active immediately.

Why do you say that I should turn *off* interrupts? Don't I want them enabled?

Thanks,

Malcolm