A lot of strange things happening, help!

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

A lot of strange things happening, help!

Jump to solution
1,404 Views
FridgeFreezer
Senior Contributor I

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.

 

 

 

 

Labels (1)
0 Kudos
Reply
1 Solution
500 Views
FridgeFreezer
Senior Contributor I

After doing a lot of trawling of forums I have downloaded MarcVDH's Codewarrior 7.2 libraries and applied the fixes to the _lo.s files and this seems to have stopped a lot of the problems. Does make me wonder why the hell this isn't handled properly by CW or correct libraries included with the distro.

 

MarcVDH's libraries are here, and much appreciated they are too:

http://www.mvdh.be/cf_lite_patched.html

View solution in original post

0 Kudos
Reply
2 Replies
500 Views
J2MEJediMaster
Specialist I

The fact that things spin out of control when you enable interrupts hints that it is an interrupt handler problem. Try this:

 

Disable all interrupts but for one handler.

Rebuild the program.

Does the handler work, or at least work for a while?

Try another handler and see if it works in isolation.

If they work separately, then try enabling a second handler in the program.

Do you get instant death or erratic operation then?

 

If the handlers work in isolation, then how you are clearing the interrupt needs looking at. Possibly one of the interrupts is firing in the middle of the other and smashing things or causing a stack leak.

 

If the handler works in isolation for a while and then dies, then you are not cleaning the stack up properly and it is leaking. The handler will work until the stack runs dry. A second handler, which relies on a valid return address being on the stack, instead picks up garbage and the program dies.

 

---Tom

0 Kudos
Reply
501 Views
FridgeFreezer
Senior Contributor I

After doing a lot of trawling of forums I have downloaded MarcVDH's Codewarrior 7.2 libraries and applied the fixes to the _lo.s files and this seems to have stopped a lot of the problems. Does make me wonder why the hell this isn't handled properly by CW or correct libraries included with the distro.

 

MarcVDH's libraries are here, and much appreciated they are too:

http://www.mvdh.be/cf_lite_patched.html

0 Kudos
Reply