search

free-pdk / easy-pdk-programmer-software

Easy PDK programmer for PADAUK microcontroller
https://free-pdk.github.io/
GNU General Public License v3.0
112 stars 37 forks source link

Add Erase Count for Flash based parts #43

Open serisman opened 4 years ago

serisman commented 4 years ago

I noticed while looking at the fppa-pdk-documentation that the original Writer keeps track of erase counts for flash based parts in the last 'reserved' section of code memory.

That may be a useful feature to retain.

I have a few MTP ICs that I have written to a bunch of times during development, but have no way of knowing how many times, or how close they are to needing to be replaced. The datasheet simply states "programming cycle at least 1,000 times", but it might be nice to start gathering our own data. At least knowing how many times an IC has been erased/written would be interesting to track, especially if we start receiving reports of failures.

Potentially the programmer software could print this value out after a probe and/or read, and also print out the updated value after an erase and/or write. I might be a good idea to print a notice or warning message if the value is over 1000 as well.

freepdk commented 4 years ago

I decided to give this space to the user as program memory.

What is the stat useful for? What would you do when:

1) erase counter is <1000 and writing of IC is not working anymore ==> throw away IC, use next one... it's cheap 2) erase counter is >1000 and writing of IC is not working anymore ==> throw away IC, use next one... it's cheap 3) erase counter is >1000 and writing of IC is working ==> throw away a working IC?

So what would you use the stats for? To monitor if PADAUK claims are true?

serisman commented 4 years ago

I decided to give this space to the user as program memory.

Aren't there several unused words after the factory calibration values, before the fuse value? Those would probably be more effort than worthwhile for a user program to actually use.

It could be made into an optional feature as well. Maybe a command line option that the programmer uses the first time to set a magic value in one location, and a counter in another location. Then, it checks if the option is enabled in the future by reading the magic value. Then it could read the counter, erase, and re-write the magic value and the new counter. So, 3ish words used.

What is the stat useful for? What would you do when:

  1. erase counter is <1000 and writing of IC is not working anymore ==> throw away IC, use next one... it's cheap
  2. erase counter is >1000 and writing of IC is not working anymore ==> throw away IC, use next one... it's cheap
  3. erase counter is >1000 and writing of IC is working ==> throw away a working IC?

So what would you use the stats for? To monitor if PADAUK claims are true?

I think it is more a case of: DATA > !DATA

We don't know if 'at least 1,000 times' means 1,001 or 2,000, or 10,000, or 100,000, or more likely somewhere in-between depending on what the actual conditions are.

I don't think throwing away a working IC makes sense, obviously, but if one failed it might be a helpful indicator of how much time/effort is worth troubleshooting before just replacing with another one. There are still times that programming fails for one reason or another, even with a 'good' IC. I had a PFS173 that kept failing calibration over and over again the other day, until I walked away and came back an hour or two later, and now it is totally fine again. I almost gave up and pulled out the hot air gun to remove/replace the IC. Obviously a loose IC in a socket is a bit easier to replace than one already soldered to a board (i.e. a 'dev board' or 'evaluation board').