WTD: suggestion for sulking 16F877

D

Don Taylor

Guest
I've successfully used 16F627's in the past and was doing a similar
project with a 16F877, a couple of switches and a bank of leds.

I'm using an external RC oscillator 50 or 100 pf, 5 or 10 kohms.
Scope shows a very pretty RC sawtooth running on the clock input,
very nice squarewave running on the /4 clock output, frequencies
are within the ballpark for the 4Mhz part and change as expected
when I switch values for R and/or C.

I've got a nice RC pair on the MCLR/ and it is sitting high.

Configuration word is 0x3F73 which means
11 disable flash memory code protection
1 disable in-circuit-debug, use RB6,RB7 for i/o instead
1 unimplemented
1 disable flash memory write protect
1 disable eeprom protect
0 disable in-circuit low voltage programming, use RB3 for i/o
1 enable brown-out reset of the processor
11 disable flash memory code protection
0 enable 72ms power up delay timer to stabilize before starting up
0 disable watchdog timer
11 resistor-capacitor oscillator
11111101110011=0x3F73

I've reduced the code down to the point now where I do nothing
but set TRISB, TRISC, TRISD all zero to make them outputs
and set PORTB=0x55, PORTC=0x55, PORTD=0x55 just to see 1's and 0's
on the outputs and go into an infinite loop.

The MPLAB simulates all this and shows the output ports set.
The PG2B programmer happily reads the hex file, sees the part,
programs it, confirms the programming... and there is no joy.

All the pins on the part sit there sulking at logic zero.
I'd almost think that the code isn't even starting to run.

Can anyone see something really silly that is staring at me
and that I just haven't recognized?

Many thanks
 
In article <3f8b0b89_5@127.0.0.1>, dont@agora.rdrop.com says...
I've successfully used 16F627's in the past and was doing a similar
project with a 16F877, a couple of switches and a bank of leds.

I'm using an external RC oscillator 50 or 100 pf, 5 or 10 kohms.
Scope shows a very pretty RC sawtooth running on the clock input,
very nice squarewave running on the /4 clock output, frequencies
are within the ballpark for the 4Mhz part and change as expected
when I switch values for R and/or C.

I've got a nice RC pair on the MCLR/ and it is sitting high.

Configuration word is 0x3F73 which means
11 disable flash memory code protection
1 disable in-circuit-debug, use RB6,RB7 for i/o instead
1 unimplemented
1 disable flash memory write protect
1 disable eeprom protect
0 disable in-circuit low voltage programming, use RB3 for i/o
1 enable brown-out reset of the processor
11 disable flash memory code protection
0 enable 72ms power up delay timer to stabilize before starting up
0 disable watchdog timer
11 resistor-capacitor oscillator
11111101110011=0x3F73

I've reduced the code down to the point now where I do nothing
but set TRISB, TRISC, TRISD all zero to make them outputs
and set PORTB=0x55, PORTC=0x55, PORTD=0x55 just to see 1's and 0's
on the outputs and go into an infinite loop.

The MPLAB simulates all this and shows the output ports set.
The PG2B programmer happily reads the hex file, sees the part,
programs it, confirms the programming... and there is no joy.

All the pins on the part sit there sulking at logic zero.
I'd almost think that the code isn't even starting to run.

Can anyone see something really silly that is staring at me
and that I just haven't recognized?
Click to expand...
Are you using the ACTUAL 877 or are you using an 877A part?
If you are using an 'A' part try disabling the brown out detector.

Jim
 
Check out PICLIST.com
They have a good news group etc.
:) Roy
"James Beck" <jim@reallykillersystems_INVALID_.com> wrote in message
news:MPG.19f4dee4f35ccb429898d5@news.east.earthlink.net...
In article <3f8b0b89_5@127.0.0.1>, dont@agora.rdrop.com says...
I've successfully used 16F627's in the past and was doing a similar
project with a 16F877, a couple of switches and a bank of leds.

I'm using an external RC oscillator 50 or 100 pf, 5 or 10 kohms.
Scope shows a very pretty RC sawtooth running on the clock input,
very nice squarewave running on the /4 clock output, frequencies
are within the ballpark for the 4Mhz part and change as expected
when I switch values for R and/or C.

I've got a nice RC pair on the MCLR/ and it is sitting high.

