CCS SMT example builds but does verify

[Ttelmah]

Let's 'extend' this a little.

Historically Tantalum capacitors were quite dangerous. Quite a lot of things
could make them fail. In their early days they were not allowed in medical,
aeronautical, or military equipment. Now however there are high quality MIL
spec versions available. These have a more rugged structure and sometimes
extra protection internally. This is an example of such a product:
[url]
https://www.kyocera-avx.com/resources/high-reliability-solid-tantalum-capacitors/#:~:text=Solid%20tantalum%20capacitors%20offer%20infinitely,and%20non%2Dcritical%20medical%20applications.
[/url]

So you can use Tantalum, but should specify these higher reliability types.

Now the advantages of Tantalum were it's far superior HF performance than
conventional electrolytic, the smaller size for a given capacity, improved
long term temperature performance. but relatively poor ESR. These
improved versions change the chemistry to help improve the ESR as well.

Since then two other products have come along. The first was the Sanyo
'OSCON' electrolytic, with similar HF performance. Similar products are
now available from many manufacturers, Before these it used to be standard
practice to combine an electrolytic with a small ceramic to improve the
HF performance. With these, this is not needed. These also give good ESR's.

The other is the appearance of the non electrolytic multi layer ceramic
capacitors. Giving very good HF performance and low ESR's. If you look at
the Microchip notes about for example the smoothing capacitor that should
be used for the internal supplies on some of their chips, they suggest
MLCC, MnO2 Tantalum, or an enhanced electrolytic like the OSCON.

Have fun.

[sandyw]

Hello JerryR, Ttelmah et al,

Tried a 10uF cap ceramic on the Vpp line directly on the programmer connector pins. Already had a 22uf cap fitted.

No change, program fails to verify, with any interrupt directives included, at memory locations 020 - > 069.

Tried a previous board with a 16f1829 fitted and I'm getting exactly the same effect except it only goes to address 060 this time.

Using same set up and programming Pic 16f8722 works fine.

I had a funny earlier when the ICD40 and ICD80 would not read the 16f18146 device ID and had to update the ICD firmware.

Turns out this was the problem.

The programmer was updated to 03.64 and started to read the ID but this was the point where the verify faults started.
Origional thought it was me and my board but tried various other boards and IC types. Failed on the 16f1829 and 16f18146 passed on the 18f8722.

Tried JerryR solution of 10u onto the Vdd pins at the programmer even though I had lots of capacitance already there, but never discard a good idea, and still didn't work.

Tried a different tack after Ttelmahs suggestion (think it was his) and went back two issues of the programmer firmware to 03.47 and it was back to not reading the Id.

Went back to issue 03.57 and eureka it all started working again so it looks as if the fundamental problem is the firmware in the icd programmer.

Hope this helps some one else and thanks for all the help.

SandyW

[Ttelmah]

I would report this. I had similar problems a few months ago on some
PIC24 variants. Problem is little changes to the firmware, and the impossibility
of testing with all the huge numbers of PIC variants...

[sandyw]

Hi Ttelmah,

Thats it reported

- SandyW

[jeremiah]

[sandyw]

Reported directly to CCS support.

Got an answer back today. They have changed the ICD code and up issued it to 3.66.

I haven't tried it yet but I assume by the time they sent it to me they have.