Code locks, crashes, works, locks, crashes, works...

[FridgeFreezer]

Seems at least once a week I'm on here trying to understand something CW is doing...

Using CodeWarrior for Coldfire v7.2, MCF52259CAG LQFP144 micro, P&E USB Multilink.

I have a project which initialises our hardware and sets a few IRQ's up - UART, DTIM, RTC, and PIT.

Main() just toggles an LED, nothing else. The other IRQ's are doing very little other than acknowledging the interrupt. The RTC toggles an LED on a 1sec timer.

If I hit F5 to run/debug the code, first time the code just locks in an ASM section and nothing happens, if you step through it eventually drops into main() and does nothing (no IRQ's fire, no LED's toggle). Second time the code will run through the asm_startmeup / board init, enable interrupts, then crash out to address 0x0F0F0F0E (or 0xFFFFFFFE sometimes). The third time I hit F5, it downloads and runs perfectly.

I am not changing anything between builds, literally just hitting "F5", "Kill", "F5", "Kill","F5", "Kill" with the same results every time round the loop.

I don't have time to post a lot more detail right now (it's POETS day after all!) but any ideas gratefully appreciated.

[FridgeFreezer · Accepted solution]

Well I found the problem in the end, as usual it was PICNIC - one of my imported files from the old codebase re-defined the PIT1 ISR, but CW didn't throw any errors or warnings so it seems it was pot luck when the interrupt fired whether it would go to the real ISR, an old ISR, or throw the toys out of the pram.

[FridgeFreezer]

OK, time for a bit more detail...

As I said, this is pretty much a bare-bones project at the moment - the MCU is initialised and the peripherals etc. setup, interrupts are set up and enabled (PIT1, DTIM0/2 as pin toggle outputs, UART, RTC) but none of the ISR's are doing anything other than maybe toggle an LED or increment a counter.

So, if I hit F5 to compile & debug the code, I get this:

If I then hit "run", the code crashes:

If I kill the process and hit F5 again the code starts in a completely different state:

If I then run it, it runs perfectly (not a very exciting screenshot, but the board is behaving as it should):

If I kill the process and hit F5 again, the startup is different again:

And if I hit "run", the code sits in the main() loop, doing nothing, with none of the interrupts enabled:

[Kopone]

I just had a very similar problem when I set up the UART interrupts on a MCF52259 project. Got the same weird crashes and nirvana jumps during startup, things that just didnt seem to make any sense. I must admit that i never really looked into the details of what caused it. However it was gone as soon as I turned off the TxReady interrupt and programatically only turned it on when I had actually bytes sitting in a send buffer.

I assumed this interrupt would only fire once - right after a byte was successfully moved out of the transmit register. However it will fire continuosly whenever the tx register is ready to take a byte (as the name actually suggests, hehe). I thought I may just have mixed up the order of setting up the isr vector and actually activating the irq, so it was fired before the vector was set. But the vector table was actually hard coded in the source.

Maybe the debugging process just doesnt work that well with plenty of interrupts during startup already, but I really didnt look into it any further.

Regards,

 Sven

[J2MEJediMaster]

I am not familiar with this part, but normally interrupts do not clear by themselves. You have to clear the interrupt bit in your handler code. Otherwise, the moment you reenable interrupts, the program will be yanked back into that interrupt handler.

---Tom