MPLAB X/xc8 first program not running

[Emil]

I'm using MPLAB X and the xc8 compiler for the first time and has run into a a problem. It looks like my program is not running. It does not turn on/blink the LEDs.

I have verified the code after programing the chip. I wrote a program in Jal to blink the LEDs and it runs fine, so there is no problem with the hardware or the programmer.

I'm using a 12F675. I have tried the code below and also the first example from the Gooligum mid-range tutorial. (http://www.gooligum.com.au/tut_midrange_C.html)

I suspect there is some setting in MPLAB that I'm missing but I can't think of what it may be..

Code: [Select]

#include <xc.h>
#pragma config FOSC = INTRCIO
#pragma config WDTE = OFF
#pragma config PWRTE = OFF
#pragma config MCLRE = OFF
#pragma config BOREN = OFF
#pragma config CP = OFF
#pragma config CPD = OFF
#define _XTAL_FREQ 4000000

void main() {
    TRISIO = 0b101011;
    GPIObits.GP2 = 1;

    while (1){
       GPIObits.GP4 = 1;
       __delay_ms(500);
       GPIObits.GP4 = 0;
       __delay_ms(200);
    }
}



The generated .hex file:

Code: [Select]

:0A0000008316FF2390008312F62BF5
:1007EC008301F82BFD308316850083128514FD2BB5
:0207FC000028D3
:02400E00B431CB
:00000001FF


[notsob]

do you have the old mplab 8 installed on the same PC, if so did you use the MPLAB Switcher to change your saettings

[Emil]

do you have the old mplab 8 installed on the same PC, if so did you use the MPLAB Switcher to change your saettings

No, I don't have MPLAB 8 or any other old version installed.

[Emil]

Any suggestions for settings to check? or config files?

I selected PIC12F675 when creating the project. Can't find other settings than that.

[ElektroQuark]

In what pins have you connect the leds?

[Emil]

In what pins have you connect the leds?

Pin 3 and 5 when using the code above.

[ElektroQuark]

Try enabling the PowerUp Timer.

Change:

#pragma config PWRTE = OFF

to

#pragma config PWRTE = ON

[Emil]

Try enabling the PowerUp Timer.

I tried now. No change.

[TheDirty]

What programmer are you using?  Are you not able to single step and check the registers in debug mode?

[os40la]

Does the PIC have a MCLR pin? if so is it tied to VCC with a 10k resistor?. I think if that is left floating the chip may be in a constant reset mode.

[Emil]

What programmer are you using?  Are you not able to single step and check the registers in debug mode?

The programmer I'm using is a Wisp628 (http://www.voti.nl/wisp628/) which I built some years ago. It doesn't have any debugging features.

I'm going to order a PICkit3, so will be able to try this when that arrives.

[Emil]

Does the PIC have a MCLR pin? if so is it tied to VCC with a 10k resistor?. I think if that is left floating the chip may be in a constant reset mode.

It's got an MCLR pin. It's connected to VCC with a resistor. I'v been using 6.8k, but have changed to 10k now. Same result.
MCLR is disabled in my code example, but I have tried enabling it. No change.

[TheDirty]

Well, I was too lazy to look at your code before because I hate the port defines that PIC compilers use.  They are always different (namely gpiobits).

I don't see any issues with the code, though I'm not that familiar with PIC config bits.  Since you are using MPLABX it's real easy to go to Window -> PIC Memory views -> Configuration bits.  From there it gives you all the options for the config bits and you can select the button 'Generate Source Code to Output' which will give you the config setup and you can copy and paste that in your program.

Sorry if I can't be of more help, but it looks good to me.

[NiHaoMike]

After programming the code, try measuring resistance between the I/O pins and ground (disconnect the LEDs) with the power on. Are the I/Os actually set low or just floating?

[Emil]

After programming the code, try measuring resistance between the I/O pins and ground (disconnect the LEDs) with the power on. Are the I/Os actually set low or just floating?

They are floating.

Resistance to ground was too high to measure on my DMM (>20meg).
I measured the voltages and all the IO pins except pin 4 (pulled to vcc) and pin 7 (1.3v) where at around 0.6 volts.

[Niklas]

I dont think its related to MCLR or the configuration bits but it is related to the compiler or the code itself. If you import the hex file into MPLAB and then have a look at the program memory, you will find a few odd things. Below is a disassembly listing of the relevant parts of the memory:

000 BSF STATUS, RP0    ; Select Bank 1
001 CALL 0x3FF            ; Call to last memory cell to get oscillator calibration
002 MOVWF T1CON       ; Save to oscillator
003 BCF STATUS, RP0   ; Bank 0
004 GOTO 0x3F6
005 ADDLW 0xFF (Empty memory)
...
3F6 CLRF STATUS
3F7 GOTO 0x3F8           ; Same as 2xNOP
3F8 MOVLW 0xFD          ; Load WREG with 0XFD = 0b11111101
3F9 BSF STATUS, RP0    ; Bank 1
3FA MOVWF GPIO          ; Load WREG to TRIS
3FB BCF STATUS, RP0    ; Bank 0
3FC BSF GPIO, 1            ; Make GPIO1 go high
3FD GOTO 3FD               ; Loop forever
3FE GOTO 0                   ; Goto address 0
3FF ADDLW 0xFF           ; Should be RETLW 0x**, (calibration value)

If the programmer erases all the memory, including the last word containing the calibration value, before programming, then the program will hang forever. From reset at 0x3FF, roll over to 000 and then perform a call to 3FF. As there is no return or retlw there, the program counter will roll over to 000 again and then make a new call 3FF and so on. Eventually the built in return stack will only be pushed but never popped. On a PIC18, that would have caused a stack overflow reset.

Possible workaround? Add an assembler instruction at address 0x3FF with a RETLW and some value. Here is how I got it to work:
1. Add a function prototype before the void main line
void MyOscCal(void);
2. Inside main, but after the while(1) loop, add a call to function MyOscCal
void main()
{
  while(1)
  {....
  }
  MyOscCal();
}

3. Create a function located at 0x3FF containing just one single RETLW instruction
void MyOscCal(void) @ 0x3FF
{
  asm("retlw 0x80");  // Change 0x80 to something else if the oscillator is way off
}

On the other hand I think the generated assembly code is missing a lot compared to the C code you attached. Here are some examples:
TRISIO = ... is totally off with the wrong value
The while loop is completely absent

The missing while loop is very strange and I managed to get the same result with:
while(1)
{
  i++;
}

The complete while loop was missing and I got a message about that i was never used.