Hopefully you all can help a noob.

I'm trying the simple blinking led project and it works fine in two separate simulators, but when I burn it on the pic, it won't do anything that requires timing.

I can set GP<2:0> high and they go high. If I put a delay between them, it only sets the first and then nothing. The same applies to a for/while/if statement. It stops at the first line. I also tried to use a TM0IF to blink the led. NO GO. All these attempts worked in the simulators.

I've been searching and playing with many settings for 8 hours.

Thanks in advance or any input you might have.

FYI I'm using Mlab and xc8 with a 12f683 pic.

 

Post some code and we can take a look.

Check your configuration bits and verify the correct settings.

If your PIC is executing a line of code, the oscillator is probably working since a C instruction is really multiple PIC opcodes.

 

Post your full code. Most often these errors are caused by not setting the correct config bit and/or not turning off analog pins. See section 4 and 12 in the datasheet
http://ww1.microchip.com/downloads/en/devicedoc/41211d_.pdf

 

do you really use MPLAB? Or MPLABX?

It is hard to say without to see the config bits.
With MPLABX, you can generate the correct C code + the blank configbits.c

I don't know, I don't think this chip has a PLL but it could be a silicon issue. So please write the revision (the device programmer gives this info when probing the PIC).

Post the complete code. Check the datasheet for this PIC (google model no.), if you have not already for special features, oscillator, and IO.

 

Thought you may want to see some code, but I've tried and dumped so many different things I didn't know what to start with. This is what I have working in the simulator right now. In the sim, the GP0 alternates every 1.5 seconds, roughly. When I burn/power the chip, the LED lights and stays lit. It appears to be full brightness. When I change the _XTAL_FREQ to 31000, it makes no difference in the Sim but on the PIC GP0 never lights.

I am using MPLABX.

#pragma config FOSC = INTOSCIO  // Oscillator Selection bits (INTOSCIO oscillator: I/O function on RA4/OSC2/CLKOUT pin, I/O function on RA5/OSC1/CLKIN)

#define _XTAL_FREQ 4000000

#include <xc.h>

void main(void) {
    TRISIO0 = 0;
    
    OSCCON = 0b00000111;
    long count = 0;

    
    while(1){
        if(count >= 100000){
            GP0 =~ GP0;
            count = 0;
        }
        
        else {

            count ++;
        }
        
        
    }
       
    

    return;
}

 

Forget what I said about changing the _XTAL_FREQ changing the output of the chip. I mistakenly burned the wrong attemp.

 

Okay, first things first.

#define _XTAL_FREQ 4000000

doesn't change the oscillator frequency - it is a preprocessor directive that tells any code looking for "_XTAL_FREQ" that its value is 4000000 - in other words, it tells your code what the oscillator should be, but doesn't tell the PIC what to configure it as. This is a common misconception for new learners...

What does change the internal oscillator frequency is the value in your OSCCON register. Look that up on page 20 of the datasheet and you'll soon learn that you've set it to 31kHz!
No wonder you haven't seen it change, you'd have to wait a loooonnnggg time to see it!

Set your OSCCON to 0x61, and you will set it for 4MHz operation...

 

I had figured that out about the _XTAL_FREQ while doing all this experimentation. It was only still in the code because I keep going back to the __delay_ms function built into xc8 and it requires it. This code does not.

I have tried almost every osc freq with every type of blink LED code. I have it slowed down so that I can tell that a lit LED is not just a sort of PWM make it seem lit but actually flashing. I'm also going by the sim results to guess the proper prescaler value.

Also, I set GP1 and GP2 after the if/else statement in the code above and they light when burned on the chip and powered. Doesn't this mean that there is an OSC working somehow? If the PIC is completing one instruction cycle every four clock cycles, can the code even progress to GP1 AND GP2 without a clock?

 

From the reply I guess OP is NOT using MPLABX.

Use the Memory view for config bits + modify + copy into configbits.c

use the templates for all new projects.

RESULT: Saving time and $$$.

 

Oh man, I can't believe I forgot to mention MCLR... Do you have a resistor from pin 4 to Vdd? You don't have MCLR disabled in your configuration, so it is operating as the master reset...

 

From the reply I guess OP is NOT using MPLABX.[...]

...this doesn't seem pertinent to solving the problem...

 

...this doesn't seem pertinent to solving the problem...

Why not? by using the project templats + config bits memory view + generate code, all config bits will be correctly set.

