Post by thread:[PIC]: 16F877-04 refuses to budge

Summary: 16F877 Pic acts like it isn't even running at power up. Why? I've used the 16F627 successfully for an almost identical projects, a few switches and a few leds running a state machine. I'm using the PICC Lite 8.0 and the Microcom IDE 6.0. I've whittled the code down to (from 200 lines of what I will go back to when it works) #include <pic.h> #define TRUE 1 /* processor control bits, configuring the hardware before startup 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 0 disable brown-out reset of the processor 11 disable flash memory code protection 1 disable 72ms power up delay 0 disable watchdog timer 11 resistor-capacitor oscillator 11111100111011=0x3F33 */ __CONFIG(0x3F33); main() { TRISC = 0x00; PORTC=0x55; while(TRUE) ; } which compiles to (disassembled and commented here) 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 ... 7f7 BSF 3,5 7f8 BCF 3,6 ; Select bank 1 7f9 CLRF 7 ; TrisC, make PortC outputs 7fa MOVLW 0x55 7fb BCF 3,5 ; Select bank 0 7fc MOVWF 7 ; PortC, make pins 01010101 7fd GOTO 0x7fe 7fe GOTO 0x7fe ; loop forever 7ff GOTO 4 I'm using 5-10k ohms and 25-100 picofarads for the RC oscillator. Scope shows a better RC charging waveform and a better /4 oscillator output from the part than I would expect, frequency varies exactly as I would expect when I change R or C values. I've got decoupling caps, I've got stable power supply with correct polarity connected to all VCC and gnd pins. I've got all outputs connected to ground via 1k ohm. I've got an RC circuit for MCLR and have tried manually holding it low for several seconds before letting it pull high. I've manually stepped the code through the simulator and watched all the instructions do exactly what I would expect, showing that port C is loaded. I've got the IC-Prog 1.05 software and the PG2B programmin hardware. It happily recognizes the part, programs it, confirms the program and will do this again and again. And when I drop the part into the protoboard... all the pins except OSC in, OSC out and MCLR remain happily at zero volts. Loading ports A, B, D, exactly the same non-effect. Lifting the pull-downs, same non-effect. I've searched the mfgr's web pages, I've searched the piclist web pages, I think I've followed every recommendation. I've asked a few folks outside the list, they have come up with a few ideas, disable delays, manually hold MCLR, check code in part, terminate all pins, don't terminate all pins, reprogram the part... I've tried each one. Exactly the same non-effect. All the port pins sit at zero volts, but not pulled down hard enough to sink current and, say, light a led. Can anyone offer an idea what might be wrong? Or what to try? Thanks spam_OUTdontTakeThisOuTagora.rdrop.com (valid, if that matters and message isn't important enough to broadcast to everyone) -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Don Taylor <.....PICLISTKILLspam@spam@mitvma.mit.edu> wrote: > Summary: 16F877 Pic acts like it isn't even running at power up. > Why? No idea, Don... But, damn, you sure know how to ask for help. Your message should be posted somewhere on the piclist.com website as the ideal toward which all requests for help should strive. Even Olin at his MOST cantankerous wouldn't be able to find fault with your post. {Quote hidden}> /* processor control bits, configuring the hardware before startup > 11 disable flash memory code protection > 1 disable in-circuit-debug > 1 unimplemented > 1 disable flash memory write protect > 1 disable eeprom protect > 0 disable in-circuit low voltage programming > 0 disable brown-out reset of the processor > 11 disable flash memory code protection > 1 disable 72ms power up delay > 0 disable watchdog timer > 11 resistor-capacitor oscillator > 11111100111011=0x3F33 */ > __CONFIG(0x3F33); Your comments match the ones and zeroes, but the bits don't add up to 0x3F33; if you really want the power-up delay disabled, you'll need to use 0x3FB3. I'd be astonished if this made any difference whatsoever, though. > I've got the IC-Prog 1.05 software and the PG2B programmin > hardware. It happily recognizes the part, programs it, confirms the > program and will do this again and again. My only suggestion -- it's not a particularly good one, but you've sorta eliminated all the others -- is to double- and triple-check that you're ACTUALLY programming the part with the code you want. Is there a chance that you're burning the PIC with the wrong program? > All the port pins sit at zero volts, but not pulled down hard enough > to sink current and, say, light a led. The PIC is really acting as though it isn't programmed... If you have another programmer (preferably different from your programming hardware/software -- maybe a Microchip programmer borrowed from your local distributor?), you could use it to read out the contents of the PIC and see if it really contains what you think it should. -Andy === Andrew Warren -- aiwKILLspamcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

