Touching the TMS/!BKPT PIN on MCF52259 locks up the entire processor, no watchdog recovery

[CarlFST60L]

Hi All,

I have found a way to completely lock up the MCF52259. Simply touch the (pin 38 TMS/!BKTP) (I used my finger, tweasers, cro probe and they all locked it up completely). It just stops, watch dogs don't recover (I have both watchdogs running and neither reset it), nothing other than pulling reset low manually or power cycling recovers from this. MC_CLK is still running and stable, I have loss of lock etc enabled and nothing happens, all code stops instantly exactly where it just stops where it was with all IO left exactly where it was. This will happen on the MCF52259DEMO / EVAL board. There is a 10K pullup to prevent this strange operation, how can it still happen with such a high impedance touch???? Sure if it was floating, but 10K pullup is small enough...

Why doesnt the watchdog recover from this, is it because its activating the external break point?? I have DSI floating, DSO pulled high. Is the internal bus locking up stopping all code and all modules from getting a clock i.e. watchdog stops ticking?

Any idea how to stop this on boards in the field as I cant add any circuits via remote software update.

Also, are there any other known pins or issues that I should allow for?

PS I have JTAG enable directly tied to ground

[TomE]

MCF52259 Reference Manual.

2.18 Debug Support Signals

Table 2-17. Debug Support Signals

Breakpoint. Input used to request a manual breakpoint. Assertion of

BKPT puts the processor into a halted state after the current

instruction completes. Halt status is reflected on processor status

signals (PST[3:0]) as the value 0xF.

> There is a 10K pullup to prevent this strange operation, how can it still happen with such a high impedance touch????

A CRO probe will have a capacitance of either 20pF (divide-by 10) or 100pF (divide by 1). That's a "dead short to ground" until the resistor can charge up that capacitor.

10k and 20pF or 100pF gives an RC time constant of 200ns or 1us, plenty long enough to trigger the breakpoint when you "touch" the earth-potential CRO probe to that pin.

Is this really a risk in the field?

We use a similar MCF5235, and we strap it to JTAG mode by default to stop the debug pins from radiating EMC. That would stop the Breakpoint. That's a design option, but not a "remote software upgrade" option.

> Why doesnt the watchdog recover from this?

I'm familiar with the MCF5329. Its watchdog has control bits for "Wait/Doze/Halt" where the "Halt" bit determines if the watchdog runs when in "halted/debug mode". If you try to debug the chip without setting this bit, the watchdog will reset out of a debug breakpoint. The MCF5235 has the same "Wait/Doze/Halt", but the manual doesn't explicitly equate "Halted" to "Debug" mode. We do force this to "3" (Enable and Halted) when debugging from GDB, so it operates the same way.

The MCF2259 BWT has "Wait/Doze/Stop" control bits, and doesn't say the "Stop" mode has anything to do with Debugging. This may be a later addition. Anyway, do you have all three bits clear in your BWT? If so, then having the BWT stop dead when Debugging is probably a "feature" you can't turn off in that chip.

I've just looked closer and have spotted something Interesting.

The bits in the Watchdog control register in the MCF5329 and MCF5235 are "... 0, WAIT, DOZE, HALTED, EN". In the same order in the MCF52259 they're "... STOP, WAIT, DOZE, 1, EN", so it looks like the STOP mode bit is an addition for this chip and "he bit previously known as HALTED" is forced to "1", possibly meaning it is permanently set in this chip.

You should also search this forum for "mcf52259 debug watchdog" and see what shows up.

Tom

[CarlFST60L]

Thanks so much for taking the time to respond, really appreciate it.

Just a little FYI, touching the pin with my tweezers is enough to trip it... Im not touching anything and if i just skim past it with the tweezers, it freezes! pretty scary, no normal input would activate like that with a 10K pullup, sure if it was more than 1M (I usually find anything 2M2 or less is enough to stop GPIO triggering from human model touches).

What I am mostly worried about is after a forced reset it 'locking up' as it boots before I have a chance to stop it in software due to some transients on this pin. We have many thousands of units being monitored continuously and I have maybe 1 a year fail due to what I believe is this. My latest version hardware has an external watchdog so it is managed by a second 8 bit processor rebooting the main processor, no benefit to these field units though.

I will go read the data sheet and see what I can do. IMO, this is a floor in the design (and data sheet for not pointing out that this pin is 'not a normal input). Human contact with a pin tied with a 10K 100% should not trip it to activate.

[TomE]

> Just a little FYI, touching the pin with my tweezers is enough to trip it

How many picofarads are you (to ground) and what voltage are you floating at? If you've got a wrist trap on you're at ground, but still with perhaps 100pF of capacitance.

> Unfortunately I had BWT.WCR |= 0b0000000000000001; and it appears that MQX must set the other flags (I guess)

Not possible. It is Write Once:

8.2.2.1 Backup Watchdog Timer Control Register (WCR)

The WCR, shown in Figure 8-2, configures the operation of the BWT. It is a read-always/write-once

register; after the register is written, the contents cannot be changed until the next Power-On Reset event

occurs.

It also has a power-on default value of 0x0002, and the "2" bit is not writeable. So you can write 0x0001 to it, and it will have the value 0x0003.

By comparison with other versions of this module, that "2" bit means "stop counting when halted in debug mode".

You can change the hardware design by putting a capacitor on that pin that is larger (say by a factor of 5 or 10) than your CRO Probe, or of you and your tweezers or your suspected miscreants. For reference, my multimeter says I'm between 70 and 100pF to ground. You wouldn't want to put a capacitor on this pin that would prevent the debugger working - I assume that's the way you load the code during Production.

> I have maybe 1 a year fail due to what I believe is this.

That's pretty low over thousands of units. How can you tell that specific cause from any other possible upset caused by ESD?

Does this happen to particular units or particular sites more than others? Ones that are more likely to get ESD from passing plastic-clad humans?

Improving grounding at any sensitive sites may be a cure.

Tom

[CarlFST60L]

Unfortunately already had BWT.WCR |= 0b0000000000000001;  //reset state is all zeros, so BWT is enable in 'all modes'

[CarlFST60L]

Unfortunately I had BWT.WCR |= 0b0000000000000001; and it appears that MQX must set the other flags (I guess) because I changed this to BWT.WCR = 0b0000000000000001; and it recovers every single time after the BWT times out.

My main concern is still what happens if a transient causes this to trip during boot up (prior to this line of code running), it WILL stop and it WILL NOT recover...

Any ideas for both my field units and new hardware going out the door?

For new hardware I have a external hardware watchdog, so that will recover it, but it would be nice to stop it before it happens. For field units, I have no idea what to do...