MFC52258 serial oddities

[jeffreysainio]

Our latest batch of boards, about half failed UART communications tests. Investigation found that every hundred to maybe every thousand characters (8-bit no parity, 38.4Kbaud), FFs are transmitted instead of the desired characters, usually 2 of them, but as many as four.

Plugging in a ColdFire Multilink to debug, the problem disappears!  Indicates that the debugger somehow cures the problem.

Further digging shows that CPU pin 43, TCLK, was the pin which the debugger affected.  This is a very strange pin.  It sits at 1.7v DC, and will push/pull 45 mA to get it to ground/3.3v!  Including good boards. Most uPs won't drive this much.

A 10K pullup does almost nothing, of course.  A 180-ohm pullup gets the pin to 2v and fixes 80% of boards.  The rest need a capacitor (a 220 pic seems to work) to ground to get stable communication.

Of course, the documentation shows no connection whatsoever between this pin and serial output.  Any ideas?  Our boards are working, but only by "magic."

[jeffreysainio]

I found the root problem.  The CPUs are thermal.  A drop of ice-water carefully placed on the chip, cures the problem, and touching the drop with a soldering-iron tip, gives nothing but errors.  We have bad CPUs, either from the factory or damaged in wave-soldering.

[scifi]

It doesn't sound like the root problem at all. The thermal sensitivity and the TCLK behaviour suggest that something is happening that you don't understand yet.

[TomE]

It still might be something else.

Here's a post to these forums where an MPC Uart only worked under 50C. The problem there was that the CPU was being overclocked:

https://community.freescale.com/message/116326#116326

I also had a problem where SDRAM was getting corrupted under certain circumstances, and it was temperature sensitive. The problem ended up being that the pin Drive Strengths defaulted to "High" and the resulting overshoots and undershoots were causing the RAM to lost whole rows.

Re: MCF5329 with random SDRAM 1k "bit rot" corruptions

Soldering iron tip? How hot are you running those things? Are you sure there isn't a fault or miswiring somewhere on the board (or a software bug) that is trying to drive power into a shorted pin? The CPU might be a lot hotter internally than the package suggests.

Anyway, good luck with it.

Tom

[jeffreysainio]

I found that grounding TCLK gives a very high error rate, while yanking it high gives error-free communications.  45mA scares me though.

[TomE]

That pin is "TCLK/PSTCLK/CLKOUT". Read Table 3 in the Data Sheet and the JTAG chapter of the Reference Manual.

> Plugging in a ColdFire Multilink

Changes the function of the four BDM pins to being JTAG pins. It also changes the TCLK?PSTCLK/CLKOUT pin.

Read up on this so you know what's happening. Is JTAG_EN in the right state? There's an internal pull-down on it, but you may have a pull-down or pull-up on the board to force the selection. You might have noise coupling to it, or you might have a pull-up that is too high a value and so the pin isn't being pulled to a valid value.

Search this forum for "JTAG_EN". You may get a match on your problem there.

Eyeball the boards closely. Production may have left off a resistor or capacitor somewhere, or used the wrong value.

Read "7.7.1.1 Synthesizer Control Register (SYNCR) in the Reference Manual, specifically the DISCLK bit. How is that set?

When you say "FFs are transmitted", do you mean real 10-bit characters with start and stop bits and the data bits set to all-ones, or do you mean it sends a break or that there's an idle-gap between the characters? Something in the hardware JTAG pins may be upsetting the hardware or you could have a software problem in the serial driver somewhere.

Tom