18F46K20 intermittent programming

Thread Starter

camerart

Joined Feb 25, 2013
2,979
Hi,
I have 3x PCBs, with 18F46K20 PICs.
There is something not right when they are programmed, as they seem to work for a while, then don't. 1x of them has never worked.

The error seems to me to be a PCB problem, so I checked, continuity, and separation of tracks etc.

I have been testing the 3x programming connections with a digital analyser, and saved the outputs of the tests, for comparison. When compared the data always seems different.

What tests can I do to find out what's going on?
C
 

ericgibbs

Joined Jan 29, 2010
15,348
What tests can I do to find out what's going on?
hi C,
I would write a short test program, that say flashes 3 LED pins, program the PIC's [ all 3 and then cycle test them] ie: power On, Off retest.

It is just possible your main program is hanging, waiting for a pulse that has critical timing or an edge problem.
So it works, and then it does not...

E
 

Thread Starter

camerart

Joined Feb 25, 2013
2,979
hi C,
I would write a short test program, that say flashes 3 LED pins, program the PIC's [ all 3 and then cycle test them] ie: power On, Off retest.

It is just possible your main program is hanging, waiting for a pulse that has critical timing or an edge problem.
So it works, and then it does not...

E
Hi E,
I've being testing with programs as you say for months, and even made the 3rd PCB in case it was a problem with my PCB making, but I've made lots of them and normally find the problem, but this time no luck.

I have a program all ports on then off, and always have a LED flash at the begining of all of my programs.

For cases like this I use a logic analyser, or oscilloscope, but have run out of ideas.

One test, was to remove the PIC, programmed it on a simple PCB, put it back on the original PCB, which works then try programming normally, and it fails.
C
 

ericgibbs

Joined Jan 29, 2010
15,348
There is something not right when they are programmed, as they seem to work for a while, then don't. 1x of them has never worked.
hi,
Does the one that has never worked, work with a simple test program.?

If so, are all 3 PIC's are giving the same problem in the main program.??

ie: does it hang in the same point in the program.?

Try programming a break point/s in the main program, that halt the program and lights an LED. Find where it is hanging.
Or use the Serial out to show the states of the program during its execution.
E
 

Thread Starter

camerart

Joined Feb 25, 2013
2,979
hi,
Does the one that has never worked, work with a simple test program.?

If so, are all 3 PIC's are giving the same problem in the main program.??

ie: does it hang in the same point in the program.?

Try programming a break point/s in the main program, that halt the program and lights an LED. Find where it is hanging.
Or use the Serial out to show the states of the program during its execution.
E
Hi E,
From what I gather it looks like it just doesn't program. As mentioned, the first place I could add a break point is where I have LED flashes, which don't flash.

When I programmed it on the small PCB, and replaced it onto PCB7-C (the third one) the LED flashes until I try programming it again with the same program.

I have a terminal, which shows nothing. When programming the analyser shows all 3x programming lines switching as may be expected.

The voltage stays constant throughout.
C
 

sagor

Joined Mar 10, 2019
675
Your statement:
" One test, was to remove the PIC, programmed it on a simple PCB, put it back on the original PCB, which works then try programming normally, and it fails. "
implies that the chip works ok when programmed using a simple programming socket/board. Then, programming on your PCB via ICSP it often fails?
That suggests that some of your ICSP programming lines on the PCB may have loads or improper resistance to the programming pins of the chip. When programming via ICSP, one has to make sure loads are either disconnected from those lines, of have a high impedance as to not disrupt the programming signals to the chip themselves. Check the load(s) on your ICSP lines on the PCB
 

Thread Starter

camerart

Joined Feb 25, 2013
2,979
Your statement:
" One test, was to remove the PIC, programmed it on a simple PCB, put it back on the original PCB, which works then try programming normally, and it fails. "
implies that the chip works ok when programmed using a simple programming socket/board. Then, programming on your PCB via ICSP it often fails?
That suggests that some of your ICSP programming lines on the PCB may have loads or improper resistance to the programming pins of the chip. When programming via ICSP, one has to make sure loads are either disconnected from those lines, of have a high impedance as to not disrupt the programming signals to the chip themselves. Check the load(s) on your ICSP lines on the PCB
Hi S,
Interesting!
What procedure should I use please?
C
 

KeithWalker

Joined Jul 10, 2017
2,306
What is connected to the programming and reset lines on your circuit boards? A schematic of the board would make it much easier for us to find the cause of your problem.
 

Thread Starter

camerart

