Log in

View Full Version : PORTB.0 Insanity



mokeymark
- 25th October 2007, 03:16
Ok, I'm using a PIC18F8722. Whenever I change the state of ANY pins on portb, I end up with portb.0 going high and staying that way. If I set portb = 0, then pause 1000, I end up with portb.0 staying low for a second then going high again at the end of the pause. I already tried "INTCON2.7 = 1" to disable the pullups. I don't have this problem on any other pins or ports. What am I missing??? Any help would possibly save my sanity and my marriage. No pressure.

-Mark Richards

paul borgmeier
- 25th October 2007, 04:23
Ok, I'm using a PIC18F8722. Whenever I change the state of ANY pins on portb, I end up with portb.0 going high and staying that way. If I set portb = 0, then pause 1000, I end up with portb.0 staying low for a second then going high again at the end of the pause. I already tried "INTCON2.7 = 1" to disable the pullups. I don't have this problem on any other pins or ports. What am I missing??? Any help would possibly save my sanity and my marriage. No pressure.

-Mark Richards

Strange - Have you set TRISB = 0?

What happens if you set the latch instead of the PORT? e.g., use "LATB = 0" instead of "PORTB = 0"

What is connected to RB0?

Are you using interrupts? (Is INTCON.7 = 0?)

mokeymark
- 25th October 2007, 08:18
I'm using an interrupt on USART:

INTCON = %11000000

The program is running through a loop, waiting for something to show up on the serial port. I'm using a CASE statement, so when I get particular data received on the first serial port I do a TRISx = 0 (where x = the port in the CASE statement) and set the appropriate I/O's HIGH or LOW.

I'll try the LATB = 0 when I get back in the lab.

Thanks,
Mark

sayzer
- 25th October 2007, 08:40
Sounds like an OSC issue to me.

===================

paul borgmeier
- 25th October 2007, 13:31
Still strange and still reaching here .... a long shot but it sounds like TRISB.0 could be getting changed somewhere during or after the Pause (by an erroneous interrupt?) – do you have an LCD hooked up where you can output the value of TRISB after your Pause that resets RB0 high?. The thought being you could monitor and see if it is getting changed. If you do not have an LCD or similar, you could put some lines like this in code AFTER the PAUSE for debugging purposes.


IF TRISB.0 = 1 THEN
High PortB.7 ' or whatever pin you have available
ELSE
Low PortB.7
ENDIF
Pause 10000 ' measure PORTB.7 and see how TRISB.0 is set

Let us Know


Sounds like an OSC issue to me.
Sayzer ... OSC???? - I am interested in your theory – can you explain?

sayzer
- 25th October 2007, 13:46
....

Sayzer ... OSC???? - I am interested in your theory – can you explain?

When I worked with PICs with different internal OSC frequencies, like PIC18F8722, I had similar problems with latching PORTs.

I am not sure if Mark is using Internal OSC but what he is having sounds like it.

Mark, what is your OSC setting?

=============

mokeymark
- 25th October 2007, 17:44
I apologize for wasting your valuable time; I just combed through all of my code and found a stinking typo that resulted in PORTB.0 being set in another part of the program. That's why I could hold it low, but it would go high again as soon as I exited the interrupt service routine. Wow, I'm so ashamed! Thank you all; I have learned a valuable lesson. One important lesson is to get some sleep in stead of trying to work around the clock to finish the project!