18LF's not programming while 18F's are...

[ja771]

correction from last message:
18F485's - not 18F495, of course. typo.

[valemike]

Do you have any diodes whose cathode is hooked up to Vdd?

For example, MCLR sometimes needs such a diode (look at the PIC datasheet in the "Reset" chapter) to ensure quick discharging of a capacitor if you use one on MCLR.

Such a diode can screw up your ICD programming.

However, since you say you can program some chips and not others, i don't know if what i said above is relevant.

[ja771]

just using the UPM untouched - there are no diodes when you buy it, and i didn't add any.

but thanks again...
j

[Mark]

Okay, I have a univeral programming module as well. I compiled your test program and here are the results

[ja771]

i can program 18F4320 chips, just not the 18LF4320's. so i really don't think there's a connection problem.

powers (2x) on 11 and 32
groups (2x) on 12 and 31

PGD on 40
PGC on 39
VPP on 1

thanks for checking. can you use an 18LFXXXX, instead of an 18LFXXX?

j

[ja771]

PLAB ICD 2 Ready
Programming Target...
...Erasing Part
...Programming Program Memory (0x0 - 0x7F)
Verifying...
...Program Memory
ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val = 0xEF15, Val Read = 0x0)
ICD0275: Programming failed.
MPLAB ICD 2 Ready

[Mark]

I don't think I have any 18LFXXXX's. I only had an 18LF452 which is actually an ES which means Engineering sample which means its really old

[ckielstra]

Just a long shot:
In all your programs the #fuses statement is missing. In MPLAB without this statement the configuration bits will not be programmed as can be seen from your printouts. So I'm just wondering what default settings you will get then? What would happen if some Code Protection bits are active in your chips???

I mention this because I had a lot of troubles in clearing the Config memory in my 18LF458. After an 'Erase Part' in MPLAB v7.00 and a following 'Blank Check' I got errors on address 0x300001 which was still configured with my old 'HS' frequency setting i.s.o. the default value after reset. So apparently an erase doesn't clear all the Config bits....

The solution was to omit the 'fuses' line, but making sure to select in MPLAB the tab Programmer/Settings/Program 'Manually select memories and ranges' with the Configuration Memory selected. This way the Configuration Memory will be programmed with the default values and since then the 'Blank Check' works.

[ja771]

didn't work.

but thanks. i tried programming in debug too - just in case...
no go.

thanks though!

[bluetooth]

I think I have found something here.

To make a long story short: I solved the problem described here by upgrading to MPLAB 7.10 and turning off the Power Up Timer (NOPUT in CCS speak).

The gory details:

I have a new project that was supposed to have an 18F2520 on it, but all we could get quickly were 18LF2520's. Everyone said ok.

So I saw this thread and thought I'd give it a try (MPLAB 6.60/CCS 3.219). I got EXACTLY the same results as

Verifying...
...Program Memory
ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val = 0xEF15, Val Read = 0x0)
ICD0275: Programming failed.

I also got some strange results when I read in the memory. So strange that I figure it was time to upgrade to MPLAB 7.10. Downloaded that and installed it (man they've got that down, it picked up right where I left off from V6.60). Initially, it looked like it solved the problem. I could erase the part and get a good blank check, and I could program a part in programmer mode.

But a new problem surfaced: when trying to use the ICD2 for debug, all programmed/verified well, but at the end I would always get:

..User ID Memory
...Read Succeeded
MPLAB ICD 2 Ready
ICD0083: Target not in debug mode, unable to perform operation

I checked the fuses, and CCS is setting them all ok.

I then looked at the ICD2 Read Me on microchip.com.... and I found this:

[Guest]

Similar to this problem, I was unable to program and verify parts until I moved from a DC 9V wall supply to a full lab power supply.

[TSchultz]

Ran into a similiar problem with the PIC18LF8720 chips a while ago.

After doing a great deal of testing, and having several discussions with Microchip the solution was to ensure all of the following;

- make sure cable from ICD2 to PIC is <= 6 inches
- make sure no (minimal) parasitic effects of RESET pin
- make sure all VDD,VAA,VSS pins are connected
- make sure to power ICD2 with external power supply

Although a number of devices would program every time, others gave problems with the same conditions. The problem seemed to stem from their bulk erase command, this does not always execute if all of the above are not handled properly.

Even putting a scope probe on RESET to monitor it was able to reliably reproduce the problem. The RESET pin is very sensitive to the rise time when it's level is changed. If it is too slow the device does not reliably enter test/program mode but the ICD does not check this.

Microchip recommended always programming at voltages >= 4.2VDC, but this was not easy as a number of other devices on the board would not tolerate the higher voltage. On the next PCB revision we added a jumper so we could isolate the PIC power pins and apply an external +5VDC for programming. At 5V all the problems seemed to go away. The higher voltage is necessary if you intend to change any of the config bits.

[Christophe]

Try this #fuses; had the same problem:

#fuses XT, NOPUT, NOPROTECT, NOLVP, NOCPD, NOWRT, NOWDT, NOBROWNOUT

gl!

[Jo�o Paulo - Brazil]

The solution for the problem of icd0161: Don�t left unconnected de AVDD and the AVSS of your PIC. If you has connected the VDD, connect too de AVDD. Do the same for the VSS and AVSS.

The 51331B.pdf (Microchip site) say this. Take a look...


Congratulations from Brazil