Error after hard reset of a MC68360 QUICC

[jeromeg2]

Hi all,

I've got a problem when performing a hard reset on a board using a MC68360 QUICC.

Basically, I use PA6 as a RS485 RX signal and PA7 as TX.

When /RESETH is driven low and maintained at low level, I expect to see PA7 goes in High-Z even if RX frames continue to come to the board. But sometimes, PA7 doesn't seem to go in High-Z (it stays at previous level). Even worse, after some milliseconds, it echoes RX frames leading to a failure detected by the board that communicates with it.

What could be wrong with the QUICC ?

Best regards,

Jérôme

[alexander_yakov]

Do you assert only RESETH? RESETH should be asserted simultaneously with RESETS.

[TomE]

Alexander writes:

> Do you assert only RESETH? RESETH should be asserted simultaneously with RESETS.

Is there a bug in the chip or in the Manual that requires that? The manual is pretty clear on that:

MC68360 USER’S MANUAL (no version, no date, but 1996 or prior):

4.7 RESET OPERATION

When the reset control

logic detects that an external device drives RESETH low, it starts driving both internal

and external RESETS and RESETH low for 512 cycles to guarantee this length of reset to

the entire system. The external and the internal resets are released after the external device

stops driving the external reset signal low or after the 512 cycles, whatever is later. Figure

4-46 shows the reset timing.

Back to the OP's question.

Have you read through the Chip Errata? Your problem sounds like:

MC68360DEB2.pdf

Device Errata

MC68360 QUICC

Revision B.2. Masks 2C69T, 0F35G, 1F35G, 0F34G, and 1F34G.

January 26, 1996

10. Parallel I/O pins are not three-stated immediately after Reset

When the QUICC is reset, the parallel I/O pins (Port A, B, and C) are not three stated until the PLL locks.

Thus, any port pins that are programmed as outputs may continue driving until the PLL re-locks after

reset. This problem will also occur during power-up reset. In this case, the parallel I/O pins will be in an

indeterminate state until the PLL locks. The fix for this has not yet been scheduled.

That problem is still present in 'Revision B.4. Mask 4F35G.", "Revision C.0. Masks 0E63C, 0F15W." and "Revision C.1. Masks 1E68C, 0G24F.". It looks like it was never fixed.

Tom

[jeromeg2]

Thank you for your answers.

First, RESETS is just pulled up.

I had already read the chip errata with interest on that point but I first dismissed this hypothesis because it doesn't explain why PA7 echoes RX frames and why it can happen up to 400ms after RESET (PLL will lock much faster ?).

But now I think there might be several hundred ms between the PLL locks and the echo because I have observed that if a put an oscilloscope probe on PA7 when RESET is low and has been going well, PA7 who was high-Z obviously becomes low but when I remove the probe, the same phenomenon appears ie several hundred ms after PA7 echoes RX frames:

--> when RESET is asserted low, it seems that the transition of an I/O pin from low to high-Z (because of the probe or because what explained in chip errata) causes the QUICC to behave in a bad way...

[TomE]

What is the software doing at those times? When does it program the pins and the serial controller? Or are you coming up into a Bootstrap of some sort and the pins don't get programmed until you make it run some other code?

Also, how can you monitor what PA7 is doing if you've removed the CRO probe from it? Obviously the 10M probe pulls the pin down, but when you remove the probe you don't know what level it goes to. How about putting a pot on it. You might be able to say you get TX Echo above 0.5V, or 1V or 2V. If it happens at a specific voltage level it might tell you something.

Are you sure the transceiver isn't doing this? The transceiver is a RS485 one. Do you have any I/O pins controlling Enable, Mode or Power on the transceiver? I know that you can get character echo (TX to RX) on a disconnected RS-232 cable. If the transceiver is disabled you might be getting capacitive coupling between the wires in the cable - except the CRO traces don't look like that. It looks like you're not using single-pair RS485, so maybe multiple devices form a "ring". is there any "bypass" logic that links RX and TX when a device is disabled to keep data going around the "ring"?

What is the DELAY between the edges on the RX and TX signals? Is it a few nanoseconds (wire delays), 50ns (silicon delays), 500ns (transceiver delays) or is it a longer delay though something that is being clocked?

Tom

[jeromeg2]

Thank you very much for your answer Tom.

At the moment, I don't worry about the software.

Sorry I did a mistake, what is called "TX at PA7" on the previous picture is TX at the output of a 74HCT125 (with a pull-up to +Vcc) which is connected to a RS485 transceiver. So I measure TX at the output of 74HCT125 and put/remove the probe at PA7 of µ.

So when RESET goes well, TX observed at the output of  74HCT125 shall be high because of the pull-up. But when the RESET goes wrong, output is low for some hundred ms meaning that PA7 is not high-Z and that leads to the problem.

Our RS485 transceiver is a MAX491 and there is no bypass function. Thus, I've already tried to disconnect TX signal from the transceiver (by raising the TX input pin of the transceiver) but the echoes are still observed at the output of 74HCT125.

By the way, our transceiver has an enable pin coming from the QUICC (D24). If the enable pin was not driven on RESET, the problem may be still present on the board but will not be seen by the other computer board because frames will not be transmitted but I've observed that D24 also is not high-Z correctly during a bad reset.

Concerning the delay, I cannot put a probe directly on PA7 because it will prevent the failure to happen. So I put a probe on RX at µ (PA6) and on TX after 74HCT125. (According to datasheet of 74HCT125 and measurements, delay between TX at µ and TX after 74HCT125 is 12ns). --> I find a delay of about 17ns.

