MCF51JM128VLK releasing control of PTH2?

[daveknight]

Is there an issue with PTH2, or with GPIO pins on the MCF51JM128VLK in general that causes the MCF51JM128VLK to release control of the pin and let it float high, or some similar behavior.

I'm using MCF51JM128VLK to drive LTC2862, to convert UART into RS485.

PTH2 sets the direction of the data flow.

PTH2 sometimes get stuck in logic 1. The pins it's driving(Driver Enable and Receiver Enable) aren't drawing excessive current. 

I've tried removing PTH2 from the circuit and using PTC7. PTC7 doesn't seem to get stuck like PTH2, but sometimes our device has to run a long time to get failure mode. I'd feel more comfortable moving forward if I knew the cause of the failure.

[daveknight]

Thanks for your suggestions everyone.

The problem was caused by interrupt service routine and read modify write problem. 

[miduo]

Hi,

Yes, you should check RGPIO_ENB first as Tom mentioned. The symptom you mentioned is most likely that the pin competition, the PTH2 be overridden by RGPIO8. Does any feedback checked with the code?

[TomE]

Check RGPIO_ENB.

Other ColdFire families (52, 53, 54) have explicit Pin Assignment Registers. The MCF51 chips are different. They're made for migration from 8-bit chips, where pin assignment is a side-effect of enabling a controller. So if the UART is enabled, then the pins are controlled from the UART, otherwise they revert to GPIO.

PTC7 doesn't have any competition. It is only ever GPIO. PTH2 can be overridden by RGPIO8.

I assume you've also checked PTH2's Output Enable setting?

You might have some software in there with a "wild pointer" that accidentally writes to the wrong addresses.

It might be a problem caused by ESD. Can you increase the shielding on the chip's IO pins? Try a 100pF cap or a series resistor on PTH2 as it seems to be the one getting affected.

Are you running at 3.3V or 5V? Are you sure none of the pins (especially PTH2) aren't being pulled above VDD by anything? Do you have any long tracks that could be causing undershoot or overshoot that could be going above VDD or below VSS?

Tom

[daveknight]

PTC7 doesn't have any competition. It is only ever GPIO. PTH2 can be overridden by RGPIO8.

I assume you've also checked PTH2's Output Enable setting?

You might have some software in there with a "wild pointer" that accidentally writes to the wrong addresses.

I'll ask software engineers to look at these. 

It might be a problem caused by ESD. Can you increase the shielding on the chip's IO pins? Try a 100pF cap or a series resistor on PTH2 as it seems to be the one getting affected.

110 ohm series resistor has no impact.

I'll try a 100pF cap if I can find one in the lab. My initial guess is that the 10k pulldown might be as effective at swamping out ESD as 100pF.

What kind of ESD issue are you talking about? 

Are you running at 3.3V or 5V?

3.3V

Are you sure none of the pins (especially PTH2) aren't being pulled above VDD by anything?

PTH2 is connected to an input on LTC2862 and a 10k pulldown. PTH2 current draw is dominated by the 10k pulldown. LTC2862 inputs don't have a pull-up mechanism.

Do you have any long tracks that could be causing undershoot or overshoot that could be going above VDD or below VSS?

The trace between PTH2 pin and LTC2862 pin is about 1 cm long, and is over a ground plane. There are some I2C and a buck converter nearby, but I expect a digital circuit like this to be pretty robust around noise. 

Actually, when I wired in PTC7 as a replacement for PTH2, I used bus wire and lengthened the trace.

[TomE]

> I'll ask software engineers to look at these.

They won't find anything looking at the source code. You need both Software and Hardware people working on the same unit at the same time. If you can get it failing with a debug pod connected (with the full source software loaded in the debugger) then you can hunt around from the debugger looking for anomalies, and can also rewrite the pin control registers to see if that fixes it. That's the only way forward.

> What kind of ESD issue are you talking about?

What kind of ESD issues have you got? The worst I've ever heard of was a fingerprint reader that had been adapted to run on Ethernet (by the addition of a serial-to-ethernet converter board). The box the reader was in wasn't earthed. So people shuffle across the carpet, build up 20kV, put their finger on it and the discharge went to case, to the micro's ground, through the CPU, out an address pin, then arced across where that track ran too close to the Ethernet output connector and down the Ethernet cable. They ended up with a BOX of dead converter boards.

Small zaps that don't kill things can still upset it.

I've worked on a project where the code had a table of the values loaded into all the port control registers, and periodically read them all back to see if any had changed, just in case any had "flipped". You may want to do the same to see if that code notices the cause of this problem.

Tom

[daveknight]

I tried 10k and 100k in series with DE/nRE, DI, and DO(basically all the pins between the LTC2862). 

I'll try working with software engineer to see if we can catch expected state of pin and actual state of pin being different.