16F627A PortA.4 trouble?

[Gusse]

I'll try this approach, but can't test it right now. I'll be back tomorrow to tell if this is working.
Anyway, it is very odd that bit level command fail and byte level is OK...

BR,
-Gusse-

[HenrikOlsson]

Hi Gusse,
No it's not really. All writes to a port are performed as a read-modify-write operation. When you do a byte write the port is read, the new value is written to the internal register and then written to the actual port.
When you do a bit level write the port is read, the bit in question set/reset and then the byte is written back to the port. (This is how the PIC works at the hardware level.)

When you do several concecutive bit operations like you're doing there is a possibillity that the actul voltage at "previous" pin hasn't actually reached the threshold voltage for the logic level that previous command set it to. So when the PIC performs the read it actually reads a high even though the previous command set it low. And because it reads a high that is what get written back to port.

If you'd perform several concecutive byte writes to the port it's likely you'll see the same effect.

Now, in your case I can't say for sure that RMW is the problem but since you've verified the pin DOES toggle between low and "off" (high impedence) when you do a write to the full port it does sound like it.

/Henrik.

[Demon]

Thanks for re-explaining that issue Henrik. I had missed previous posts and didn't know of this issue. Now if only I can remember it by tomorrow.

And even if it ends up being lost on me, your explanation to a funky problem like this one is bound to help at least one other person anyways. So your effort was most likely not wasted after all.

Robert


EDIT: I can only assume something like this is going to happen more often as PIC speeds increase. It's quite a difference from the common 8Mhz when I started to todays 48MHz.

(I know, there's most likely even faster PICs coming out the door)

[HenrikOlsson]

Hi Robert,
The effect is increased due to several reasons. In a perfect world there wouldn't be an issue but due to capacitive loading on the pins etc the effect increases as the speed goes up. Some PICs (the larger ones) may not have the +/25mA drive capacity on the port pins so there it'll take even longer to "charge" to external capacitance and bring the voltage up.

18F devices and I believe the newer 16Fxxxx devices have LAT registers associated with each port. Writing to LATx instead of PORTx bypasses the issue completely because the inherent RMW operation is then performed against the LAT (which is the port latch register) instead of the actual port pins.

/Henrik.

[Gusse]

Or try something like

TempByteA VAR BYTE
TempByteA.1 = LED.1
TempByteA.2 = LED.2
'etc
PortA = TempByteA
'etc

This is working workaround for the issue. Thanks!

When you do several concecutive bit operations like you're doing there is a possibillity that the actul voltage at "previous" pin hasn't actually reached the threshold voltage for the logic level that previous command set it to. So when the PIC performs the read it actually reads a high even though the previous command set it low. And because it reads a high that is what get written back to port.

If you'd perform several concecutive byte writes to the port it's likely you'll see the same effect.

I haven't seen that kind of issues before and with current project the A.4 was failing in bit-mode. Even if A.4 was moved to be first port operation, it still failed.

Hi Robert,
The effect is increased due to several reasons. In a perfect world there wouldn't be an issue but due to capacitive loading on the pins etc the effect increases as the speed goes up. Some PICs (the larger ones) may not have the +/25mA drive capacity on the port pins so there it'll take even longer to "charge" to external capacitance and bring the voltage up.

18F devices and I believe the newer 16Fxxxx devices have LAT registers associated with each port. Writing to LATx instead of PORTx bypasses the issue completely because the inherent RMW operation is then performed against the LAT (which is the port latch register) instead of the actual port pins.

All port that I use are driving high impedance load, P-FET gate (+ 56k pull-up to VCC), so definitively ports are not heavily loaded.
I think this i a real bug, but don't know is it in PBP or somewhere else.

[Darrel Taylor]

P-FET gate (+ 56k pull-up to VCC)

Try a MUCH smaller resistor. ~4.7K

The rise time needs to be fast enough to avoid the R-M-W issue Henrik talked about.
The other pins are driven high in a matter of nanoseconds.
A 56K resistor will probably take much longer.

I think this i a real bug, but don't know is it in PBP or somewhere else.

It's not a bug in PBP. It's just the way the hardware works.

[Gusse]

OK. I might do some trials later, but more robust solution for me was to change control away from A.4.
If open drain requires that port rise time must be within some specific time range when using xxMHz XTAL, then that should be mentioned more clearly. At least I have missed this information.

-Gusse-