topic Re: MCF5328 based product not getting progrmmed through Cyclone MAX BDM port in ColdFire/68K Microcontrollers and Processors

MCF5328 based product not getting progrmmed through Cyclone MAX BDM port

Soos — Thu, 25 Oct 2012 16:48:05 GMT

A new product based on MCF5328, has 26-pin BDM port, which we used for firmware development & product is now ready for production.

We want to use Cyclone Max for programming production unit, but it is not getting programmed.

Same board gets programmed with same BDM port on development system.

I have attached a schematic file with this.

Flash gets half way programed & stops. No fixed location every time.

If anybody has faced similar problem & know solution for that, please let us know.

Your will appreciate your advice.

Thanks

Re: MCF5328 based product not getting progrmmed through Cyclone MAX BDM port

TomE — Fri, 26 Oct 2012 13:52:35 GMT

Read through all the Cyclone Max's data sheets and manuals from cover to cover.

Get onto P&E for support. Check out their web site and read through their support forums:

P&amp;E Microcomputer Systems

Compare your debugger port with a Development Board schematic and see if anything is wrong, like missing pullups or pulldowns. You've got more pins connected (to the debug connector) than we have. You might have too many., It might be worth making a short adapter cable and cutting the wires the Cyclone Max doesn't need.

Have you got any "special stuff" in the debug pod initialisation to write to any special registers or that does any nonstandard port setup? Have you got the Cyclone programmed for the right FLASH chips you're using with the right width and so on?

Tom

Re: MCF5328 based product not getting progrmmed through Cyclone MAX BDM port

Soos — Thu, 01 Nov 2012 16:53:01 GMT

Hi Tom

Thanks for your response.

We could resolve the problem. I talked to my engineer & I am giving below the actions we have taken to fix this.

This will be useful to all who may face similar problem.

the PE Micro algorithm file consists of configuration commands in the form of plain ASCII text and algorithms in the form of S19 records. The algorithms start with a table of configuration values and function pointers to things like “erase module,” “program words,” and so on.
Finally, a delay function was written and it is being called before every instruction that writes to the flash.
The delay is called before each one of those write cycles. In its original form, the algorithm file was tightly coded assembler that would preload different Coldfire address registers with the different addresses needed by the command sequence and then step through the command sequence literally from one Coldfire instruction to the next. That fact, combined with the fact that the algorithm resides in the fast on chip static RAM, means that the command sequence was hitting the flash chip faster than usual, where usual is defined as C code compiled with lower optimization settings (to ease debugging) or which resides in slower memory than the on-chip static RAM, or both.