How do I tell if a PIC is working?

Thread Starter

camerart

Joined Feb 25, 2013
1,634
Hi,
I've made a PCB with a PIC controller.
I've added two LEDs as indicators, but they don't flash as expected. Voltage applied to the PIN turns LEDs ON.
The PIC programs and verifies ok.
How can I tell if the PIC is working?

Camerart
 

adelgado

Joined Sep 15, 2017
1
Do you have a simulator software? Say, proteus? It's better you run or simulate the program in proteus first so you would know your program is working.

Write a program that will simply flash the LED, say twice, by sending a 1 to the port pin where the LED is connected, then a delay of 500ms, and then send a 0, a delay of 500ms, send a 1, a delay, and a 0. This will flash the LED twice in 2 seconds.

So, try it in proteus. If the simulation works, you are almost there. Burn the program to PIC, and turn in on. If the LED won't flash, then there is a problem with your hardware. Probably a loose crystal, a loose connection to ground and source pins, or the LED is reverse-biased (working connection) or the limiting resistor for the LED is very large. Better to use green LED because its forward voltage is high, thus you may omit its limiting resistor. It won't get busted especially that it is simply flashing, it won't heat up.
 

tribbles

Joined Jun 19, 2015
26
One of the common mistakes I used to keep on making with PICs is that I forgot that some of the digital output pins will default to analogue inputs.

So I would check that you've disabled all analogue functions first of all.

Which PIC is it?

Oh, and what are the I/O pins you're using?

And finally, have you set up a clock?
 
Last edited:

Thread Starter

camerart

Joined Feb 25, 2013
1,634
Do you have a simulator software? Say, proteus? It's better you run or simulate the program in proteus first so you would know your program is working.

Write a program that will simply flash the LED, say twice, by sending a 1 to the port pin where the LED is connected, then a delay of 500ms, and then send a 0, a delay of 500ms, send a 1, a delay, and a 0. This will flash the LED twice in 2 seconds.

So, try it in proteus. If the simulation works, you are almost there. Burn the program to PIC, and turn in on. If the LED won't flash, then there is a problem with your hardware. Probably a loose crystal, a loose connection to ground and source pins, or the LED is reverse-biased (working connection) or the limiting resistor for the LED is very large. Better to use green LED because its forward voltage is high, thus you may omit its limiting resistor. It won't get busted especially that it is simply flashing, it won't heat up.
Hi A,
I'm using Oshonsoft simulator and it runs ok.
I've tried voltage to the LED PINs and they switch ON.
I've checked all the connections.
Internal Oscillator
I tried LEDs ON/OFF also all the PORTS ON/OFF.
Thanks, C.
 

Thread Starter

camerart

Joined Feb 25, 2013
1,634
One of the common mistakes I used to keep on making with PICs is that I forgot that some of the digital output pins will default to analogue inputs.

So I would check that you've disabled all analogue functions first of all.

Which PIC is it?

Oh, and what are the I/O pins you're using?

And finally, have you set up a clock?
Hi T,
It's an 18LF4431
The program is the simplest, with no Analog outputs
I'm beginning to think, I may have got the PIC too hot when soldering?
C.
 

Thread Starter

camerart

Joined Feb 25, 2013
1,634
Hi,
What I was wondering is, if the PIC programs and verifies, does this prove it's working?
Is it possible that the PIC program is working, but the PORTs aren't?
C
 

jpanhalt

Joined Jan 18, 2008
7,694
With MPLab SIM, oscillator settings don't matter. Only with a hardware simulator (e.g., MPLab ICD3 or PicKit 3) will you catch an error in the oscillator module. Are you using actual hardware simulation with Oschonsoft?
 

be80be

Joined Jul 5, 2008
1,906
When you program a pic all that happens is your programmer writes the chips memory it then reads it back to see if it has the
same data. That doesn't mean your code is right and will run as you think.

You more then likely have the fuse wrong or the port settings wrong. The fuse setting are the first place I check.

Oschonsoft has great sim to check port settings to see if there right but it really don't care much about fuse setting it will sim the reg setting fine tho.
 

JohnInTX

