16F627A PortA.4 trouble?


Closed Thread
Results 1 to 22 of 22
  1. #1
    Join Date
    Apr 2007
    Location
    Pennsylvania, USA
    Posts
    158

    Default 16F627A PortA.4 trouble?

    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

    Code:
    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
    Shawn

  2. #2
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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.

  3. #3
    Join Date
    Apr 2007
    Location
    Pennsylvania, USA
    Posts
    158


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

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

  4. #4
    Join Date
    Apr 2011
    Location
    Kent, UK
    Posts
    52


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

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

  5. #5
    Join Date
    Apr 2007
    Location
    Pennsylvania, USA
    Posts
    158


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

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

  6. #6
    Join Date
    Apr 2007
    Location
    Pennsylvania, USA
    Posts
    158


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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?
    Shawn

  7. #7
    Join Date
    Apr 2007
    Location
    Pennsylvania, USA
    Posts
    158


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

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

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

  8. #8
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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.

  9. #9
    Join Date
    Apr 2007
    Location
    Pennsylvania, USA
    Posts
    158


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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!
    Shawn

  10. #10
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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 for example.

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

    /Henrik.

  11. #11
    Join Date
    Apr 2007
    Location
    Pennsylvania, USA
    Posts
    158


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

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

  12. #12
    Join Date
    Jul 2003
    Posts
    2,405


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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.
    Regards,

    -Bruce
    tech at rentron.com
    http://www.rentron.com

  13. #13
    Join Date
    Dec 2007
    Location
    Finland
    Posts
    191


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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

    Code:
    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-

  14. #14
    Join Date
    Dec 2007
    Location
    Finland
    Posts
    191


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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-

  15. #15
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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
    Code:
    TempByteA VAR BYTE
    TempByteA.1 = LED.1
    TempByteA.2 = LED.2
    'etc
    PortA = TempByteA
    'etc
    /Henrik.

  16. #16
    Join Date
    Dec 2007
    Location
    Finland
    Posts
    191


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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-

  17. #17
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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.

  18. #18
    Join Date
    Jan 2005
    Location
    Montreal, Quebec, Canada
    Posts
    2,588


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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)

  19. #19
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,516


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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.

  20. #20
    Join Date
    Dec 2007
    Location
    Finland
    Posts
    191


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    Quote Originally Posted by HenrikOlsson View Post
    Or try something like
    Code:
    TempByteA VAR BYTE
    TempByteA.1 = LED.1
    TempByteA.2 = LED.2
    'etc
    PortA = TempByteA
    'etc
    This is working workaround for the issue. Thanks!

    Quote Originally Posted by HenrikOlsson View Post
    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.

    Quote Originally Posted by HenrikOlsson View Post
    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.

  21. #21
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    Quote Originally Posted by Gusse View Post
    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.
    DT

  22. #22
    Join Date
    Dec 2007
    Location
    Finland
    Posts
    191


    Did you find this post helpful? Yes | No

    Default Re: 16F627A PortA.4 trouble?

    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-
    Last edited by Gusse; - 14th February 2012 at 08:26.

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts