16F627A PortA.4 trouble?

[spcw1234]

I can't drive porta.4 high on this 16f627A, what am I missing?

All other pins on port A work fine (A.5 is input only)
Comparators are disabled
The TRISA is set to all 0's for output



define OSC 04 '4MHz internal oscilator
clear
cmcon = 7
OPTION_REG.7 = 1
trisa = 0
trisb = 0

main:
porta=255
pause 1000
porta=0
pause 1000
goto main

end

[HenrikOlsson]

Hi,
Checked the datasheet lately? ;-)

PORTA is an 8-bit wide latch. RA4 is Schmitt Trigger input and an open drain output.

Open drain output, only switches to GND, floating when set "high".

/Henrik.

[spcw1234]

Thank you Henrik! I saw the OD under output type, and wasn't putting it together for some reason.

[timmers]

Add a pull up resistor, then it will work. Depends on what you are driving as to what value to use.

[spcw1234]

Right you are. No easy way to add that to these PCB's though...

[spcw1234]

I am not liking this chip! Maybe I should go back to my more familiar 18F parts! :)

New problem, I was trying to setup the capture module using timer1 and I accidentally configured timer1 to use an external osc which made me loose control of those pins as general I/O's. Problem is, now my programmer can't re-program the chip to change it. It doesn't detect the PIC. Not sure why an MCLR reset won't allow me to use the timer1 OSC pins as PGC and PGD, but it isn't working. Any ideas?

[spcw1234]

OK, I bricked 2 of these chips now... With this code?



Capture VAR PIR1.2
T1CON.5=1 '1:4 prescaler
T1CON.4=0 '1:4 prescaler
T1CON.3=1 'Timer1 OSC enabled
T1CON.2=1 'sychro clock
T1CON.1=0 'internal clock
T1CON.0=1 'start timer


It works fine until I add the above into my program, then it seems portb.7 gets fried and I have to replace the chip to program again.

[HenrikOlsson]

Hi,
Just a shot in the dark here, can it have anything to do with LVP, do you have it turned OFF in the CONFIGs?

What programmer are you using to program the chips? Once they are "bricked" can't you even erase them?

/Henrik.

[spcw1234]

LVP is off, the chip still works 100% except portb.7 (maybe portb.6 too, I don't have anything on that pin) I have an LED on portb.7, which works fine until I add the above code. The programmer is a PICFlash2. It does not recognize the chip at all, won't allow me to erase, read, write, etc... I really need to use the capture module, but I can't keep bricking these chips. Not sure how to proceed from here.

Thanks!

[HenrikOlsson]

Hi,
I think the pin stop working because you enable the oscillator for TMR1, the oscillator uses RB6 and RB7 so they can't then be used as I/O.

I see you're using internal oscillator, are you using internal MCLR as well by any chance?

Looking around there seems to be an issue with using internal oscillator and internal MCLR and initially setting PGD/PGC pins as outputs - or something like that. In that case the device apparently can't enter programming mode without the device programmer applying Vpp before Vdd which apparently not all device programmers can do - again, or something like that. See this (http://www.microchip.com/forums/tm.aspx?m=409635&high=bricked) for example.

Not saying this IS the case in your case but it does "smell" like it to me.

/Henrik.

[spcw1234]

I am using external MCLR pulled high with a 4k7 resistor. That does sound like what is happening, except I am not using the internal MCLR. I am also using an external VDD, and I didn't terminate a VDD pin on my ICSP connector.

It is a surface mount chip, and I replaced it again.

I plan to order an 18F1220 as that has the enhanced CCP module, which my code is already written to work with. I was just trying to cut costs, but it has been a headache. I need a pin compatible chip to the 16F627A since I already have the PCB's, assuming I don't get this working.

[Bruce]

Clear T1CON.3. If your programmer won't allow you to reprogram them with this bit set, at least you shouldn't have the same problem with new ones. You only enable TMR1 osc if you're using an external oscillator.

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

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