PIC16F: First microntroller project verifies ok then does nothing

[Restartt]

I'm no stranger to electronics, I've been doing analog stuff for a long time.  Recently I wanted to get back into some hobby stuff and everyone said hey, that stuff you're doing will work, but nowadays its much easier to just do it all with a microcontroller instead of like 6 IC's and some Rs and Cs.  Great.  I did some C and some Java like 10+ years ago, I can dust off some coding.

So I whipped up a quick circuit and some code to have a PIC16F916 display a digit to a 7 segment LCD, and decrement the digit by one every time a button is pressed.  do some display, IO, debouncing, etc.  I pick up a pickit5 to program everything, I breadboard it all with jumper wires and solderless breadboards and a power supply.  ready to go

I program the part, it programs and verifies.

Then i go to run the program.  Nothing.

Ok, I say, thats a little complex maybe, lets just copy a quick "put one output pin high" program from the web.  Like a flasher but i didn't have an LED handy so i just wanted to set output hight.

programs and verifies fine.  output is not high.   Im running out of specific webpages so I try to feed chatgpt the datasheet and my issues and it has my try turning off the brownout protection and a few other things that dont help.  ("ai" is truely as meh as i thought, it got several things from the datasheet straight up wrong i had to ask are you sure and it said admitted it was wrong and changed which is NOT a confidence booster, always check the datasheet)

One thing i did notice from its suggestions is I checked the MCLR/VPP and when "#pragma config MCLRE = OFF" then that pin should read high when nothing is attached, but it doesn't.

I've verified 3v reaches VDD, ground reaches VSS.  anything else I try and set or read is basically floating around .1V.

Am i missing something?  is the part just dead (it says it programs and verifies, would it do that if the part was FUBAR)?  What can I try/look out for?

Attached are the diagram and the last version of C code I copied from the internet to test a specific pin.  I can provide whatever else needed

[MikeK]

If you have a 7-segment display then you do have an LED handy.

Don't use MCLR as input unless you've run out of pins.  I always set it to external reset and tie it to high with a 10K resistor.  You can't always trust the datasheet, and there may be something in the errata about it.  Regardless, start with the least number of possible problems...set MCLRE = ON and tie it high with 10K.

Also, use these, just to be sure:

Code: [Select]

ANSELA = 0b0000_0000
ANSELB = 0b0000_0000
ANSELC = 0b0000_0000
ADCON0 = 0b0000_0000
ADCON1 = 0b0000_0000
ADCON2 = 0b0000_0000
CM1CON0 = 0b0000_0100
CM1CON1 = 0b0000_0000
CM2CON0 = 0b0000_0100
CM2CON1 = 0b0000_0000


[Restartt]

I'll go scavenge for some resistors to make the pullup.

I can probably grab a spare led tomorrow.

The 7 segment is LCD not led.

[Pseudobyte]

I have not done PIC programming in quite some time but i do recall the debugger halting on the first instruction. 

The difference being "Debug" vs "Make & Program Device". If debugging you have to tell it to continue execution.

At the risk of sounding patronizing, which button are you pressing?

If you use the make and program button you should be able to disconnect the debugger and power cycle to reset the mcu.

[Restartt]

The difference being "Debug" vs "Make & Program Device". If debugging you have to tell it to continue execution.

I did make and program, and it finished and verified.  I disconnected, power cycled pic, still didn't work.  I also tried it with a second pic

[StillTrying]

Some of the pins around 17 upwards are out by 1 going by this.

[Restartt]

Some of the pins around 17 upwards are out by 1 going by this.

Good catch - i just looked and can confirm the current setup is done to the datasheet, but i did completely redo the setup to take off all the other stuff and have it just be whats needed to program. maybe the first setup was as per the schematic and maybe hurt the chip

[StillTrying]

It might still be OK.

I think the _XTAL_FREQ on corgon's should be 4000000 the default freq unless you change it, but should only effect the _delay.

Try a different output such as RC4 on pin 15, easy to get at.

And then output the dissassembly, for a hard check.

[Restartt]

It might still be OK. I think the _XTAL_FREQ on corgon's should be 4000000 the default freq unless you change it. Try a different output such as RC4 on pin 15, easy to get at. And then output the dissasembly, for a hard check.

I tried it with just a steady on so the freq shouldn't matter i dont think.  ease of access doesnt matter, i'm checking with a jumper wire to a multimeter on a breadboard, its easy to get at.  I've tried two different pins

Im afraid i dont know what you mean by dissassembly, does it break the code down into assembly somewhere?

Have you tried the code I sent you?
It works fine for me. You must be making a mistake somewhere.
I’ll send you the compiled code, try uploading this HEX file to the PIC.

I tried the code you sent on a PIC16F916.  I programmed using a pickit5 and got no errors and a "Programming/Verify complete".  i disconnected the programmer, turned the power off, then on again for the PIC chip, and probed between RBO and VSS, there i got a steady 0.2V

[MarkF]

I believe you still need to set the OSCCON register for internal clock
in addition to setting the configuration bits.

Add:

Code: [Select]

void main(void)
{
    OSCCON = 0b01110001;      // 8 MHz internal clodk
    ANSEL = 0x00;             // All AN pins as digital
    TRISBbits.TRISB0 = 0;     // RB0 output

    while (1) {
       PORTBbits.RB0 = 1;     // LED ON
       __delay_ms(500);       // 500 ms delay
       PORTBbits.RB0 = 0;     // LED OFF
       __delay_ms(500);       // 500 ms delay
   }
}

[StillTrying]

"does it break the code down into assembly somewhere?"

[Window] > debugging > output > disassembly, if you're using MPLAB X.

Breadboards and jumper wires can cause all kinds of problems, for DC I think it might be better to have the multimeter 0V connected off the board, so that you can keep checking the 0V at the board really is <0.1V.

[Restartt]

I figured out the problem with the outputs not going high when set high, or blinkers not blinking, and it was super simple.  maybe a little embarassing.

If you have more than one project, when you go to program a device, it doesn't program on the open or the active one or what you have highlighted.  You have to manually set the new project as "main project" every time.

So i was just reprogramming the same LCD program on to the board again and again, instead of the test outputs.  the file/project name isn't in the output text where it tells you everything went well, so i had no idea it wasnt programming what i wanted.

Now to try and figure out how to make the LCD program work.......

[Restartt]

LCD program now works and i've added buttons for reset and decrement. looks like i'm all set!  Thanks to everyone that helped

[Doctorandus_P]

Always start with a blinking LED project (or similar) before you attempt any more complicated I/O with your uC.

A blinking LED confirms that:

1. You have a working compiler.
2. You have a working programmer / boot loader.
3. You have initialized some output.
4. You have a working uC which actually runs your program (clock configuration problems, power supply and such).

[donlisms]

Good advice, but would not have helped restartt.

[Apollodore]

Hello. Earlier, it was mentioned to review the reset circuit. Add a pull-up. Has this been done?

A single 100nf capacitor on the power supplies seems insufficient to me. The 100nf should be placed as close as possible to the vss and vdd of the pic. Add a 10uf close to the battery. A bad power supply decoupling generates a bunch of bugs that we can't understand in debug mode.
 
I'm happy it's working

[Restartt]

The reset line is set to use it's internal pull-up and not be connected to the external pin.

A 22uf bulk cap is planned when running off battery