LED BLINKING CODE NOT WORKING

[NASK]

I need to simply blink some LED using 16f887 micro controller. My code is shown below and it work fine in Proteus Design Suite  but not working correctly in real environment. I tried with new micro controllers too still not properly working.  According to code,eight  led one by one need to ON & OFF. but but at a time two led are ON and not working given order.

example : 1st LED & 3rd LED blink  then 2nd LED & 3 LED blink

my code is;

/* MPLABX used & xC8 compiler used */

#include <xc.h>


#define _XTAL_FREQ 16000000
// CONFIG1
#pragma config FOSC = HS       // Oscillator Selection bits (HS oscillator: High-speed crystal/resonator on RA6/OSC2/CLKOUT and RA7/OSC1/CLKIN)
#pragma config WDTE = OFF         // Watchdog Timer Enable bit (WDT disabled and can be enabled by SWDTEN bit of the WDTCON register)
#pragma config PWRTE = OFF      // Power-up Timer Enable bit (PWRT disabled)
#pragma config MCLRE = ON       // RE3/MCLR pin function select bit (RE3/MCLR pin function is MCLR)
#pragma config CP = OFF         // Code Protection bit (Program memory code protection is disabled)
#pragma config CPD = OFF        // Data Code Protection bit (Data memory code protection is disabled)
#pragma config BOREN = ON       // Brown Out Reset Selection bits (BOR disabled)
#pragma config IESO =ON           // Internal External Switchover bit (Internal/External Switchover mode is enabled)
#pragma config FCMEN = ON        // Fail-Safe Clock Monitor Enabled bit (Fail-Safe Clock Monitor is enabled)
#pragma config LVP = OFF        // Low Voltage Programming Enable bit (RB3 pin has digital I/O, HV on MCLR must be used for programming)

// CONFIG2
#pragma config BOR4V = BOR40V   // Brown-out Reset Selection bit (Brown-out Reset set to 4.0V)
#pragma config WRT = OFF        // Flash Program Memory Self Write Enable bits (Write protection off)






void main(void) {
    ANSEL=0;
    ANSELH=0;
    TRISC=0x00;
    TRISD=0x00;
    PORTD=0x00;
    PORTC=0x00;
    while(1){
     
    PORTDbits.RD0=1;
    __delay_ms(100);
    PORTDbits.RD0=0;
   
   
    __delay_ms(100);
    PORTDbits.RD1=1;
    __delay_ms(100);
    PORTDbits.RD1=0;
     __delay_ms(100);
     
   
    PORTDbits.RD2=1;
   __delay_ms(100);
    PORTDbits.RD2=0;
   __delay_ms(100); 
     
     
    PORTDbits.RD3=1;
       __delay_ms(100);
      PORTDbits.RD3=0;
     __delay_ms(100);   
     //+++++++++++++++++++++++++++++++++++++++++++++++++++++   
    PORTCbits.RC4=1;
     __delay_ms(100);
     PORTCbits.RC4=0;
      __delay_ms(100);   
       
    PORTCbits.RC5=1;
      __delay_ms(100);
    PORTCbits.RC5=0;
       __delay_ms(100);   
       
    PORTCbits.RC6=1;
      __delay_ms(100);
    PORTCbits.RC6=0;
       __delay_ms(100);   
       
       
    PORTCbits.RC7=1;
    __delay_ms(100);
     PORTCbits.RC7=0;
     __delay_ms(100);
   
    }
}




 

[Nusa]

Don't assume the problem is in software, especially when it works in simulation.

Show us the hardware if you want input from us! Circuit diagram? Picture?

Are you able to test the LED's without the PIC to ensure that they work and that there are no shorts between them?

[Ian.M]

My first suspicion is a RMW related issue. See: RMW and solutions for it @Microchip's forum.

[StillTrying]

My first suspicion is a RMW related issue.

Mine was! But with the 100ms delays I can't see how that's possible.

Too many unused inputs left floating ?

[Ian.M]

Yes. the 100ms delays *should* mean the other port bits are stable at a valid logic level when the bit being manipulated switches.   However if the PIC is exposed to a high level of EMI, that may not be the case. e.g. if there are long unscreened wires to the LEDs or tracks that correspond to a quarter wavelength in a GSM band and no groundplane.   Without seeing the board layout and schematic (as Nusa requested), we are only guessing.

I wouldn't expect floating pins on unrelated ports to cause that sort of problem - its hard to conceive of a failure mechanism that could cause that sort of crosstalk on a different port other than severe ESD damage. 

One possible issue that novices run into is failure to connect all the Gnd and Vdd pins.  Combined with high currents drawn by the LEDs that could cause this sort of issue due to internal voltage drops across the die disturbing logic thresholds or gliching output latch bits..

I would suggest a simple test to eliminate gross hardware faults like pin to pin shorts.   Tie /MCLR low to disable the PIC, forcing all its pins to be inputs, then jumper each port pin that controls a LED in turn to Vdd, through a 220R resistor for current limiting, and check that for each, only the correct LED lights.