EEPROM - Problem writing more than a handful of data?

blackcattech · Post by **blackcattech** » Thu Mar 21, 2013 1:55 pm

I've got an unusual problem with writing data to the internal EEPROM of the PIC18F24K22. I was experiencing unusual operation in a program I'm writing and it wasn't until I checked the contents of the EEPROM (where some calibration values are stored) that I found for some reason some EEPROM writes weren't working.

I have a 'default' configuration defined using Consts. I check a specific location to see if it is written, if not I write this default config in to the EEPROM. The last 3 or 4 words weren't being written. I found if I changed the location of this data the problem still recurred. I tried altering the sequence in which data is written and the problem data now wrote correctly but other data failed to write.

The only solution I have found so far is to do a EE.Read in the middle of the writes. Presumably this clears something but I'm not sure if it is an issue with Swordfish or with the PIC itself.

Has anyone seen this and come up with a solution?

It only appeared to write 37, occasionally 38 bytes before failing. This is an unusual number and to me would suggest a PIC issue but who knows? I tried adding delays of 100us between writes but that didn't help.

While I do have a solution it would be nice to know why this is happening so I can make sure the code is robust.

For reference, the PIC is clocked at 4MHz and is running from 3.3V

Jerry Messina · Post by **Jerry Messina** » Thu Mar 21, 2013 4:56 pm

There's no reported errata for the 24K22 eeprom, and a quick glance at EEPROM.bas doesn't throw up any obvious red flags.

Do you have interrupts enabled while doing the writes? If so, you might try disabling them and see what happens.

blackcattech · Post by **blackcattech** » Thu Mar 21, 2013 5:33 pm

Hi Jerry,

It is a bit of a mystery, I've done the same as you and checked the errata and can't spot anything.

I don't specifically disable interrupts before calling this code but it also comes before I enable them so that shouldn't be an issue. I will double-check tomorrow and make sure they are disabled, I must admit I've just wondered if this is one of the settings that is maintained after a power-on reset rather than defaulting to off...

I've got my PicKit3 plugged in and set to automatically update on file changes so the power is always applied. If the various interrupt control registers don't reset on power-on then you may well have hit the problem.

blackcattech · Post by **blackcattech** » Fri Mar 22, 2013 2:15 pm

Just a quick update, it does appear to be an interrupt issue.

I can't find anything in the datasheet but it appears that GIE etc are only cleared / disabled on a power-on or brown-out reset. Forcing the interrupt off before calling the EEPROM writing routine appears to have solved the problem.

If anyone has spotted where in the datasheet it shows the status of the SFRs after 'other' resets it would be useful to know - the text sort of indicates it is there but when I actually look at the table it refers to you only get POR/BOR reset status.

Jerry Messina · Post by **Jerry Messina** » Fri Mar 22, 2013 5:09 pm

Table 5-2 does seem to be missing some info. If you take a look at another similar chip in the K22 series (like the 87K22) they show it. Usually the difference is that at PON some bits are undefined, where other resets they are unchanged from the state they had before the reset.

AFAIK, there are only a few registers that don't initialize after a 'reset' event, such as RCON and the STACKPTR status bits to name a few.

INTCON (where the GIE bit resides) should always be cleared after any reset.

What type of 'other reset' is occurring where you don't see GIE cleared?

blackcattech · Post by **blackcattech** » Sun Mar 24, 2013 11:01 am

I'm not sure what sort of reset was occuring - what I was doing was making a change to the code and uploading it to the PIC via a PICKit3 without removing power.

Now, I assumed that the PICKit does an MCLR reset but maybe not? Maybe the PIC just keeps executing code in these circumstances?

I guess this is a useful lesson to learn, you can't assume the device will be in a reset state after uploading a new program. However, it also presumably helps find things that could come back and bite you later on...

Jerry Messina · Post by **Jerry Messina** » Sun Mar 24, 2013 3:08 pm

Now, I assumed that the PICKit does an MCLR reset but maybe not?

Your assumption is correct. The PICkit wiggles the MCLR line in the process of getting the chip into/out of programming mode (usually a number of times).

I think both MPLAB and the standalone app have menu settings/controls which allow you to assert/release the MCLR line... might be handy for testing.

