EEProm Error

[Craig Shaw]

I am trying to program a 16F25K80. All except location 5 of eeprom programs and verifies. Location 5 always has FF. If I atempt to write location 5 I get an error and a read of eeprom reads FF

[Anobium]

I will ask the obvious questions.

What are you using to program the device? PICkit2, PICkit3 or user HEX ?

[Craig Shaw]

Sorry, it was a detailess question. My fault. I was using a pickit2. First tried with the Microchip prog software and then PK Plus. Both programs do the same thing. I tried another PIC and it had the same problem. I have a pickit 3 and should try that, but this is the first time I've had a problem with the 25K80 and PK2. I programmed 2 other PIC's with the programmer (no eeprom values) and they work just fine. The files are hex files. It just seems to be the EEPROM that has a problem, the program area works just fine. Unless of course I have some bad 25K80's, but its odd it is only location 5 that doesnt work, 0 to 4 and 6 onwards all program!

[Craig Shaw]

I have now tried 10 x 25K80's with the PICKit 3. All the same, location 5 of eeprom is FF and should be 00. How do I check the HEX file, and indeed could that be the problem. I am very confused. Or is it my PC given that all other bytes program correctly, and how can that be?

[Anobium]

Send me the HEX. Let me look.

[Craig Shaw]

Not a problem. The person who wrote the code suggests that the PIC runs between write and verify! I did not consider this given that the pic runs on a crystal oscillator so how does it run, perhaps I'm missing something. The PICKit 2/3 doesn't have a crystal ?? I see add attachment but it doesnt work. I'll try chrome, since this is IE.

[Craig Shaw]

The file works with google. I'll have to switch, bugger

[Anobium]

Got the source?

[Anobium]

Your HEX has data at EE location 0. And, the code when loaded doed update EE location 5.
If the period between initial programming and verification the write to EE location 5 is happening. The programmer should have put a small delay in the program to ensure the verification did not happen.

I tested with PICKitPlus using PK2 & PK3 and Northern Programmer.

[Craig Shaw]

Thank you for your help. I learn something new every day. Cant pretend to understand, but obviously the PIC was programmed correctly.

Many thanks

Craig

[Anobium]

:-).

The program (the hex) updates that byte the moment the program runs... bad practice as it will fail on verify. If you can get the source then this is easily sortable by adding a small delay at the start of the program.

[Craig Shaw]

I have subsequently learnt from people who program the 25k80 that they program and verify the code then separately load and verify eeprom. That is 2 separate steps. Apparently this works. What I still dont understand is, how does the pic run at the end of programming so that it actually writes to the eeprom. I thought it would be dead until put into a device and then runs at power up

[Anobium]

This make sense. As programming is, general and empirically, reliable then what you could choose not to verify the programming operation.

[Craig Shaw]

I am back at the start, I am a member of MERG in the K and members have struck the same problem. But I get shot down when I mention your software and am told to use IPE. I cant get it to work. This is what I posted to MERG today (they wont help and could care less I think):

***Gentlemen,

Installed the IPE but get a connection failed on PK3 using usb connection with correct device selected and tool connected to the PK3 (it does see it). So I cant try it. I updated the OS to the latest on the PK3 with PK3Plus software, but ipe still wont connect. Found this issue on the web but the solutions do not work. Any other ideas? I have read switcher is not necessary with usb connections, but I tried that and it made no difference anyway.
*
So I again tried the PK3 with PK3Plus and found the following. If the software is set to write/verify it fails with loc 5 set to FF.***

---

*** But if I unset write/verify and disable write eeprom I can write and verify program memory. I then disable program memory and enable eeprom and write eeprom it will verify.

*If I take the now programmed pic and verify against the hex file it verifies OK with loc 5 set to 00.
**
** Checking "Hold PIC in RESET" does nothing in all cases, its the program/verify enabled that causes the problem. So somehow in program/verify mode location 5 of eeprom gets set to FF. This is odd or a bug I think. I'll pursue it with Anobium and see if they can give me a rational explanation as to how this happens. How the hell could a pic without an oscillator run so as to set location 5, makes no sense at all.

*** But I have programmed it successfully so I can get by with this method until......
*
*** If I could get the IPE to work with the PK3 I would use the IPE, it looks OK to me.***

*** Craig***
*

