AnsweredAssumed Answered

A lot of strange things happening, help!

Question asked by FridgeFreezer on Jul 2, 2010
Latest reply on Jul 6, 2010 by FridgeFreezer

Apologies if this post doesn't make a lot of sense, I'll try and fill in details as I can but this is really strange. I'm sure I'm missing a few obvious things here but I'm completely perplexed as to what's going on, possibly there are several problems, hopefully you guys can help shed some light on it.


Using CodeWarrior for Coldfire v7.2, MCF52259CAG LQFP144 micro, P&E USB Multilink, on a PCB based on the M52259EVB.


The project initialises our hardware and sets a few IRQ's up - UART, DTIM, RTC, and PIT, all either directly using Freescale's drivers (uart.c, pit.c, etc.) or using cut down/simplified versions of those routines. I've had the code working in very basic form (EG doing nothing of any use but sitting there toggling an LED from the RTC_1HZ ISR, another from PIT1, and stepping stepper motors from DTIM0 & DTIM2 on ISR's.


However, as soon as I go to make changes to the code or even just the structure (EG move the RTC_ISR from rtc.c to interrupts.c) it goes of into the weeds in various random and hard to reproduce ways.


I had a problem previously where some old code I'd imported re-defined an ISR function and CW didn't warn about it, which would give a different result every time you ran it (work, crash, freeze, work, crash, freeze...) but I have checked and I can't see anything else like that. I can roll back to a working version of the code, change the smallest thing and it just completely stops. Sometimes it will mostly work but the DTIM ISR won't work, or will work once then never again. Sometimes no interrupts will work (despite all the vectors & ISR's being set up and visible in the debugger).


The behaviour is so difficult to pin down I'm struggling to describe it, I suspect if I could accurately describe it I could fix it myself. Anyway, a few more symptoms;


The problems usually start after initialisation when I unmask interrupts (asm_set_ipl(0)), if it's going to crash it will usually do it then with an address error, usually jumping to 0xFFFFFFFE, 0xFFFFFFFF, or 0x0F0F0F0F.


The status register when exceptions occur also is unpredictable but 0x4010006F seems to be a popular state for it to end up in, which I'm not sure is even valid?


Quite often the code gets stuck in an illegal instruction loop from a line in one of the DTIM ISR's (which works the rest of the time) which is something like this:

global_data.timer_value = (bigconst32 / global_data.speed_value);


One thing that's perplexing me is that the freescale asm_startmeup code in mcf5225x_lo.s calls mcf5225x_init() but the code (based on Freescale's example code) calls this from main() as well. If I comment it out from main() it doesn't work.


I have to dash now but I'll fill in more details and answer any questions as soon as I can.