MCLR actually not neccessarily will reset if left open- this will happen at some random point and after that it may persist.

Something I experienced years ago one or two times.

2. Did OP respond- yes I use X and have viewed the config memory and copied into configbits.c?

This is the new way of starting a project. It can get a noob quickly to the point blinking the notorious LED incl. Interrupt.

OK according to Microchip comment, don't test the flags in a specific way...

 

Why not? by using the project templats + config bits memory view + generate code, all config bits will be correctly set.

Are suggesting a floating reset is not a problem?

MCLR actually not neccessarily will reset if left open- this will happen at some random point and after that it may persist.

Something I experienced years ago one or two times.

2. Did OP respond- yes I use X and have viewed the config memory and copied into configbits.c?

This is the new way of starting a project. It can get a noob quickly to the point blinking the notorious LED incl. Interrupt.

OK according to Microchip comment, don't test the flags in a specific way...

...okay, but does that differ from MPLAB? Are you unable to view the configuration bits in MPLAB?

Either way, the tool in MPLABX just generates the text for you to copy into your project and doesn't offer any advantage, aside from convenience, in functionality of the target device.

Are you suggesting a floating reset is not neccessarily a problem?

 

...okay, but does that differ from MPLAB? Are you unable to view the configuration bits in MPLAB?

Either way, the tool in MPLABX just generates the text for you to copy into your project.

OK maybe, no pun intended. But the templates are new.

I don't remember if in the MPLAB I used 2004 there was an option to modify the config bits together with textual explanation.

Maybe I missed to realize back then- always painfully calculated the value from the datasheet and placed into absollute allocated location.

I am only guessing about the troubles- maybe one my suggestions is of use. Sometimes it is. I hope the troublle can be found soon.

If it is just me and a circuit with SMD chips and TFT and stuff does NOT work- almost no idea to test is abhorrent to me in terms of not allowing myself it could be the reason for the trouble.

I normally get a long with PICs these days in the order being able t read the FLASH on the first attempt, and blink the LED on the following FLASH. But I must admit, not always.

Most weird thing I had was one PIC10F200 etched PCB- sometimes the LEDs would go off after random time, and the IC would turn slightly hot. Then some time later it would function again. I just ditched it some day.

 

I've tried it with MCLR enabled and disabled. I've also tried tying it to VDD via resistor.

I just now tried to set up a crystal osc. Couldn't get that to work either. Of course, since I'm a noob and can't get the internal to work, it doesn't surprise me. It was my first attempt at a crystal circuit.

 

I've tried it with MCLR enabled and disabled. I've also tried tying it to VDD via resistor.

I just now tried to set up a crystal osc. Couldn't get that to work either. Of course, since I'm a noob and can't get the internal to work, it doesn't surprise me. It was my first attempt at a crystal circuit.

Hmm.... I know I've run into problems when using something like

 GP0 = ~GP0:

Try splitting the delay and set the value explicitly. E.g.

if(count >= 100000){
            count = 0;
        }
If ( count < 50000)
 GP0 = 1;
        
        else
GP0 = 0;
            count ++;

 

Just for the purpose of clarity, I am using MPLAB X and I have used the config bits and tried several different combinations. I.E. WDT on/off, MCLR enable/disabled, both INOSC options, etc. The only options that I haven't tried are the code and data code protection bits.

I have also tried several different methods on a completely different chip, so I know that it must be something I'm doing/not doing.

Thank you all for the responses.

 

Are you suggesting a floating reset is not neccessarily a problem?

Sooner or later it will cause undetermined behaviour. But not always immediately.

Only older PICs can't turn off RESET. I am not using them so much now, besides chips I still have around in my inventory.

I wil browse the PDF manual and see if there is something noteworthy. I used this chip once some years ago with assembler. source maybe still around (embarassing, guess).

 

In the project configuration, under compiler options, have you unchecked CALIBRATE OSCILLATOR?

AFAIK that does not seem to work right for most chips.

ANSEL = 0?

And please show the config bits here.

Do you have a 1uF cap somewhere? Just any small cap will do.
Do you supply power with the PIC programmer?

For the start, just FLASH with one LED set to ON,
next time FLASH with that LED set off.

 

ANSEL = 0?

I thought I had remembered that this was the reset value. Double checking makes me realize it isn't.

OP: make sure you configure the pins as digital output pins through setting the ANSEL as takao suggested.

Edit: Perhaps you should take a picture of your circuit so we can verify...