16F627A PortA.4 trouble?

[Gusse]

I didn't want to make a similar topic so therefore I'm including my findings here. I'm using 16F876A and also A.4 is causing some minor problems.

Code part "Test" is working OK, so PortA.1-5 and PortB.1-5 switching on and off.
Problem occurs with "Test2" on A.4. A.4 is always LOW, meaning that corresponding LED is always ON (other 9 LED's are OK).

I have pull-up for A.4 (open drain) so, it should goes up as soon as it is set high, as it does with "Test" code.
Any idea whats is wrong or how to fix it? At the moment I don't want to change make HW changes so SW is prefered

Mainloop:
    GOSUB Test
    GOSUB Test2
    GOTO Mainloop

Test:
    PortA = %00000000
    PortB = %00000000
    PAUSE 500
    PortA = %00111110
    PortB = %00111110
    PAUSE 500
    RETURN

Test2:
    LED = %11111111111
    GOSUB Select_LED
    PAUSE 500
    LED = %00000000000
    GOSUB Select_LED
    PAUSE 500
    RETURN
    
    
Select_LED:
    LED = ~LED        'Invert for P-FET supply for LEDs
    PortB.1 = LED.4   'LED4      
    PortB.2 = LED.6   'LED6      
    PortB.3 = LED.8   'LED8     
    PortB.4 = LED.10  'LED10      
    PortB.5 = LED.2   'LED2          
    PortA.5 = LED.5   'LED5      
    PortA.4 = LED.7   'LED7  !!!!!!!!Open drain    
    PortA.3 = LED.9   'LED9      
    PortA.2 = LED.1   'LED1      
    PortA.1 = LED.3   'LED3      
    RETURN

BR,
-Gusse-

[Gusse]

I tried everything that I knew, including ASM code, for PortA.4 but no help. I had to make a HW change and after that original code works OK (A.4 -> A.0).
If anyone has an explanation for this feature, I would like to hear it.

BR,
-Gusse-

[HenrikOlsson]

I'm throwing out my latest standard answer (or so it feels): Read-Modify-Write issue.
To test if this is the case insert a PAUSE 10 or whatever between the individual PortX.Y = LED.Z

Or try something like

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

/Henrik.

[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.