I second Andy's feedback. This is a thorough, well thought-out post for serious suggestions. Sadly, I have only one. I think that the place to start is to verify that the programmer H/W and S/W are functional by loading a known-good hex file to flash an LED. If it works then you can pretty much eliminate those variables relating to the hardware and focus on the development tools. My code is on my laptop and I can't access it now or I'd send you a 'LED blink' hex file. But you'll have no trouble getting one off the net or from PIClist members. Good luck. Andrew ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ---- On , Andrew Warren (.....aiwKILLspam.....CYPRESS.COM) wrote: > Don Taylor <EraseMEPICLISTspam_OUTTakeThisOuTmitvma.mit.edu> wrote: > > > Summary: 16F877 Pic acts like it isn't even running at power up. > > Why? > > No idea, Don... But, damn, you sure know how to ask for help. > > Your message should be posted somewhere on the piclist.com > website as the ideal toward which all requests for help should > strive. Even Olin at his MOST cantankerous wouldn't be able to > find fault with your post. > > > /* processor control bits, configuring the hardware before startup {Quote hidden}> > 11 disable flash memory code protection > > 1 disable in-circuit-debug > > 1 unimplemented > > 1 disable flash memory write protect > > 1 disable eeprom protect > > 0 disable in-circuit low voltage programming > > 0 disable brown-out reset of the processor > > 11 disable flash memory code protection > > 1 disable 72ms power up delay > > 0 disable watchdog timer > > 11 resistor-capacitor oscillator > > 11111100111011=0x3F33 */ > > __CONFIG(0x3F33); > > Your comments match the ones and zeroes, but the bits don't add > up to 0x3F33; if you really want the power-up delay disabled, > you'll need to use 0x3FB3. I'd be astonished if this made any > difference whatsoever, though. > > > I've got the IC-Prog 1.05 software and the PG2B programmin > > hardware. It happily recognizes the part, programs it, confirms the > > program and will do this again and again. > > My only suggestion -- it's not a particularly good one, but > you've sorta eliminated all the others -- is to double- and > triple-check that you're ACTUALLY programming the part with the > code you want. Is there a chance that you're burning the PIC > with the wrong program? > > > All the port pins sit at zero volts, but not pulled down hard enough > > to sink current and, say, light a led. > > The PIC is really acting as though it isn't programmed... If you > have another programmer (preferably different from your > programming hardware/software -- maybe a Microchip programmer > borrowed from your local distributor?), you could use it to read > out the contents of the PIC and see if it really contains what {Quote hidden}> you think it should. > > -Andy > > === Andrew Warren -- aiwspam_OUTcypress.com > === Principal Design Engineer > === Cypress Semiconductor Corporation > === > === Opinions expressed above do not > === necessarily represent those of > === Cypress Semiconductor Corporation > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics > > -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

The one thing you didn't mention is trying a crystal oscillator. Have you tried that? Have you also tried writing a simple program in assembly and loading that up? And making sure that all the interrupts are disabled? I'm assuming that you have included all of the code and assembled output. It looks reasonable to me, if that's the case. Mike H. {Quote hidden}>Summary: 16F877 Pic acts like it isn't even running at power up. Why? > >I've used the 16F627 successfully for an almost identical projects, a >few switches and a few leds running a state machine. > >I'm using the PICC Lite 8.0 and the Microcom IDE 6.0. I've whittled the >code down to (from 200 lines of what I will go back to when it works) > >#include <pic.h> >#define TRUE 1 >/* processor control bits, configuring the hardware before startup >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 > 0 disable brown-out reset of the processor > 11 disable flash memory code protection > 1 disable 72ms power up delay > 0 disable watchdog timer > 11 resistor-capacitor oscillator >11111100111011=0x3F33 */ >__CONFIG(0x3F33); > >main() > { TRISC = 0x00; > PORTC=0x55; > while(TRUE) > ; > } > >which compiles to (disassembled and commented here) > >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 >... >7f7 BSF 3,5 >7f8 BCF 3,6 ; Select bank 1 >7f9 CLRF 7 ; TrisC, make PortC outputs >7fa MOVLW 0x55 >7fb BCF 3,5 ; Select bank 0 >7fc MOVWF 7 ; PortC, make pins 01010101 >7fd GOTO 0x7fe >7fe GOTO 0x7fe ; loop forever >7ff GOTO 4 > >I'm using 5-10k ohms and 25-100 picofarads for the RC oscillator. >Scope shows a better RC charging waveform and a better /4 oscillator >output from the part than I would expect, frequency varies exactly >as I would expect when I change R or C values. > >I've got decoupling caps, I've got stable power supply with correct >polarity connected to all VCC and gnd pins. I've got all outputs >connected to ground via 1k ohm. I've got an RC circuit for MCLR >and have tried manually holding it low for several seconds before >letting it pull high. > >I've manually stepped the code through the simulator and watched >all the instructions do exactly what I would expect, showing that >port C is loaded. > >I've got the IC-Prog 1.05 software and the PG2B programmin hardware. >It happily recognizes the part, programs it, confirms the program >and will do this again and again. > >And when I drop the part into the protoboard... all the pins except >OSC in, OSC out and MCLR remain happily at zero volts. Loading >ports A, B, D, exactly the same non-effect. Lifting the pull-downs, >same non-effect. > >I've searched the mfgr's web pages, I've searched the piclist web >pages, I think I've followed every recommendation. > >I've asked a few folks outside the list, they have come up with a >few ideas, disable delays, manually hold MCLR, check code in part, >terminate all pins, don't terminate all pins, reprogram the part... >I've tried each one. Exactly the same non-effect. > >All the port pins sit at zero volts, but not pulled down hard enough >to sink current and, say, light a led. > >Can anyone offer an idea what might be wrong? Or what to try? > >Thanks >@spam@dontKILLspamagora.rdrop.com (valid, if that matters and message isn't >important enough to broadcast to everyone) > >-- >http://www.piclist.com hint: The list server can filter out subtopics >(like ads or off topics) for you. See http://www.piclist.com/#topics _________________________________________________________________ Compare Cable, DSL or Satellite plans: As low as $29.95. https://broadband.msn.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

