Long Reload Times (CW5.1 & S08GT32)

[Wings]

Every time I go through a debug-edit-reload cycle I spend 21 seconds waiting for this Cyclone Pro to reload my new code into the chip. If you multiply this 21 seconds by the number of times I do this in a lengthy project, then multiply that by all the programmers out there doing the same thing, that comes to an awful lot of wasted time. Seems to me that MetroWerks/Freescale/whoeveritisnow would have realized that this part of CodeWarrior should merit a great deal of attention in speed optimization.

All those windows that appear and flash a sequence of messages up the screen way too fast to read, and reloading the Cyclone with its programming algorithm every single time, then actually loading my code (which is surprisingly quick), then sitting still for about 9 seconds doing who-knows-what after it resets my target ... all those things when all I want it to do is to simply reload and get out of the way. It's beginning to bug me, as you can probably tell.

OK. I'm now getting to my question. I want to know how everyone else goes through their debug-edit-reload cycle. This is what I do... First, test & figure out where my code went wrong. Second, edit the source (assembly for me) and re-assemble. Then (and here is mainly where my question is focused) I switch from the editor window over to the debug window (BDM_P&E_Multilink_CyclonePro.ini) and under the File menu I choose "Load Application...". If I click on the Debug tool in the editor window it takes a bit longer, bringing up the original Connection Manager and making me click Connect.

How do you do it and how long does it take?

[Wings]

Doesn't anyone debug code any more?

[Alban]

Sorry Wings...

We always get it right from the very first try !

Debug in RAM instead of flash, it is much, much faster.
Also, using the simulator could be a possibility. I never used it on S08 though, so dunno how it is.

You can have Two PRM files. One for debug putting code in RAM, and one for execution putting code in flash.
By using #pragma, you can put only specific functions in RAM and don't reload the flash. You debug the functions, then remove the #pragma so they go back to where they belong... CODE_SEG DEFAULT.

Cheers,
Alban.

[Wings]

I appreciate the suggestion Alban, but the GT32A I'm using only has 2k of ram and I've got almost all of that allocated already. My code is up to 11k and I estimate that I'm about half way done. Besides, when I add a new chunk of code the bugs I find are seldom just isolated to the new code.

I wish we had the ability to change what's in flash on a byte by byte basis, then it would be similar to executing out of ram. I miss being able to patch my code in place. A BNE that should be a BEQ requires a total recycle. P&E could do this if they wanted and a while back I was told that adding this ability was on their to-do list.

I wish Freescale & P&E would add a total re-write of CW & the debugger to their to-do list (and while they're at it, a version that runs on a Mac). It is infinitely more complex than it should be, and I feel like I'm back in Windows 3.1 every time I use it. (They don't pay me enough for that.)

[peg]

Hi Wings,

I don't use Codewarrior to avoid all the fluff.

I use P&E's tools (bought from them) from my editor.

I just tested a similar sized programme in a GT16 and can Reset, load algorithm, Erase, blank check, programme, verify, calc and programme trim and programme in a serial number in 6 seconds.

Then I can fire up the debugger load the file, connect to the device, verify the contents and be running in the debugger in 8 seconds.