I just checked and see that the development version has the following extra lines of code:
#elif defined _HW_AVR32 || (defined _M5223X && defined _GNU) // {14}
#ifndef _WINDOWS
start_application(UTASKER_APP_START); // jump to the application
#endif
#endif
This was added on
25.07.2009 Use start_application() for M5223X and GCC {14}
As the comment states it was added for the GCC M522XX project. I am surprised that it is not in the V1.4 release because the change was probably made during last minute tests.
The fact is however that CW is the overwhelming Coldfire compiler used for the project and I expect that boot loader users do tend to use this (note that CW is also more or less the only way to program the Kirin3 too...).
Yeah, the line in the v1.4 release source doesn't have the second half of the elif
I am curious about your last comment above. Do you mean it is the only way to program the flash? I am successfully using the GCC toolchain and Eclipse for development and debugging with hardware breakpoints. I am using a PE Micro BDM device for programming the flash and the CodeSourcery sprite works fine with that. I was using the TBLCF for a while but it was just too slow in programming the flash.
Your analysis of the jump to the application does see spot on too. The code has been copied from Startup.s, which is used by Codewarrior. Codewarrior has been configured to pass arguments in registers and not on the stack (this is faster and produces small code size) but the GCC will probably pass on the stack and not D0.
So my only conclusion is that the boot loader really probably never has been used with GCC before!
Therefore I am sorry about this lapse in testing.
Perhaps you could add the move of the value from stack and verify that the jump to the application address then completes correctly (also the load of the SP). Maybe that is all that needs to be fixed (hopefully). If not I will have a go on my M52259DEM board too.
I did fix the code in start_application and it does now successfully jump to the application code at 0x1000. However, I am now getting a strange behavior when trying to execute a line of code in mcf52235_init which looks like this:
while (!(MCF_CLOCK_SYNSR & PLLOCKED)) { SIM_LOCK } // wait for PLL to lock
It appears the program goes off into the weeds (the PC is at 0xfffffffe). This isn't a problem when executing the same code in the non-bootmanager version. Still looking at this issue. Any help would be appreciated.
BTW, I also had a minor issue that RAM was only defined 32K in size (in the .ld files) when my processor has 64K. But when I modified it to use the full 64K of the 52259, I discovered the code in start_application would fail because the initial value for SP (also defined in the .ld files) was outside of RAM.
Now I am off to see if the GCC compiler can be configured to pass args through registers
Thanks for your quick response. I guess these weren't noobie questions after all
Dave G.