I made a little 18F1320 code for a friend, because I don't have the real hardware.
I simulated and everything works well. However, he burned the chip and its behavior is completely erroneus.

The question is: Is there somebody here who can make the same test on real hardware?
Thanks in advance!

PS. The code is made for MPLABX with XC8. It has 4 outputs and 1 input (all digital). The erroneus behavior has to do with the detection of the interrupt.

 

Hi, try posting a schematic diagram or a high resolution picture of the circuit, along with the code.

 

Here it goes:
This code is one of many different versions that I have tested with the same result: The software simulation works flawlessly but the real hardware doesn't. The real hardware is tested by a friend who doesn't know code programming, so I don't have access to real debugging -That is why I asked for somebody who can test it and debug it on real hardware.
PS. There are code here that is not used on this trimmed version, like the variable ab.

The proper behavior of this thing is:
1) TURN OFF RA0,RA1,RA2,RA3. WAIT 3s
2) TURN ON RA0,RA1,RA2,RA3. WAIT 1s
3) TURN OFF RA0,RA1,RA2,RA3. WAIT 3s
4) Enable interrupts. It makes the swtich closing turn on RA0, RA1, RA7

The erratic behavior, present on the real hardware is:
At power on, TURN ON RA0, RA1 and the switch makes nothing at all.

From the various versions that we have tested, it seems to be the interrupt code that works in a totally strange manner: like interrupting without any change on the switch, even with no switch -leaving RB7 fixed connected to GND.

#include <stdio.h>
#include <stdlib.h>
#include "abcd.h"


#define     ON      1
#define     OFF     0



int ab;



void interrupt input_rised(void)
{
    int count = 0, state = OFF;

    if (INTCONbits.RBIF && INTCONbits.RBIE)
    {
        state = PORTBbits.RB7;
        count = 0;

        do {
            if (PORTBbits.RB7 != state) {
                goto _exitint;
            } else {
                count++;
                __delay_ms(1);
            }
        } while(count < 5);


        state = PORTBbits.RB7;
        LATA7 = state;

        if (ab) {
            LATA0 = state;        // A
            LATA1 = state;        // B
        } else {
            LATA2 = state;        // C
            LATA3 = state;        // D
        }

        _exitint:
            INTCONbits.RBIF = 0;
    }
}





void delay1s(int n)
{
    for (int j = 1; j <= n; j++)
        for (int i = 0; i < 20; i++)
            __delay_ms(50);
}





void main(void)
{
    OSCCON = 0x76;              // 8 MHz
    ADCON1 = 0x7F;
    ab = 1;

    TRISAbits.RA0 = 0;
    TRISAbits.RA1 = 0;
    TRISAbits.RA2 = 0;
    TRISAbits.RA3 = 0;
    TRISAbits.RA4 = 0;
    TRISAbits.RA6 = 0;
    TRISAbits.RA7 = 0;

    TRISBbits.RB0 = 0;
    TRISBbits.RB1 = 0;
    TRISBbits.RB2 = 0;
    TRISBbits.RB3 = 0;
    TRISBbits.RB4 = 0;
    TRISBbits.RB5 = 0;
    TRISBbits.RB6 = 0;
    TRISBbits.RB7 = 1;

    LATA0 = OFF;
    LATA1 = OFF;
    LATA2 = OFF;
    LATA3 = OFF;

    delay1s(3);

    LATA0 = ON;
    LATA1 = ON;
    LATA2 = ON;
    LATA3 = ON;
    delay1s(1);
    LATA0 = OFF;
    LATA1 = OFF;
    LATA2 = OFF;
    LATA3 = OFF;

    delay1s(3);


    INTCONbits.RBIF = 0;
    INTCONbits.RBIE = 1;
    ei();

    // main
    while(1);
}

 

A couple of quick observations:

Before turning on interrupt-on-change be sure to read PORTB to clear any pending mismatch conditions. Be sure to read PORTB in the interrupt routine to clear the mismatch condition. Keep in mind that switch bounce will create several interrupts as will switch release.

Your code does not have any CONFIG bits set - that is necessary for actually running the code on a chip:
In MPLABX, open Window->PIC Memory Views->Configuration Bits.
In the Configuration Bits Window, visit and set up ALL config bits for your particular setup, especially the oscillator, watchdog and MCLR pin select. If you don't know about an option - find out.
Click Generate Source Code to Output. A window will open with the source code you need to implement your selections.
Copy and paste into your source code.
Rebuild.

If you are using the internal oscillator block, don't forget to set OSCCON in your init code to what you want it to run at.

Lots of sims will 'run' without oscillators etc. Chips will not.

You should consider getting a PICkit 3 for debugging on real hardware.

I may have commented on your earlier posts using interrupt on change for switch detection. I do not like it. You are seeing why that is.

Good luck.

 

Thanks for your answers!
However, I think I have made all that you suggest.
- The config bits are on the file .h that I didn't show.
- About the mismatch condition, I read there are two ways of avoiding it, one is reading PORTB like you say, the other is what I did.
- There is antidebouncing code.
- OSCCON is set.

Do you think interrupt on change is not a good way to detect switching? I need to detect both condtions (CLOSED, OPEN) at the proper moment.
I tried also, on another version, to detect CLOSE in one pin and detect OPEN on another one, but it happened the same: it worked well on simulation but failed on real hardware.

I know is completely annoying to read posted code, but I made it because one user suggest it.
Now, I have written a new (simplest) code, I sent it to my friend and I waiting for test results.

 

I know is completely annoying to read posted code

Not true. Now we have a bit more of your project. How about that abcd.h file?

 

Not true

I said it because is that way to me. I have had people who show me pages of very bad written code and look for my advice in a narrow time...

Whatever, as I said before, I'm waiting for the test results of a shorter code that I sent to my friend and then I will tell you more...
Thanks!

 

Where are your VDD and VPP connections?

MCLR is floating. You need to be certain to disable it in your config bits.

Post your config bits.

Does the 18F1320 have an IOCx register? If so I do not see it being set.

But as John mentioned IOC is not a good choice for manual switch change. You will need software or hardware debouncing. It would be a better option o just poll the switch.