So, whenever I made any changes to my c code, seemingly unpredictable things would happen. I'll tell you what I learned and the final solution.
At first I thought it may have been a compiler issue. Using -Wa,-m5249 (specifies as should assemble for the m5249 coldfire processor) , I got an error that there was some bad assembly code -- generated code. So it seemed that the compiler was generating bad asm. I tried to do option -m5249 to no avail -- it didn't have that architecture available. I found a very useful list of options if you do m68k-elf-gcc --target-help . -m5200 was kinda-sorta in the list with -m5249 so i tried that and it seems to be working. Hopefully m5249 is a derivative of the m520x architecture.
In this process, I found fomit-frame-pointer to cut down on some assembly which doesn't look to do much. I don't know if I am schedualing my own demise by setting this though.
These didn't fix my troubles, so i ran back to my handy 92 MiB dissassembly and looked through the initialization code. I noticed that the stack pointer was being set to a location on SRAM0 (the 32k one). I tried to set this to that location, but unfortunately used relative addressing. Apparently the instructions look identical except for a # before the symbol name. I noticed the difference by reading the dissassembly of my own code and noticing that some move.l's ended in c while others ended in 9's. Apparently c is absolute and 9 is relative, meaning that bit 3 determines relative / absolute. So after I got the relative / absolute situation worked out, I got it to work.
So I guess the moral is to not setup a stack pointer that will write over your code when its used. I can't believe I could figure this out, because the symptoms were really very random.
I have my code flash the backlight like crazy right now. It is completely seizure-tastic. You really can't look away when it is doing that. I hope to figure out how to get the lcd working soon so I can actually get some decent feedback.