----- Original Message ----- From: Andrew Warren <KILLspamaiwKILLspamCYPRESS.COM> To: <RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU> Sent: Tuesday, October 21, 2003 2:12 AM Subject: Re: [PIC]: 16F877-04 refuses to budge {Quote hidden}> Don Taylor <spamBeGonePICLISTspamBeGonemitvma.mit.edu> wrote: > > > Summary: 16F877 Pic acts like it isn't even running at power up. > > Why? > > No idea, Don... But, damn, you sure know how to ask for help. > > Your message should be posted somewhere on the piclist.com > website as the ideal toward which all requests for help should > strive. Even Olin at his MOST cantankerous wouldn't be able to > find fault with your post. > > > /* processor control bits, configuring the hardware before startup > > 11 disable flash memory code protection > > 1 disable in-circuit-debug > > 1 unimplemented > > 1 disable flash memory write protect > > 1 disable eeprom protect > > 0 disable in-circuit low voltage programming > > 0 disable brown-out reset of the processor > > 11 disable flash memory code protection > > 1 disable 72ms power up delay > > 0 disable watchdog timer > > 11 resistor-capacitor oscillator > > 11111100111011=0x3F33 */ > > __CONFIG(0x3F33); > > Your comments match the ones and zeroes, but the bits don't add > up to 0x3F33; if you really want the power-up delay disabled, > you'll need to use 0x3FB3. I'd be astonished if this made any > difference whatsoever, though. Ok, I'm not going to offer any solutions, however it strikes me that 11111100111011=0x3F33 */ __CONFIG(0x3F33); is incorrect, do you meen: 11 1111 0011 1011 -> 0x3F3B or am I missing something? Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Don Taylor wrote: > Summary: 16F877 Pic acts like it isn't even running at power up. Why? > > I'm using the PICC Lite 8.0 and the Microcom IDE 6.0. I would start with MPLAB and assembler until you get something working. At least is eliminates the tools. {Quote hidden}> 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 > ... > 7f7 BSF 3,5 > 7f8 BCF 3,6 ; Select bank 1 > 7f9 CLRF 7 ; TrisC, make PortC outputs > 7fa MOVLW 0x55 > 7fb BCF 3,5 ; Select bank 0 > 7fc MOVWF 7 ; PortC, make pins 01010101 > 7fd GOTO 0x7fe > 7fe GOTO 0x7fe ; loop forever > 7ff GOTO 4 Looks OK, other than I didn't check your hard coded constants and SFR addresses. Again, start with MPLAB assembler until you know your basic setup works. Trying to guess what some third party flakeware tools might be doing is a waste of time. > I've got an RC circuit for MCLR > and have tried manually holding it low for several seconds before > letting it pull high. Watch the maximum MCLR rise time spec. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

What about the config bits.....are you sure that you have the oscillator set to the correct type? I'd have to go back and read your post again, but the FIRST thing I check if it appears to be non-working is check the power and ground (I think you did that) and then if its an RC or XTAL oscillator (such that the osc/4 pin is not tied to anything) look for the clock coming out that pin. All you need to do is code a little delay loop and flash the LED. I do that almost every time I do a project so that I can immidiatly see if the code is loaded and running. Not only do I do this on micro's but also for FPGA's. _________________________________________________________________ Enjoy MSN 8 patented spam control and more with MSN 8 Dial-up Internet Service. Try it FREE for one month! http://join.msn.com/?page=dept/dialup -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.