Below you can see the echo phenomenon

[TomE]

68360. Those things are nearly 20 years old. How come you're working on these now? How can you get a failure after all this time?

> But when the RESET goes wrong, output is low for some hundred ms meaning

> that PA7 is not high-Z and that leads to the problem.

What voltage do you expect on PA7 when it is "high-Z"? When you put an oscilloscope probe on it the probe will pull it down. When it is "high-Z" it is floating. The voltage is indeterminate. It depends on whatever electrons are leaking into and out of the trace capacitance

When the probe is removed the voltage is zero. It then starts floating up due to various giga-ohm leakages. 200ms later it gets to 1.4V or 1.5V or 2.5V or whatever the 74HCT125 threshold is. Meanwhile there's 1/10 of a volt of signal being coupled across from the received data trace, and that starts toggling the output. There's your "echo".

If the design needs a "defined state" on a CPU output pin when it is reset and before it is configured then you have to have resistive pull-ups or pull-downs on those pins to establish the level. Some other chips default to weak pullups on the pins on reset to make this easier without requiring extra components.

Tom

[jeromeg2]

Again thank you for taking time to answer.

I'm working on an old product but still produced. I think the problem has always been here but never seen because the boards are always ON and never reseted.

You are talking about signal being coupled across from the received data trace but if it was the case, wouldn't I see it even when reset goes well? ...

When I said output is low when RESET goes wrong, I'm not putting a probe on PA7 but at the output of 74HCT125 where there is a 10k pull-up so if I have a low level at the output I assume PA7 is not high-Z but forced to low. Am I wrong?

On the other way, when I put a pull-up directly on PA7, PA7 always goes high when reseted meaning that it is not forced to low ... So having a low level at the output of a 74HCT125 (with a pull-up on the output) doesn't necessary mean the input is forced to low?

Jérôme

[TomE]

"High-Z" doesn't mean "at a high voltage". It means "high impedance" or "high resistance". It means "floating in the breeze like a party balloon".

"High-Z" isn't a state like "0" or "1" that can be propagated through a logic gate. It isn't a third level. "High-Z" on the input of a gate does not mean the output will be "High-Z".

> You are talking about signal being coupled across from the received data trace but if it was the case, wouldn't I see it even when reset goes well?

Once the Software has programmed the PA7 pin and is actively driving it, the capacitance of the other track will have no effect.

Whether this problem happens or not depends on how long the RESET is asserted, and then how long the software takes after RESET to program the pin and get it under control. Given that, it then depends on the exact current leakage conditions (and temperature and humidity) of a particular board that controls what the "floating pin" is doing during that time when the pin is uncontrolled. Residual contamination on the board (or within the board) and minute leakages in all chips on the track may result in it floating "Up", "Down", to some intermediate level and that superimposed with a fraction of any nearby AC signals.

In your testing you are making this worse by holding RESET down for a long time. This shouldn't happen during normal operation. So are you creating a problem that doesn't happen (or doesn't happen often) during normal operation?

> Sorry I did a mistake, what is called "TX at PA7" on the previous picture is TX at the output of a 74HCT125

> (with a pull-up to +Vcc) which is connected to a RS485 transceiver.

Each gate on a 74HCT125 has three pins. It has Input, Output and Output Enable. Does PA7 connect to the Input or the Output Enable? Since you say there's a resistor on the output, the circuit would make no sense unless PA7 connects to the Output Enable pin, the Input is grounded and the 74HCT125 is being used in the circuit as an inverter.

> So when RESET goes well, TX observed at the output of  74HCT125 shall be high because of the pull-up.

No, that doesn't follow at all. The output will only be pulled up by the resistor when the Output is disabled, and that only happens when the Output Enable pin is driven high. Or is "floating high". "Tri-state" isn't a property of a track or a pin that is propagated through the 74HCT125 from an input to an output. The gates only respond to the voltage on their inputs.

> But when the RESET goes wrong, output is low for some hundred ms meaning that PA7 is not high-Z and that leads to the problem.

PA7 is high-Z. "high-Z" means high RESISTANCE and not high VOLTAGE.

I'll prove it to you. Add a 100k pull-up resistor to PA7. Does that fix the problem?

Then, instead of the pullup, add a 100pF capacitor to PA7. That should hold the floating pin at its previous state for a few seconds or more. It should also swamp the capacitively-coupled receive signal and prevent the echo.

The original design is bad as it should have always had a pullup on PA7.

> So having a low level at the output of a 74HCT125 (with a pull-up on the output) doesn't necessary mean the input is forced to low?

That is correct. It doesn't necessarily mean the input is FORCED to low. It may also mean the input is FLOATING low due to the 10pF or so of trace, pin and silicon capacitance, and the lack of any current flowing into the trace to make it go high. From the maths, a picoamp per picofarad gives you one volt per second.

If you reset a board when it is driving the pin high it may stay "floating high" for the duration of the reset and you won't see a problem. Or it may "drift down" and echo.

If you reset a board when it is driving the pin *LOW* it may stay "floating low" for the duration, and that time you'll see a problem. Or it may "drift up" and echo.

So it may depend on the microsecond-level timing of when the Reset is generated on a working board. That may explain why sometimes it gives a problem and sometimes it doesn't.

For a newly-powered on board, the "floating voltage" could end up as anything.

Tom

[jeromeg2]

I'am actually reading §7.10 SERIAL COMMUNICATION CONTROLLERS (SCCS) and it talks about loopback and echo mode:

Maybe my QUICC goes to loopback mode or something like that, I keep reading...