Configuration word is 0x3F73 which means
11 disable flash memory code protection
1 disable in-circuit-debug, use RB6,RB7 for i/o instead
1 unimplemented
1 disable flash memory write protect
1 disable eeprom protect
0 disable in-circuit low voltage programming, use RB3 for
i/o
1 enable brown-out reset of the processor
11 disable flash memory code protection
0 enable 72ms power up delay timer to stabilize before
starting up
0 disable watchdog timer
11 resistor-capacitor oscillator
11111101110011=0x3F73

I've reduced the code down to the point now where I do nothing
but set TRISB, TRISC, TRISD all zero to make them outputs
and set PORTB=0x55, PORTC=0x55, PORTD=0x55 just to see 1's and 0's
on the outputs and go into an infinite loop.

The MPLAB simulates all this and shows the output ports set.
The PG2B programmer happily reads the hex file, sees the part,
programs it, confirms the programming... and there is no joy.

All the pins on the part sit there sulking at logic zero.
I'd almost think that the code isn't even starting to run.

Can anyone see something really silly that is staring at me
and that I just haven't recognized?


Are you using the ACTUAL 877 or are you using an 877A part?
If you are using an 'A' part try disabling the brown out detector.

Jim
Click to expand...
 
"Don Taylor" <dont@agora.rdrop.com> wrote in message
news:3f8b0b89_5@127.0.0.1...

All the pins on the part sit there sulking at logic zero.
I'd almost think that the code isn't even starting to run.
Click to expand...
I don't know this part but.... Are the outputs open collector? Do you need
to enable internal pull-ups or provide external ones?
 
"Don Taylor" <dont@agora.rdrop.com> wrote in message
news:3f8b0b89_5@127.0.0.1...

All the pins on the part sit there sulking at logic zero.

I'd almost think that the code isn't even starting to run.
Click to expand...
Are you sure it did start to run ? How ?

Jan-Erik.
 
Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> writes:
"Don Taylor" <dont@agora.rdrop.com> wrote in message
All the pins on the part sit there sulking at logic zero.

I'd almost think that the code isn't even starting to run.

Are you sure it did start to run ? How ?
Click to expand...
Other than seeing the supplies are stable and the osc in and out
are looking exactly like what I would expect I see nothing from the
part. So, how could I tell whether it started to run or not?

As I said in my original post, the reset pin is pulled up, I've
triple checked the configuration word and I've searched all the
Microchip website for anything like this. There was one posting
about all the pins being held low but that was for someone who had
written PORTE and accidentally driven the part into master/slave
mode and so couldn't get anything out of PORTD, which isn't happening
with mine. And, yes it is a 16F877, not a 16F877A.

Thanks
 
Don Taylor <dont@agora.rdrop.com> wrote in message
news:3f8b0b89_5@127.0.0.1...
I've successfully used 16F627's in the past and was doing a similar
project with a 16F877, a couple of switches and a bank of leds.

I'm using an external RC oscillator 50 or 100 pf, 5 or 10 kohms.
Scope shows a very pretty RC sawtooth running on the clock input,
very nice squarewave running on the /4 clock output, frequencies
are within the ballpark for the 4Mhz part and change as expected
when I switch values for R and/or C.

I've got a nice RC pair on the MCLR/ and it is sitting high.

Configuration word is 0x3F73 which means
11 disable flash memory code protection
1 disable in-circuit-debug, use RB6,RB7 for i/o instead
1 unimplemented
1 disable flash memory write protect
1 disable eeprom protect
0 disable in-circuit low voltage programming, use RB3 for i/o
1 enable brown-out reset of the processor
11 disable flash memory code protection
0 enable 72ms power up delay timer to stabilize before
starting up
0 disable watchdog timer
11 resistor-capacitor oscillator
11111101110011=0x3F73

I've reduced the code down to the point now where I do nothing
but set TRISB, TRISC, TRISD all zero to make them outputs
and set PORTB=0x55, PORTC=0x55, PORTD=0x55 just to see 1's and 0's
on the outputs and go into an infinite loop.

The MPLAB simulates all this and shows the output ports set.
The PG2B programmer happily reads the hex file, sees the part,
programs it, confirms the programming... and there is no joy.

All the pins on the part sit there sulking at logic zero.
I'd almost think that the code isn't even starting to run.

Can anyone see something really silly that is staring at me
and that I just haven't recognized?