blackcattech · Post by **blackcattech** » Sun Mar 24, 2013 7:18 pm

Which only makes things odder as adding a Disable(OnISR) at the start of my code cured the problem but the reset should have disabled interrupts anyway...

I guess belt and braces is always best, but still, it would be nice to know what is going on.

By the way, do you have any experience of the PICKit3? I'm struggling a bit with the software for it. I'd used the PICKit2 before and the program was a nice simple installer. However, for the 3 there doesn't seem to be an installer, you just unzip the directory and run the program from there as far as I can see.

Aside from meaning you have to create your own shortcut it appears to be causing problems on my PC. IT seem to have the computers set up in such a way that you need to go through an installer to get access to the hard drive and as this wasn't the case it crashes every time I close it as it can't update the .ini. I'm surprised Microchip haven't done an installer so am I just looking in the wrong place?

Jerry Messina · Post by **Jerry Messina** » Sun Mar 24, 2013 7:39 pm

Which OS and which PICkit3 programmer app?

If it's win7 then there's a good chance you can't write to INI file if it's in the same dir that the program's in. Try putting it in a sub dir NOT under program files.

The newer PICkit3 Scripting App V3 is a strange beast if that's the one you have. It turns your PICkit3 into a PICkit2 for all practical purposes. Check out this thread for a link to the old standalone app http://www.sfcompiler.co.uk/forum/viewtopic.php?t=1732

blackcattech · Post by **blackcattech** » Sun Mar 24, 2013 8:18 pm

Thanks, it is the scripting app I have and I am also running Win7 so that also explains the issue I'm getting. I downloaded the latest software from the Microchip website when I got it, seemed a better idea than using what was on the disc that came with the programmer. Seems maybe I was wrong!

I did notice that the software even refers to it as a PicKit 2 in places. I'll try that other app on Monday and hopefully it will improve things...

Thanks for your help, Jerry, appreciated as always.

Jerry Messina · Post by **Jerry Messina** » Mon Mar 25, 2013 9:09 am

There's nothing necessarily wrong with the PK3 scripting app. It does give you access to some features they never implemented in the standalone app like device autodetect. Unfortunately you're stuck with the same device support that the PK2 had since it shares the same dat file. You basically get the PK3 back to the same point that the PK2 was in 2011. Isn't progress wonderful?

My other complaint is that it has to reflash the PK3 to do this, and that makes it incompatible with MPLAB. If you're like me and you use MPLAB for debugging then you're constantly reprogramming the thing . I've bricked a few PK3's reflashing them... getting them back to life wasn't fun.

blackcattech · Post by **blackcattech** » Wed Apr 03, 2013 3:55 pm

Any tips on fixing a bricked PK3? Mine appears to have died...

I was trying to get the Programmer-on-the-go function working which meant reverting to MPLab mode. This appears to have killed it. I can't even get the bootloader to work to allow be to reflash it...

Is there a way to do it without buying another programmer and opening this one up to reprogram it?

Jerry Messina · Post by **Jerry Messina** » Wed Apr 03, 2013 5:29 pm

Oh boy.

I'm not sure what state the firmware left the thing in, but you can try holding down the button while you insert the USB to force it into bootloader mode. That used to work with the PK2 (not sure if it's in the new firmware or not).

Short of that, you need another programmer to revive it. To make matters worse, if you pop open the PK3 you'll find that the ICSP connector is a "non-standard" one. It's on 50 mil centers if I recall, so you'll likely need a special adapter.

blackcattech · Post by **blackcattech** » Wed Apr 03, 2013 7:41 pm

Oh, rude words...

I'd read that the PicKit3 could be a bit dodgy but I thought I'd risk it, especially as I'm intending to use some newer PICs including the PIC24 series so thought it would be more likely to have support...

First time I've needed to do anything to it and it dies....

I've tried holding down the button, all the lights come on but nothing can recognise it. I've tried both PK3 applications as well as MPLab8.7 and 10.

I do have a PK2 somewhere, I'll see if I can do anything with that but I'm minded to just return it as faulty.

I did notice that someone is advertising on eBay, £10 to fix bricked PK3s! Must be such a common thing... And looking on the MCP forum it's been happening since 2010 but no obvious improvement.