Confusion and possible bug on 16f876

[khufumen]

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

[Acetronics2]

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

[Melanie]

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.

[khufumen]

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.

[mister_e]

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.

[nimonia]

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

[Bruce]

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.

[khufumen]

"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