XINST causing programming failure

[David]

I think I have been having very similar problems described in this post: http://sourceforge.net/p/sdcc/discussion/1865/thread/631cd58b/

However, when I attempt to use "#pragma config XINST=OFF" I am no longer able to program the device using pk2cmd, and just get a Program Memory Errors message with varying addresses and values (though 0x003FF8 or 0x003FFe is common for the "Address" field) and often a "VDD Error detected".

Quick description of the original problem that led me to the XINST stuff is that my LEDs always light up in the 10101011 pattern in the "else" block that should never be reached. Updated SDCC and tried again, then it started warning me about xinst.

This is the entirety of my program:

        #include "pic16/pic18f24j10.h"

    //__code unsigned char __at (0x300000) cfg0 = 0b11100001;
    #define WAIT_CYCLES(A)  for(__delay_cycle = 0;__delay_cycle < A;__delay_cycle++)
    int __delay_cycle;

    #pragma config XINST=OFF
    #define HI 1
    #define LO 0

    void why(int z)
    {
        if(z == HI)
        {
            PORTC = 0b11111111;
        }
        else if(z == LO)
        {
            PORTC = 0b11110000;
        }
        else
        {
            PORTC = 0b10101011;
        }

    }

    void main(void)
    {
        TRISC = 0b00000000;
        PORTC=0b00000000;

        while(1)
        {
        why(LO);
        WAIT_CYCLES(5000);
        why(HI);
        WAIT_CYCLES(5000);
        }
    }

I also tried setting the XINST bit off through the commented out config line at the top, but I don't really know what I'm doing when it comes to setting config stuff that isn't defined in the header file. The result was the same when I did it that way, though - failed to program.

[Diego Herranz]

Several things:

1) Can you post the compilation command you´re running and the sdcc and gputils versions?

2) Are you using --use-non-free, right?

3) It's recommended that you use #include <pic18fregs.h> instead of #include "pic16/pic18f24j10.h" and sdcc includes the apropriate header for your device automatically. This way, your code is more portable.

4) Your delay routine could be optimized away by the compiler and at the end of the day have no delay at all and have the pins toggling all the time. You have access to delay routines with #include <delay.h>

I have several examples/tutorials of sdcc for PICs where you can see 2), 3) and 4) used. https://github.com/diegoherranz/sdcc-examples

The XINST problem you mention is quite strange. Can you try this and provide feedback?

Regards,
Diego