Joined Jun 26, 2012
3,771
Hi,
What I was wondering is, if the PIC programs and verifies, does this prove it's working?
Is it possible that the PIC program is working, but the PORTs aren't?
C
To add to @be80be
Be sure MCLR/ is pulled up or disabled in the Configuration Bits then, a quick go/no go would be to add a pullup resistor to one of the PORT C pins then add
LATC = 0
TRISC = 0
to the beginning of your code and use a DVM on that pin. If it goes to 0 volts (or close to it) when you power up, the PIC is running (PORTC is a digital input on power up and the code must execute to output a 0).
If you are using the internal oscillator, specify to output the oscillator on RA6 in the Configuration Bit settings (INTIO1) then inspect that pin. If the oscillator is running, the voltage should be about 1/2 Vdd on a DVM (you can scope it if you have one). If the pin is Vss or Vdd, the oscillator isn't running.
Once the PIC is running its up to the code to make your LEDs flash. Be sure to visit each port description in the databook to know when you have to configure the pin to be digital. See ANSEL0 and ANSEL1 descriptions.
Finally, be sure you always write or toggle to LATx not PORTx to avoid r-m-w issues.

Good luck!
 

Sensacell

Joined Jun 19, 2012
2,430
99% it's a problem with the way the chips config bits are set- if you can successfully program and verify the part.

I have encountered parts with a bad pin while the rest of the part worked, but this is very rare.
 

Thread Starter

camerart

Joined Feb 25, 2013
1,634
With MPLab SIM, oscillator settings don't matter. Only with a hardware simulator (e.g., MPLab ICD3 or PicKit 3) will you catch an error in the oscillator module. Are you using actual hardware simulation with Oschonsoft?
Hi J,
As the PIC PCB isn't connected during the SIM, I presume it's software simulation.
C.
 

Thread Starter

camerart

Joined Feb 25, 2013
1,634
When you program a pic all that happens is your programmer writes the chips memory it then reads it back to see if it has the
same data. That doesn't mean your code is right and will run as you think.

You more then likely have the fuse wrong or the port settings wrong. The fuse setting are the first place I check.

Oschonsoft has great sim to check port settings to see if there right but it really don't care much about fuse setting it will sim the reg setting fine tho.
Hi B,
I'll check the D/S for the fuse settings, although I'm not sure what fuse settings are. I've programmed lots of PICs, so I must have set them without knowing the name.
C.
 

Thread Starter

camerart

Joined Feb 25, 2013
1,634
To add to @be80be
Be sure MCLR/ is pulled up or disabled in the Configuration Bits then, a quick go/no go would be to add a pullup resistor to one of the PORT C pins then add
LATC = 0
TRISC = 0
to the beginning of your code and use a DVM on that pin. If it goes to 0 volts (or close to it) when you power up, the PIC is running (PORTC is a digital input on power up and the code must execute to output a 0).
If you are using the internal oscillator, specify to output the oscillator on RA6 in the Configuration Bit settings (INTIO1) then inspect that pin. If the oscillator is running, the voltage should be about 1/2 Vdd on a DVM (you can scope it if you have one). If the pin is Vss or Vdd, the oscillator isn't running.
Once the PIC is running its up to the code to make your LEDs flash. Be sure to visit each port description in the databook to know when you have to configure the pin to be digital. See ANSEL0 and ANSEL1 descriptions.
Finally, be sure you always write or toggle to LATx not PORTx to avoid r-m-w issues.

Good luck!
Hi J,
MCLR has a pull up resistor.
Set RA6 CLKO and the Oscilloscope shows a saw tooth at 1 Us and a Square wave at 0.1MS.
Here is the program showing LATs ON/OFF, but not on the live PCB still.
What's a DVM?
C.
 

Attachments

tribbles

Joined Jun 19, 2015
26
Your configuration bits:

