Electronics > Microcontrollers

Port pin sometimes reads wrong after slow rising input has settled

(1/3) > >>

Circlotron:
Been using a 9S08FL micro with several port pins driven from the outside world via an RC network that gets to +5V in about 10mS. At power up there is a 50mS delay before the pin is read to make sure the RC is fully settled. Mostly it works just fine but on two occasion in maybe several hundred power ups the pin appears to be read as a low instead of a high. I know that slow moving inputs are not a good thing because there can be an uncertainty at the transition point, but the pin is read well after it has gone high. Scope has verified this. Could the slow rise cause the input buffer to be put into some kind of weird state before it gets read?

srb1954:

--- Quote from: Circlotron on August 17, 2022, 10:29:59 pm ---Been using a 9S08FL micro with several port pins driven from the outside world via an RC network that gets to +5V in about 10mS. At power up there is a 50mS delay before the pin is read to make sure the RC is fully settled. Mostly it works just fine but on two occasion in maybe several hundred power ups the pin appears to be read as a low instead of a high. I know that slow moving inputs are not a good thing because there can be an uncertainty at the transition point, but the pin is read well after it has gone high. Scope has verified this. Could the slow rise cause the input buffer to be put into some kind of weird state before it gets read?

--- End quote ---
This sounds as though it could be a metastability problem in the input logic or the input circuitry could be oscillating as the slow rising input voltage transitions through the logic threshold voltage.

Some of the 9S08 chips have synchroniser circuits on the input pins, which will clock the input signal through several flip-flops to ensure that a validly timed signal is presented to the processor core. If you a have a slow rising input signal that passes through the logic threshold voltage at or about the same time as the clock signal then the flip-flop can get stuck in a metastable state where the internal circuit nodes of the flip-flop are neither in a logic 0 or logic 1 state but temporarily stuck half way in between. Eventually, the flip-flop nodes will resolve themselves to proper logic levels but that may be at the wrong logic sense compared to what it should have been.

A similar situation exists if the input circuitry is oscillating during the transition through the threshold voltage. The synchroniser may again get stuck in the incorrect logic state depending on the exact timing relationship between the sampling clock and the input signal transitions.

I suggest you read up the reference manual for the processor to fully understand the input circuitry structure and follow that up with some research on metastability problems. The problem of metatstability is not often covered in digital design courses but it is always a problem when clocking asynchronous signals signals into synchronous circuitry. It can't be entirely eliminated but the probability of an error can be reduced to acceptably low levels by suitable circuit design techniques.

Circlotron:
Thanks for that srb1954. I know one proper solution would be to have a schmitt trigger between the RC and the port pin but there's not a lot of board space left so I'd much much much rather find some kind of software solution. Plus the expense of a revised board. Would it make any difference if I read the port pin multiple times and took what the majority of the read states were? Although if the synchronizing flipflops have already (erroneously) decided on a state I suppose that wouldn't make much difference. What if I momentarily configured the input to an output and back again? Would that reset the state of the synchronizing circuitry? I haven't yet found anything describing the IO circuitry in any worthwhile detail.

Circlotron:
Maybe a fix might be to use the A/D function and read the analog voltage presented to the pin and if it's > 75% of Vdd then call it a 1, less than 25% call it a 0. If in between those limits then something else is way wrong anyway.

srb1954:

--- Quote from: Circlotron on August 18, 2022, 12:36:37 am ---Thanks for that srb1954. I know one proper solution would be to have a schmitt trigger between the RC and the port pin but there's not a lot of board space left so I'd much much much rather find some kind of software solution. Plus the expense of a revised board. Would it make any difference if I read the port pin multiple times and took what the majority of the read states were? Although if the synchronizing flipflops have already (erroneously) decided on a state I suppose that wouldn't make much difference. What if I momentarily configured the input to an output and back again? Would that reset the state of the synchronizing circuitry? I haven't yet found anything describing the IO circuitry in any worthwhile detail.

--- End quote ---
Even if the flip-flop has gone into a metastable state it should eventually resolve itself to an operational state when the node voltages on the flip-flops slowly drift back to their normal operating range. This may take some time, us or even ms, and then a few more clock cycles should restore normal synchroniser operation.

I would just do a S/W fix and treat the input as though you were debouncing a noisy switch and keep taking S/W samples at several ms intervals until you see a stable, unchanging state over >3 samples.

If you have the opportunity for a H/W fix then a Schmitt trigger would be a good idea to provide a fast clean input signal to the chip. Also check the supply rails to the chip are clean and well bypassed; noise on the supply rails can affect the threshold voltages of the CMOS gates and make them prone to oscillation when presented with a slow input signal.

Navigation

[0] Message Index

[#] Next page