Picaxe "forgetting" firmware

rq3

Senior Member
I build a commercially available product using a Picaxe 20M2, which has been in the field since 2013. On very rare occasions (3 times so far, out of hundreds), a customer will claim that the device has competely quit working. And it has. But, reinstalling the firmware is always successful, the device works properly, even after severe environmental stress testing, and the units appear to be fine, even many years later.

Long ago, I opened a ticket with Microchip about this, and they ultimately shrugged and mumbled about cosmic rays and bit hits.

This just happened again (the third time), and because I track serial numbers of the devices, it was interesting to note that they were all sequential serial numbers, from 2015.

Has anyone else seen this?
 

westaust55

Moderator
I have had one similar case with a 20X2.
I constructed a project in mid January 2016 so likely the chip bought locally was from a 2015 batch.

A while back (do not recall exact date) say around 18 months ago the project stopped working.
I initially swapped out the RS485 interface chip without success ad then programmed and inserted another 20X2 (had been bought at the same time) and the circuit returned to operation.
So I reprogrammed the original 20X2 and it also worked. Surmise is that my program had somehow been corrupted.
The original 20X2 is still back on the board and have not had a problem since in the ensuing time period.

Of the many PICAXE projects that I have built, including four other boards built in 2015 (these 4 are identical but for a different purpose to that mentioned above)
with combined 20X2 at 64 MHZ and 28X2 at 80 MHz (overclocked) non have incurred a program corruption/loss.

Semantic follow:
You mention "Firmware" however, the firmware is normally considered the assembler program that Rev Ed install into the PIC chips to create the PICAXE. The PICAXE firmware is akin to the BIOS in your PC or laptop.
Suggest, that it is your own BASIC "program'" (aka software) that you are having to re-program.
 

bpowell

Senior Member
If the PICAXE lost your program, but retained the PICAXE firmware, why open a ticket with MCHIP? Seems like you should open a ticket w/ Rev Ed.
 

inglewoodpete

Senior Member
If the PICAXE lost your program, but retained the PICAXE firmware, why open a ticket with MCHIP? Seems like you should open a ticket w/ Rev Ed.
My only observation out of this is the both the PICAXE firmware and the downloaded 'software' are stored in flash. Admittedly, the two modules are stored in different areas of the flash using different methods of storage. If you can still download your BASIC program, the PICAXE program area just lost something in its area. If the the PICAXE is 'bricked', then it's the PICAXE firmware area. Either area could lose its program but with different reasons and different solutions.

In programming hundreds of PICAXEs with thousands of downloads, I have not had a failure that was not of my own making. I would put lost downloads down to bad fortune.
 

rq3

Senior Member
If the PICAXE lost your program, but retained the PICAXE firmware, why open a ticket with MCHIP? Seems like you should open a ticket w/ Rev Ed.
The Picaxe 20M2 works as advertised. The bootloader from RevEd survived and works. The code I installed on the 20M2 evaporated after a number of years, yet the RevEd bootloader still works. Hence, I believe this is a MicroChip issue.
 

hippy

Technical Support
Staff member
Long ago, I opened a ticket with Microchip about this, and they ultimately shrugged and mumbled about cosmic rays and bit hits.
I suspect that would ultimately be our response, that if that is happening there is little we can do about it. It would seem to be such a rare event that it would be almost impossible to replicate and diagnose, to tell what had actually happened, even more so why.
 

MartinM57

Moderator
...On very rare occasions (3 times so far, out of hundreds), a customer will claim that the device has competely quit working....
Yes, when I had a DISABLEBOD command in the code trying to minimise the NAP power consumption - it had minimal effect on the consumption but appeared to have the nasty side effect of corrupting the EEPROM on power up/power down and making the program appear to have completely quit.

I solved it by belt and braces - remove the DISABLE BOD and change the design so that instead of using the EEPROM as a look up table, I calculate the required value on the fly.
 

Buzby

Senior Member
DISABLEBOD is a very dangerous command.

It's only real benefit is to reduce power consumption on a known stable supply. Even then, if the supply is switched off, it can still cause problems.

Running without BOD risks EEPROM and RAM corruption when using a very low supply, or even just a dip in supply volts.

Much better to leave it active !.
 

bpowell

Senior Member
The Picaxe 20M2 works as advertised. The bootloader from RevEd survived and works. The code I installed on the 20M2 evaporated after a number of years, yet the RevEd bootloader still works. Hence, I believe this is a MicroChip issue.
It's academic at this point; but I'd argue the 20M2 is NOT working as advertised; however, the silicone chip itself is. The PICAXE firmware and the user-loaded code don't exist in two separate areas on the chip. It's all flash memory. If you're just losing the user code and not the firmware, I'd lean towards the firmware (PICAXE) being the culprit ... if it was the silicone, I'd expect the PICAXE firmware itself would have just as much of a chance of being corrupted or erased as the user code. Sounds to me like the PICAXE firmware zapped the user code for some reason ... maybe it thought a download was starting? Who knows?
 

Goeytex

Senior Member
Ditto to bpowell's analysis.

The Flash memory of a 20M2 is organized in to 3 blocks of memory as far as "write protection" is concerned. The area where the firmware resides is write protected, meaning it cannot be self-written, whereas the area where the user program resides is not and cannot be write protected so as to allow it to be programmed via EECON registers (self-write)

Since it only happens to memory that is not write protected, there could be a correlation. This hints at a rare/obscure bug that under the right conditions could somehow "write" to the program memory area. ( All theoretical). This would be extremely unlikely to happen given the necessary steps required to self-write to flash memory. But still maybe just a tad more likely than a hit by a cosmic ray or a hit by a highly energized proton particle due to to a solar flare or coronal mass ejection.
 
Top