CONFIG1L has no useful bits (you've described it as 'INTOSC', but this is actually in CONFIG1H
CONFIG1H looks okay
CONFIG2L you've set it to 0b00001110 - bits 2:3 are '11', which is 'Reserved' according to the datasheet (this is for the brown-out voltage level)
CONFIG2H is actually the watchdog configuration, and not the power up timeout

And I'm stopping at this point, because it seems that either I've got the wrong datasheet, or you have - this is what I'm using:

http://ww1.microchip.com/downloads/en/DeviceDoc/39616d.pdf

It's possible that there's an errata, but it seems like there is a massive discrepancy.
 

Ian Rogers

Joined Dec 12, 2012
647
Hi C!!

Are you running this on a real pic for the first time???? If your code has the "simulation_waitms_value" set Your code may be running far too fast... It will be tripping itself up!!

Other than that as Sensacell mentioned... Config bits not matching hardware used...
 

ericgibbs

Joined Jan 29, 2010
8,583
hi C,
As I have suggested previously, with Oshonsoft it is so easy to add an Hseropen, and Hserout [ that output say "Ready"] or an other program sequence check marker tags/information.
E
 

Thread Starter

camerart

Joined Feb 25, 2013
1,634
Your configuration bits:

CONFIG1L has no useful bits (you've described it as 'INTOSC', but this is actually in CONFIG1H
CONFIG1H looks okay
CONFIG2L you've set it to 0b00001110 - bits 2:3 are '11', which is 'Reserved' according to the datasheet (this is for the brown-out voltage level)
CONFIG2H is actually the watchdog configuration, and not the power up timeout

And I'm stopping at this point, because it seems that either I've got the wrong datasheet, or you have - this is what I'm using:

http://ww1.microchip.com/downloads/en/DeviceDoc/39616d.pdf

It's possible that there's an errata, but it seems like there is a massive discrepancy.
Hi T,
From experience, any problems will be at my end;)
I simply copied and pasted the configuration settings from an earlier 18LF2431 program I have working, which isn't really what should be done.
C.
 

Thread Starter

camerart

Joined Feb 25, 2013
1,634
Hi C!!

Are you running this on a real pic for the first time???? If your code has the "simulation_waitms_value" set Your code may be running far too fast... It will be tripping itself up!!

Other than that as Sensacell mentioned... Config bits not matching hardware used...
Hi I,
Yes, a new PCB with ne PIC, for the first time.
I do sometimes, forget the SIM simulator value, but not this time.
I'll have to go through the D/S more carefully.
C.
 

Thread Starter

camerart

Joined Feb 25, 2013
1,634
hi C,
As I have suggested previously, with Oshonsoft it is so easy to add an Hseropen, and Hserout [ that output say "Ready"] or an other program sequence check marker tags/information.
E
Hi E,
Thanks for reminding me, I forget. I'll add it.
C.
 

tribbles

Joined Jun 19, 2015
26
Hi T,
From experience, any problems will be at my end;)
I simply copied and pasted the configuration settings from an earlier 18LF2431 program I have working, which isn't really what should be done.
C.
Hmm - the '2431 should have the same configuration bits as the '4431...

What I would have is something like this as a start:

CONFIG1H => 0b00001001/ 0x09 (IESO, FCMEN disabled, INTOSC enabled, with CLKOUT on RA6, and IO on RA7)
CONFIG2L => 0b00001000 / 0x08 (VBOR = 2.7V, BOREN disabled, PWRTE enabled)
CONFIG2H => 0b00000000 / 0x00 (WDT window disabled, WDT disabled)
CONFIG3L => 0b00000000 / 0x00 (All configuration bits are unlikely to cause problems)
CONFIG3H => 0b00000000 / 0x00 (Set any pin swaps so they aren't using RCx; MCLR is disabled, and an input instead)

These look like what you had before, but are unlikely to cause any problems. I've also described what they really mean.

CONFIG4L => 0b10000000 / 0x80 (Debug, LVP and STVREN are disabled)
CONFIG5L => 0b00001111 / 0x0f (Disable code protection)
CONFIG5H => 0b11000000 / 0xc0 (Disable other code protection)
CONFIG6L => 0b00001111 / 0x0f (Disable write protection)
CONFIG6H => 0b11100000 / 0xe0 (Disable other write protection)
CONFIG7L => 0b00001111 / 0x0f (Disable table reads from other tables)
CONFIG7H => 0b0100000 / 0x40 (Disable table reads to boot block)

Another thing I would be tempted to do is to alternate I/O values, so instead of writing them all with 0x00, waiting, and then writing with 0xff, I would use 0xaa and then 0x55. This means that if it's freezing in the 'wait' stage, you'll know it's got at least that far.

And finally, what voltage are you powering the PIC from?
 
Top