Many thanks
Click to expand...
I'd also disable the Brownout and the startup timer for initial test
purposes. Just use a long time constant (say 2 seconds) on the MCLR reset
pin. I've had a similar lock-up problem in the past. Found it was a slow +5V
power supply ramp-up.
regards
john
 
"Don Taylor" <dont@agora.rdrop.com> wrote in message
news:3f8dace7$1_5@127.0.0.1...

Other than seeing the supplies are stable and the osc in and out
are looking exactly like what I would expect I see nothing from the
part. So, how could I tell whether it started to run or not?
Click to expand...
Aren't the port pins configured as Inputs at Reset? If you see all 0V then
you probably are writing to the port config register correctly at least
(otherwise any pull-ups on inputs will give you logic 1).
 
"CWatters" <colin.watters@pandora.be> writes:
"Don Taylor" <dont@agora.rdrop.com> wrote in message
news:3f8dace7$1_5@127.0.0.1...

Other than seeing the supplies are stable and the osc in and out
are looking exactly like what I would expect I see nothing from the
part. So, how could I tell whether it started to run or not?

Aren't the port pins configured as Inputs at Reset? If you see all 0V then
you probably are writing to the port config register correctly at least
(otherwise any pull-ups on inputs will give you logic 1).
Click to expand...
#include <pic.h>
__CONFIG(0x3F33);
main()
{ TRISB = 0x00; TRISC = 0x00; TRISD = 0xe0;
PORTB=0x55; PORTC=0x55; PORTD=0x55;
while(TRUE)
;
}

I have tried all the suggestions people have made thus far.

With this config word I've turned off the brownout, turned off the
power up delay, wired the reset input low and only let it go high
several seconds after power up, checked that the supply is clean
and has decoupling caps right next to the part, checked the RC
oscillator to see that it is running cleanly, have nothing else
connected to the part...

And all the outputs sit there sulking at logic low. I'm using a
resistor & led as a cheap logic probe and every one of the pins
pulls that led down hard enough to turn it on just as brightly as
tying the led to ground. Voltmeter gives same results, almost 0v.

Anyone else got an idea?

Thanks
 
"Don Taylor" <dont@agora.rdrop.com> wrote in message
news:3f8ef40f_5@127.0.0.1...
"CWatters" <colin.watters@pandora.be> writes:
"Don Taylor" <dont@agora.rdrop.com> wrote in message
news:3f8dace7$1_5@127.0.0.1...

Other than seeing the supplies are stable and the osc in and out
are looking exactly like what I would expect I see nothing from the
part. So, how could I tell whether it started to run or not?

Aren't the port pins configured as Inputs at Reset? If you see all 0V
then
you probably are writing to the port config register correctly at least
(otherwise any pull-ups on inputs will give you logic 1).

#include <pic.h
__CONFIG(0x3F33);
main()
{ TRISB = 0x00; TRISC = 0x00; TRISD = 0xe0;
PORTB=0x55; PORTC=0x55; PORTD=0x55;
while(TRUE)
;
}
Click to expand...
I guess your C compiler sets the banksel? Have you tried a simple ASM
program like that?

Regards,
Bob Monsen
 
"Robert Monsen" <postmaster@BulkingPro.com> writes:
"Don Taylor" <dont@agora.rdrop.com> wrote in message
#include <pic.h
__CONFIG(0x3F33);
main()
{ TRISB = 0x00; TRISC = 0x00; TRISD = 0xe0;
PORTB=0x55; PORTC=0x55; PORTD=0x55;
while(TRUE)
;
}

I guess your C compiler sets the banksel? Have you tried a simple ASM
program like that?
Click to expand...
Well, thanks to everyone who has had a suggestion. But nothing has
worked yet. Here is the program read back out of the part and
disassembled, with my comments included. There are a few redundant
bytes of code there but I haven't turned on the compiler optimization,
no need to add any more risk optimizer bugs by trying to squeeze a
few bytes out of a 15 byte program.

My guess is that the part is never beginning to run. But I've
disabled all the "features" and I manually hold reset low for seconds
before it is allowed to run. It is a 5 amp supply driving a 50 ma
part, it has decoupling caps, voltage polarity is right, part is
repeatedly accepted by the programming hardware and confirms the
programming. But maybe something is latching up the part. Microchip
website searching turns up nothing. I'm stumped.

Any other ideas to try?
Thanks