Joined Feb 25, 2013
2,979
What is connected to the programming and reset lines on your circuit boards? A schematic of the board would make it much easier for us to find the cause of your problem.
Hi K,
Here is the schematic and PCB, and nothing but Pickit3 is connected to those lines.
The sch shows an 18F4620, but it has been changed to 19F46K20
C
 

Attachments

Last edited:

nsaspook

Joined Aug 27, 2009
9,466
Hi K,
Here is the schematic, and nothing but Pickit3 is connected to those lines.
The sch shows an 18F4620, but it has been changed to 19F46K20
C
I don't see a RC time delay on the MCLR lines, missing delay cap. Even with a on-chip BOR signal slow VDD ramp times can cause issues on boards without a small delay cap.

https://microchipdeveloper.com/8bit:mclr
https://www.microchip.com/forums/m810715.aspx



I've used a circuit like this for MCLR when there are external reset connections to reduce ESD currents to the VPP/MCLR pin.
 
Last edited:

Thread Starter

camerart

Joined Feb 25, 2013
2,979
I don't see a RC time delay on the MCLR lines, missing delay cap. Even with a on-chip BOR signal slow VDD ramp times can cause issues on boards without a small delay cap.

https://microchipdeveloper.com/8bit:mclr
https://www.microchip.com/forums/m810715.aspx



I've used a circuit like this for MCLR when there are external reset connections to reduce ESD currents to the VPP/MCLR pin.
Hi N,
This seems very feasable, also I followed the links which points to intermittent programming too.

Aussie Susan in one of the replies in a link said
"My (limited) experience is that the capacitor is not required but I typically have the code that initialises the oscillator right at the start of my program (which typically enables the PLL and waits until the whole oscillator section is locked and stable). Therefore I don't need any hardware delay on the \MCLR\ line. "
I also wonder if this is a good idea?

I'll add the components,Thanks, C
 
Last edited:

Thread Starter

camerart

Joined Feb 25, 2013
2,979
Hi,
I've just had a thought!!
If I remove the MCLR pull up resistor, and add a switch, so that I can switch on the PCB and give it time to ramp up, then switch it to run, then program it. Will this work?
C
 

nsaspook

Joined Aug 27, 2009
9,466
Hi,
I've just had a thought!!
If I remove the MCLR pull up resistor, and add a switch, so that I can switch on the PCB and give it time to ramp up, then switch it to run, then program it. Will this work?
C
Don't remove the pull up resistor. There's no need to make this a manual reset operation.
 

Thread Starter

camerart

Joined Feb 25, 2013
2,979
Don't remove the pull up resistor. There's no need to make this a manual reset operation.
Hi N,
Ok., I'll leave it as suggested.

A worry of mine, is I change the components, then time passes and I get an intermittent fault again, which is related to this.
I've been looking into this are, and in one of the D/S it states to set the RCs to suit the application, so I feel this method may not be future proof.
Any comments, or ways I can verify, that the components selected are 'down the middle' of the error?
C
 

Thread Starter

camerart

Joined Feb 25, 2013
2,979
Something seems strange. On Master, Vpp is via R3 to Vdd. On Slave, Vpp is via R4 to ground.
Hi S,
Well spotted, this is an error, but luckily, I have posted a reject SCH, that is in my OLD folder. I have a slightly updated one and I will replace the one you have been checking in #10, along with the PCB.
Apologies for this.
C
 

nsaspook

Joined Aug 27, 2009
9,466
Hi N,
Ok., I'll leave it as suggested.

A worry of mine, is I change the components, then time passes and I get an intermittent fault again, which is related to this.
I've been looking into this are, and in one of the D/S it states to set the RCs to suit the application, so I feel this method may not be future proof.
Any comments, or ways I can verify, that the components selected are 'down the middle' of the error?
C
10K and 0.1uf are the traditional RC values across many product lines and devices for (HV) programming mode. I usually put a small value 50->200 ohm in series to the MCLR pin to reduce possible negative voltage ringing and transient currents from external reset connections. Good power supply rise times and good chip bypassing on PCB circuits are also important to long-term reliability for operation and In-Circuit Serial Programming.
https://microchipdeveloper.com/8bit:lvp
 

Thread Starter

camerart

Joined Feb 25, 2013
2,979
I don't see a RC time delay on the MCLR lines, missing delay cap. Even with a on-chip BOR signal slow VDD ramp times can cause issues on boards without a small delay cap.

https://microchipdeveloper.com/8bit:mclr
https://www.microchip.com/forums/m810715.aspx



I've used a circuit like this for MCLR when there are external reset connections to reduce ESD currents to the VPP/MCLR pin.
Hi N,
Does the Cap have to be polarised?
Where does the track go (Yellow arrow)
C
 

Attachments

Top