Can't program flash with BDM USB-TAP

[lambtron]

I have a coldfire 52230 target, which I am debugging with a bdm usb-tap under cw 6.4 build 6. The executable is too large for ram so it's running in flash.

Everything works fine for awhile, then I can no longer program flash. Nothing changed (hardware, software, connectivity, etc.) to cause the problem and nothing fixes the problem (reboot, restart cw, different usb-tap, cycle target power, in every possible sequence thereof). Suddenly, and for no apparent reason, I can again successfully program flash. When it goes down, it is sometimes down for days or even weeks. Same for up time.

When it's down and I try to erase flash, it reports that flash is erased, but memory dumps indicate otherwise. Furthermore, when it's down and I attempt to erase, I get this log:

======================================================================
=== Execute: Erase
=== Timestamp:  Wed Jan  9 14:06:04 2008
=== Flash Device:         CFM_MCF52230
=== Flash Organization:   4Kx32x1
=== Flash Mem Start Addr: 0x00000000
=== Flash Mem End Addr:   0x0001FFFF
======================================================================
Using Algorithm: CFM_MCFCOMMON.elf
 
Loading Flash Device Driver at: 0x20000000
Flash Driver Buffer is at:      0x20001FB0
Flash Driver Buffer Size is:    0x00004050
Done

Initialization Command Succeeded
Erasing entire flash ... Done

Erase Command Succeeded
Timestamp:  Wed Jan  9 14:06:06 2008

But when it's working ok and I erase flash I get this log:

======================================================================
=== Execute: Erase
=== Timestamp:  Wed Jan  9 13:39:40 2008
=== Flash Device:         CFM_MCF52230
=== Flash Organization:   4Kx32x1
=== Flash Mem Start Addr: 0x00000000
=== Flash Mem End Addr:   0x0001FFFF
======================================================================
Using Algorithm: CFM_MCFCOMMON.elf
 
Loading Flash Device Driver at: 0x20000000
Flash Driver Buffer is at:      0x20001FB0
Flash Driver Buffer Size is:    0x00004050
Done

Initialization Command Succeeded
System clock:  25000KHz
 
Erasing entire flash ... Done

Erase Command Succeeded
Timestamp:  Wed Jan  9 13:39:47 2008

Please note that this text (and the following blank line) appears only when it's working:

System clock:  25000KHz

Here's my config file:

ResetHalt

; Set VBR.
writecontrolreg 0x0801 0x20000000

; Program RAMBAR.
writecontrolreg 0x0C05 0x20000021

; Program FLASHBAR.
writecontrolreg 0x0C04 0x00000061

; Enable PST[3:0].
writemem.b 0x40100074 0x0F

This is VERY FRUSTRATING. I've opened trouble tickets on this but the problem has always disappeared before the cause was determined. So the tickets expire and close and then the problem returns.

Am I the only developer who has seen this problem? If not, would someone from freescale please post advice here so that (1) the conversation can continue beyond the timeframe of a ticket, and (2) others might benefit from this discussion?

[TudorS_]

Hello.

The common internal flash algorithm for ColdFire cores had a bug in the 6.4 release that prevented it to determine the correct clock frequency in some instances.

This has been fixed in subsequent releases, i.e. CodeWarrior for ColdFire v7.0

--Tudor

[J2MEJediMaster]

That system clock message appears significant. I wonder if the oscillator generating the system clock signal is drifting in and out of tolerance? Is there any way you can check that?

---Tom

[lambtron]

Thanks for the reply, Tom.

I agree: the system clock message appears to be significant.

I have checked the oscillator circuitry, which consists of a 25MHz external crystal, with classical bias components, connected to the 52230's XTAL and EXTAL pins. It appears to have excellent stability, with well-shaped sinusoid, with frequency almost exactly 25MHz. Amplitudes look good: 2.4V on EXTAL, 3.2V on XTAL.

Any other ideas?

[lambtron]

Additional info about this problem:

I can use the usb-tap to "run" the program on the target. The program doesn't actually run because I can't program it into flash, but this tricks cw into thinking that it's running, thus enabling me to display various cw debug windows. I can then open cw's Register window, which in turn makes it possible to examine and modify registers within the 52230 device. From there, I have enabled PIT0 and verified that it is counting, so it's proven that the system clock is applied to at least this internal circuit.

[J2MEJediMaster]

I assume that you've read chapter 17 of the MCF52235 Reference Manual, which covers the ColdFire Flash Module? It mentions that the clock signal has to be at the proper frequency for the programming operations to work. Also, although the clock signal looks fine now, it might take hours (or days) before it drifts. I'm afraid I'm running out of ideas here.

---Tom