The third last paragraph pretty well sums it up. Merg does not believe the pic can run to set location 5 of eeprom without an oscillator, and of course in the PK3 it doesnt have one! Does it?

I am so, so confused. I assume the PK#OS in your software is the latest (PK3OS200..5.hex or something) and I have put that on the PK3. Why wont the PK3 work with IPE but does work with your, and Microchips by the way, software

[Craig Shaw]

Its a PIC 18F25K80 by the way, and it seems to be the only PIC MERG uses that has this feature while progam/verify is used.

[Anobium]

Morning.

I will get a 18F25K80, then, I will analyse the protocol and report back.

But, a few insights.

1. We use the stock PK#OS. We believe this is critical to keep things easy.
2. IPE uses one operating system in the PK3 and we use the stock PK#OS. This means thay we know what the PK#OS does... only Microchip know what goes on inside IPE.
3. The programming duration is externally timed and is controlled by PGC (which is controlled by the PK#OS and the PICKitPlus software). This is stated in the programming reference guide.
4. Re 'Hold PIC in Reset'. The software does do operate, as follows:

            if (MCLRtoolStripMenuItem.Checked)
            {
                checkBoxMCLR.Checked = false;
                MCLRtoolStripMenuItem.Checked = false;
               Pk2.HoldMCLR(false);
            }
            else
            {
                checkBoxMCLR.Checked = true;
                MCLRtoolStripMenuItem.Checked = true;
                Pk2.HoldMCLR(true);
            }

This essentially means if you select that then MCLR_GND_ON - Turns on VPP NPN ground.

But, the state MCLR will change during the programming cycle (per the programming scripts) and I have not checked that the state of MCLR is returned the pre-programming state during a programming option.

1. That chip has an internal oscillator. The default is 8mhz so you do not need an oscillator to make this chip work. :-)

Anyway, I will get a chip and report back.

[Anobium]

When I examine the programming protocol for this chip... I will be able to tell you the exact nature of the write to EEProm location 5. :-)

[Craig Shaw]

Evan,
Simple with program/verify checked, write the hex file to the pic. When it completes do a verify and it fails! This may be user stupidity but if program verify is checked does a verify happen in the background that you dont see when it does the write, because that seems to be successful?. Because doing a verify after write/verify is checked it fails. Is the pic running before the second (possible) verify

[Anobium]

I have the chip here. And, I can reproduce the error.

This must be a long standing error as this error happens with every version on the software including the Microchip original software of the Pk2 and Pk3.

I already know.
1. This is a long standing error. Problably plagued the users for years.
2. The source HEX has data set to 00 at EEPROM 0x05
2. MPLAB-IPE work correctly.
3. Northerm Programmer work correctly.
4. The PICKit parts programming basebase has the following:
* A script to erase the FULL part
* NO script to erase just the EEPOM

So, I already know where to look - the PICKit parts programming basebase .

It is highly likely the script is incorrect. As the script was created by someone (not me) and it has an error which is creating the error.

All sortable. Tell the gentleman MERG in the K I am 'on the job to resolve' - hopefully.

[Anobium]

I also know that the person that created the programming entry for the 25K80 simply copied an existing entry creating the 26K80. This happened in a release of the database called 1.62.14. But, the script cannot be copied across. :-(

So, I will resolve by creating a new programming set of scripts.

[Anobium]

I have spent some time looking into this.

I am very sure this is a script error. I can prevent the error from happening but essentially the script is not supporting any form of timing. It is simply throwing the data at the EEPROM. If you repeatedly read a device... you can see similar issues... the data read changes....

I will have another later this week.

[Craig Shaw]

At least it was a problem/bug. I hope you can resolve it.
Thanks
Craig

[Anobium]

I hope so. It does look like a timing issue. If I debug the SPI operations one EEPROM row write at a time there is no issue. So, hence I have hope.

[Anobium]

Here is a demo of the device being programmed with your source file.

https://1drv.ms/v/s!Ase-PX_n_4cvgs1czq-lZlKouTBxAA

If it does not play online, download and watch locally using VLC player.

[Craig Shaw]

Well that looks great. Using your software and my pickit 2 or pickit3 was what I wanted. The MERG people go on about IPE but I couldnt get it to go, complains about comms error. I think I have to go to MPLAB mode to use IPE. I prefer a working pickitplus option. Others at merg want to use the old method as well.
Regards
Craig