Confusion and possible bug on 16f876


+ Reply to Thread
Results 1 to 14 of 14
  1. #1
    Join Date
    Oct 2004
    Posts
    46

    Default Confusion and possible bug on 16f876

    I've been working with 16f876 chips for some time now using PIC BASIC Pro and have recently run into a strange phenomena that has me baffled. Pins 1 and 2 on PORTB have some issues I believe. They don't always go high as outputs when you tell them to go high. Check out this simple code:

    DEFINE OSC 20 ' define oscillator to be 20Mhz
    ADCON1 = 7 ' set pins to digital

    HIGH PORTA.5
    HIGH PORTC.4
    HIGH PORTB.5
    HIGH PORTB.4
    HIGH PORTB.1
    HIGH PORTB.2

    STOP

    If you run the above code I think you will find that PORTB.1 and PORTB.2 are still LOW. They never turned high!

    I am hoping someone can confirm my results.

    Kind Regards,
    Eric

  2. #2
    Join Date
    May 2004
    Location
    NW France
    Posts
    3,564

    Question

    Hi,

    I run a 16F876 @ 20 Mhz ... with a red/green led connected to PortB1 and B2 via 270 ohms ....everything perfect.

    Alain

    PS: did you set TRISB, even once ??? ( theoretically not compulsory ... but ... I always do !!!)

  3. #3
    Join Date
    Jul 2003
    Posts
    2,358

    Default

    I've many tens of thousands of 16F876's and 16F876A's in the field switching Relays on PortB... Pins are aliased and switched individually with HIGH & LOW commands... No issues or problems whatsoever.

    I NEVER use the STOP command... you just don't know what state the processor will remain in... This is kinder...

    StopLoop:
    Pause 1000
    Goto StopLoop

    I agree also with Alain... ALWAYS do TRIS functions.

  4. #4
    Join Date
    Oct 2004
    Posts
    46

    Default Response

    The problem is not with turning PORTB's Pins 1 and 2 on and off. If I individually select them to go high or low they will do so. The problem is when I have 6 high statements in a row and PORTB's pins 1 & 2 are included they will not go high.

    ' This works fine
    HIGH PORTB.1
    HIGH PORTB.2


    ' this does not work.
    HIGH PORTA.5
    HIGH PORTC.4
    HIGH PORTB.5
    HIGH PORTB.4
    HIGH PORTB.1
    HIGH PORTB.2

    note that PORTB.5 and PORTB.4 will go high as well as the other pins except PORTB.1 and PORTB.2

    I shall try using TRISB. I did use the goto loop instead of stop and had similar results.

  5. #5
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898

    Default

    that's really strange... i use this PIC since many times and never see that problem but can you confirm those...
    1. Is your supply line clean and properly filtered (0.1uF close to your PIC)?
    2. If on a bread-board and you use crystal, did you try to remove those capacitor around the crystal?

    looks more an hardware problem. Unsufficient supply line filtering, VCC drop when you have too many load on PORTB OR your total current on a PORT exceed the maximum rating of the PIC.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  6. #6
    Join Date
    May 2005
    Posts
    33

    Default information..

    just wat i've experimented lately... if u dnt set the tris register as in setting it to output it wont output high by doign portb.x = 1

    i foudn thsi out frm the matrix keypad example of lab-x1.

    for example if u do this:

    portb = $ff
    trisb = %10101010



    u get the even bits high... correct me if i'm wrong
    i've always tot tht u haf to set the tris b4 outputting something and this discovery has been very useful.

    sorry guys if u already knew bout this. just an info for those who doesnt
    Last edited by nimonia; - 20th May 2005 at 16:35.

  7. #7
    Join Date
    Oct 2004
    Posts
    46

    Default Continuing saga

    My supply voltage lines are clean to the PIC and I have a .1uf cap sitting next to the Vcc pin. The board I am working with is a board I had built by PCBExpress so the crystal and other components are not mounted on a breadboard. My total current useage for all componenents on the board is less than 30mA.

    Some background...
    A month ago I built a board using an 16f876. PortB Pins1 & 2 were used for communicating with an AT45 memory chip using ShiftIn and ShiftOut. My memory would sporadically lose data I was sending to it. It didn't happen all the time. It was one of the horrible random things that would occasionally happen. I spent weeks going through the code and electronics trying to narrow the problem down. I finally gave up and redid the board. Now I am having trouble with the same pins which in this version are being used to simply turn on and off power to some components. The memory is working fine in this version. When I add two and two together the culprit seems to be these two pins... all the others work fine.

    In any event, I will try out the TRISB method tonight and post the results.

    Kind Regards,
    Eric Berg

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

    Default

    What you're probably seeing is the read-modify-write anomally.

    When the PIC first initializes, all pins are set to inputs by default.

    Then using the PBP HIGH & LOW commands in consecutive order
    like this;

    HIGH PORTB.5
    HIGH PORTB.4
    HIGH PORTB.1
    HIGH PORTB.2

    This generates code that first writes a 1 to the port latch, then
    flips the TRIS bit for the pin to 0 to making the pin an output.

    However, the remaining pins are still configured as inputs until you
    land on the next HIGH statement for the next pin.

    This meets the conditions for the read read-modify-write bug with
    pins configured as inputs & outputs on the same port when using
    read-modify-write instructions like BCF & BSF on a port.

    The simple fix is to setup all output port latches & TRIS registers in
    the initialization/startup section of your code.
    Regards,

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

  9. #9
    Join Date
    Oct 2004
    Posts
    46

    Default Question to Bruce

    "The simple fix is to setup all output port latches & TRIS registers in
    the initialization/startup section of your code."

    Bruce - are you saying to use TRIS to set the pins as outputs when the program starts?

    Eric

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

    Default

    Absolutely.

    Example:

    DEFINE OSC 20

    MyVar VAR BYTE ' Define all variables, etc,,

    PORTB = %11110000 ' output logic at power-up
    TRISB = 0 ' all outputs

    Main: ' Main code starts here.

    The very first instructions that execute will be port latch setup (value
    to place on any output pin at power-up), followed by TRIS settings.
    Regards,

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

  11. #11
    Join Date
    Oct 2004
    Posts
    46

    Default A Super Thanks

    Thanks Bruce et all for your help and insights into helping solve this issue. I've probably put a good 15 hours overall into wrestling with this issue.

    Many thanks again!
    Kind Regards,
    Eric

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

    Default

    I'd always set TRIS before I do any Port I/O... so in Bruces example I'd initialise my PIC...

    TRISB = 0 ' all outputs
    PORTB = %11110000 ' output logic at power-up

    in that sequence.

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

    Default

    Hi Melanie,

    I used to do it that way as well until reading the 16F mid-range ref
    manual.

    9.11 Initialization

    It is recommended that when initializing the port, the data latch
    (PORT register) should be initialized first, and then the data direction
    (TRIS register). This will eliminate a possible pin glitch, since the PORT
    data latch values power up in a random state.
    Regards,

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

  14. #14
    Join Date
    Jul 2003
    Posts
    2,358

    Default

    Hi Bruce.

    Yeah... I read that too and disregarded it... didn't seem logical to start any I/O operation before you decided what the pin is going to be first. I normally follow the TRIS immediately with my pin initial state value... the school of thought being that the 1uS or so that a pin 'might' be in the wrong state at initialisation isn't going to do anything drastic. The most dangerous peripherals most folks could have are Relays, Contactors or SSR's - and they're just not going to react that fast. Further, there will be a number of clock cycles between physical Power-On and when the PIC actually wakes up and starts executing (kinda like me in the morning between the time the alarm clock goes off and my first cup of coffee!) and executes your first I/O Instruction and TRIS... now that is an indeterminate time anyway which is beyond our control during which the I/O pin will be high impedance - whatever you've got connected to that pin, and depending on the circuit, could float either way anyhow, so what's another uS between friends?

Posting Permissions

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