;__CONFIG(0x3F33); /* disable low voltage prog, disable brown-out, disable pwr up delay */
;/* manually hold MCLR low for seconds after power up and then manually pull high */
0 CLRF 3 ; Select bank 0
1 MOVLW 0
2 MOVWF 0xa ; PClath, clear upper program counter bits
3 GOTO 4
4 CLRF 3 ; Select bank 0
5 GOTO 0x7f7
....
;main()
; {
; TRISC = 0x00;
7f7 BSF 3,5
7f8 BCF 3,6 ; Select bank 1
7f9 CLRF 7 ; TrisC, make PortC outputs
; PORTC=0x55;
7fa MOVLW 0x55
7fb BCF 3,5 ; Select bank 0
7fc MOVWF 7 ; PortC, make pins 01010101
; while(TRUE)
; ;
7fd GOTO 0x7fe
7fe GOTO 0x7fe ; loop forever
7ff GOTO 4
; }
 
Perhaps the ADC is causing problems?

The data sheet says..

Other PORTA pins are multiplexed with analog inputs
and analog VREF input. The operation of each pin is
selected by clearing/setting the control bits in the
ADCON1 register (A/D Control Register1).
Click to expand...
and..

On a Power-on Reset, these pins are configured
as analog inputs and read as '0'.
Click to expand...
The suggested code is...

BCF STATUS, RP0 ;
BCF STATUS, RP1 ; Bank0

CLRF PORTA ; Initialize PORTA by
; clearing output
; data latches

BSF STATUS, RP0 ; Select Bank 1
MOVLW 0x06 ; Configure all pins

MOVWF ADCON1 ; as digital inputs

MOVLW 0xCF ; Value used to
; initialize data
; direction

MOVWF TRISA ; Set RA<3:0> as inputs
; RA<5:4> as outputs
; TRISA<7:6>are always
; read as '0'.
 
Sorry I didn't spot you were using port C not port A.



"CWatters" <colin.watters@pandora.be> wrote in message
news:W0wkb.88794$4x2.4267033@phobos.telenet-ops.be...
Perhaps the ADC is causing problems?

The data sheet says..

Other PORTA pins are multiplexed with analog inputs
and analog VREF input. The operation of each pin is
selected by clearing/setting the control bits in the
ADCON1 register (A/D Control Register1).

and..

On a Power-on Reset, these pins are configured
as analog inputs and read as '0'.

The suggested code is...

BCF STATUS, RP0 ;
BCF STATUS, RP1 ; Bank0

CLRF PORTA ; Initialize PORTA by
; clearing output
; data latches

BSF STATUS, RP0 ; Select Bank 1
MOVLW 0x06 ; Configure all pins

MOVWF ADCON1 ; as digital inputs

MOVLW 0xCF ; Value used to
; initialize data
; direction

MOVWF TRISA ; Set RA<3:0> as inputs
; RA<5:4> as outputs
; TRISA<7:6>are always
; read as '0'.
Click to expand...
 
"CWatters" <colin.watters@pandora.be> writes:
Sorry I didn't spot you were using port C not port A.
Click to expand...
I understand, not like I haven't overlooked something before :)
I picked port C for the simplest test because it wasn't multiplexed
with master/slave or analog or ...

Before I reduced the code down to three lines, I had configured port A
as digital and output copies of the switch inputs there, so I thought
I could see the switch operation directly. And even that was still
leaving all the port bits sitting at zero volts.

Thanks for trying, any other ideas?

"CWatters" <colin.watters@pandora.be> wrote in message
Perhaps the ADC is causing problems?

The data sheet says..
....
Click to expand...
 
"Don Taylor" <dont@agora.rdrop.com> wrote in message
news:3f92bd48_5@127.0.0.1...
Thanks for trying, any other ideas?
Click to expand...
I once had something similar on another PIC but it went away on it's own! I
was writing in assembler and as far as I can tell the only change I made
would have (in effect) added a small delay between power up and configuring
the ports. Can't see how that would explain anything (you would expect other
people to report the same problem).

I worked through the code you posted and it looks OK. I rechecked your
config bit settings against the data sheet and they also look OK. I also
checked that a Brown Out Reset didn't have a seperate reset vector to the
normal one (it doesn't).

Do you get the same results on more than one 16F877 or isn't it possible?

Is the PCB layout good? Good grounding? Decoupling? Otherwise I'm stumped
too.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top