USB programmer problem 18LF4620

[BrianT]

I have some data loggers using the 18LF4620 storing data in multiple M25P64 fllash memory chips. In an attempt to recover data from some data loggers where the battery went flat and the processor code memory has been largely erased, I have stitched some wires to the on-board 18LF4620-PT, 44 pin TQFP package, to allow my MeLabs USB programmer to program the chip via ICSP.

I am running the latest 4.22 beta code for the USB programmer. I can read the processor main memory, the configuration data and the data EEROM. I can see that the EEROM data is correct so I am definitely reading the chip BUT I cannot program the chip. I have the 18F4620 as the selected device in the programmer selection window.

Every time I try to program I get the message 'Target device does not match selected device' yet the chip is a genuine 18LF4620 and they have programmed before.

When I turn off the target device checking it then fails with an 'Erase failed' message. If I turn off the erase before programming it prompts for 'device not blank - program anyway?' . I say yes to that then it looks like it is programming but comes up with many 'code verify' errors.

How come the USB programmer can read the PIC but not program it?

Cheers
Brian

[Bruce]

Is there anything connected to the PIC programming data & clock pins while you're trying to program it in-circuit?

Do you have LVP enabled?

[ohararp]

Brian,

Sorry I can't help with your original problem. I am kicking myself for not putting an icsp port on my boards! Same problem. Good luck. In future designs I am going to put a header that will allow me to connect in with a little "middle man" board that has the 10k resistor and diode (the LL4148 works great for this) on board. Then If I have issues I only have to connect a single header.

You don't suppose you could chare the interface code to the huge SPI Flash memory that you are using? I would love to use these in an upcoming project.

[BrianT]

The lesson for my future PCBs is to not trust the bootloader exclusively. If the code gets scrambled the bootloader fails and you are up that famous creek.

A trawl of the Melabs site ended up at http://www.melabs.com/support/meprogfixes.htm where I found....

Programming Errors:

"Target device does not match selected device." - This indicates that the programmer has read an unexpected device id from the target PIC®. Make sure you've selected the correct device in the dropdown list on the toolbar. You will also get this error if the programmer can't put the PIC into programming mode. This can be caused by low power supply voltage, a defective PIC, incorrect placement of the PIC in the programming socket, or a bad in-circuit programming connection.

Problems specific to PIC18F1220, 18F1320, 18F2220, 18F2320, 18F2620 and 18F4620 can sometimes be fixed with a small modification to your Serial Programmer board.

I added the capacitor and squeaked the voltage up a bit ( I have parts on the board rated MAX 3.7 volts) and hey presto it works now.

Having got the ICSP attached I could read the PIC EEROM and program memory. This showed some unextected results. The first 60 bytes or thereabouts of program space look like code but from there to top of memory, the PIC reads FF in every cell. Somehow the code initiated an 'erase mem' comand. The EEROM was correct except for three cells which are frequently read but very rarely if ever written to.

My next PCB will have accessible pads for PGC, PGD, Vss, Vdd and Reset to allow attaching the ICSP when/if the bootloader fails. That will be very tight on an already crowded board.

I think the mixing of 5 volt programmers with 3.3 volt boards will lead to more of these subtle problems.

Brian

[BrianT]

Sorry I did not answer your specific questions.
Bruce.
PGD, PGM and PGC are floating. LVP is turned OFF in the configuration fuses. The problem I am sure was voltage related where I suspect the USP programmer is looking for something near 5 volts and it was only getting 3.1-3.5 volts. The new cap from Vdd to Gnd in the USP programmer probably helped as well.

Oharap.
My code is currently set up for two M25P64 serial interface flash memory chips which receive data as 8 blocks x 256 bytes for a total of 2048 bytes per record. I (wastefully) time and date stamp every block and record housekeeping data like current AGC setting for diagnostic reasons. Spansion now have a 128 Mbit chip in a compatible footprint package so I might tweak my code for their M25FL128 chip after I have had time to read the fine print. These guys all claim 'industry compatible' and software compatible throughout their range but it aint really so. ST dropped their 'deep power down' command when going from 32 Mbits to 64 Mbits sending quiescent current from 2 uA up to about 100 uA and forcing me to add a PNP power switch to the memory that brings new complications during the power up/down sequencing of the interface pins to the PIC. At least the pinout remained the same. Spansion has a byte wide parallel load/dump feature which could speed data transfer but I can't fit the extra interface on my board. I am happy to send you the code but you will need to unravel all the 'junk DNA' that has been quietly festering over the half dozen hardware and software revisions on this project.

HTH
Brian

[ohararp]

Brian,

Thanks for the input on all fronts. I use all the devices you mention and will be adding a cap per the melabs guidance to help with programming.

As for code I am looking for a starting point for the interface and will then modify as the actual chip needs. I am looking for a flash type memory that is not sd for an upcoming gps logger. I'll pm you in the near future! Best of luck.

Ryan O'Hara