11
\$\begingroup\$

This question is related to AVR deprogramming itself.

Project info:
We have a battery powered product using an ATMEGA644P. The application permanently runs in sleep mode and only wakes up once a second (RTC) or when one of the two external interrupt lines is triggered.

The device features a pretty simple boot-loader that is communicating over UART (using RS232 interface IC). Its just serves as a convenience method to update the firmware so that no hardware ISP programmer is required. (The boot-loader expects checksum secured telegrams)

The devices was designed with internal brown-out DISABLED because it doubles the power consumption and long battery life is mandatory (I guess that an external brown-out detection should have been used - a re-design is in work).

Problem:
Every few month a device just stops working, there were NO firmware updates performed on those devices. However, after further examination, the flash contents of those devices seem to be corrupted. Furthermore, the batteries of some of those devices were still good, but I don't want to rule out some kind of under-voltage situation.

This is a comparison of the original flash contents (left) to the corrupted contents (right):

Flash comparison

Some observations:

  • A corrupted block always consists of at least one flash page (256 bytes) and is page aligned. In other words: Only whole pages are affected, not single bytes.
  • Corrupted content reads 0xFF most of the time, but may also contain some other values or be completely "random".
  • The small bar on the left side of the image shows all affected areas. For this device, its about one tenth of the total flash contents.
  • We had one device where only a single page was affected.

It is totally plausible that an under-voltage condition while writing the flash memory can corrupt flash contents. However, this would mean that some flash sensitive instructions have to be executed.

Maybe the controller is randomly restarting due to under-voltage and the boot-loader code is acting entirely unpredictable during this time. To quote some guy from another forum regarding under-voltage:

"It is not only random instructions from flash being executed, but random instructions period (there is no guarantee that the code from flash will be read & interpreted correctly). Along with this other parts of the mcu may not behave as designed, including protection mechanisms."

Question(s):
Do you think the "random behavior during under-voltage and executing some instructions changing data in flash pages" - explanation is sound? If that is the case, why don't we see this kind of errors all the time just as a cause of some software issues (stack overflow, invalid pointers).

Do you have any other ideas what could cause this kind of corruption? Could this be caused by EMI/ESD?

\$\endgroup\$
2
  • \$\begingroup\$ In the second block in your example, did any bits go from 1->0 or all they all 0->1 transitions? I have a script that computes this, but I'm not going to type in all the numbers from your screenshot. \$\endgroup\$
    – markrages
    Jun 25, 2014 at 15:55
  • \$\begingroup\$ @markrages: From looking at it, 0->1 only. One answer also pointed out, that it looks like a partial erase where not all bits were flipped to 1. Thanks for the observation. \$\endgroup\$
    – Rev
    Jun 25, 2014 at 19:38

4 Answers 4

Reset to default
11
\$\begingroup\$

You should notice that the flash is not written, it is erased. An erased flash is full of 0xFF. Your first 256 bytes are totally erased, your third 256-bytes region is partially erased (you only have 0 to 1 bitflips from correct data to corrupted one).

According to the datasheet, this flash is page-erasable (I usually work with erase-blocks bigger than the pages). As seen in page 282, Performing Page Erase by SPM is pretty easy.

You may be interested by section 23.8.1 ( Preventing Flash Corruption ) :

A Flash program corruption can be caused by two situations when the voltage is too low. First, a regular write sequence to the Flash requires a minimum voltage to operate correctly. Secondly, the CPU itself can execute instructions incorrectly, if the supply voltage for executing instructions is too low. Flash corruption can easily be avoided by following these design recommendations (one is sufficient):

  1. If there is no need for a Boot Loader update in the system, program the Boot Loader Lock bits to prevent any Boot Loader software updates.
  2. Keep the AVR RESET active (low) during periods of insufficient power supply voltage.
    This can be done by enabling the internal Brown-out Detector (BOD) if the operating volt-age matches the detection level. If not, an external low VCC reset protection circuit can be used. If a reset occurs while a write operation is in progress, the write operation will be completed provided that the power supply voltage is sufficient.
  3. Keep the AVR core in Power-down sleep mode during periods of low VCC . This will prevent the CPU from attempting to decode and execute instructions, effectively protecting the SPMCSR Register and thus the Flash from unintentional writes.
\$\endgroup\$
5
  • \$\begingroup\$ Your observation about the partial erase on the third page seems plausible. Regarding the Atmel text: We all agree that BOD seems to be mandatory. But I am still not sure about the EXACT cause of the corruption. Isn't it pretty unlikely that the controller just executes (because of low-voltage) this specific instruction to erase a flash page? I mean, this would even have to happen during boot loader code execution, since flash is only writable from there. And it requires a specific sequence. \$\endgroup\$
    – Rev
    Jun 25, 2014 at 19:30
  • 3
    \$\begingroup\$ It's not possible to explain the exact source of the corruption : as your Vcc drops, it becomes too low to fully saturate one transistor with an other one. A MCU is basically a very big logical equation. If your transistors stop behaving as logical switches, you change this equation. As the first transistor to misbehave depends on ASIC Wafer doping and external electromagnetic perturbations, you can't predict what will happen. To address this issue, when you design your ASIC, you may add an analog part that switch off digital part before misbehaving. But it increase the whole ASIC cost. \$\endgroup\$
    – Jacen
    Jun 26, 2014 at 11:35
  • \$\begingroup\$ Confusing that the application note AVR180 External Brown-out Protection states: "Note that AVR® internal Flash Program Memory contents are never affected by insufficient power supply voltage". Further: "As the AVR CPU is not capable of writing to its own program memory, the internal Flash Program memory contents are never affected by a power failure situation." - IMO Atmel is just ignoring that there is something like boot loaders that HAS TO change flash mem. \$\endgroup\$
    – Rev
    Jun 30, 2014 at 7:25
  • \$\begingroup\$ @Rev1.0 Well yeah, it's pretty unlikely... that's why you only see it on one device every few months, rather than all the devices all the time. \$\endgroup\$
    – user253751
    Aug 20, 2018 at 23:22
  • \$\begingroup\$ "I mean, this would even have to happen during boot loader code execution, since flash is only writable from there." - That's only true if the boot lock bits (BLB01 and friends) are set appropriately! Are they? "Confusing ... application note ..." - Application notes are notoriously unreliable. Use them for inspiration only; for guarantees, rely on the datasheets (which are also not infallible but hey). \$\endgroup\$
    – marcelm
    Aug 21, 2018 at 8:56
4
\$\begingroup\$

This is a well known problem, and affects many microcontrollers (not just Atmel). The flash memory control hardware corrupts or erases part of the memory under low voltage conditions. The simple fix is to enable brown-out protection.

You should always enable brown-out protection on microcontrollers as a matter of course.

\$\endgroup\$
3
  • 3
    \$\begingroup\$ Do you have any solid references about HOW and WHY "memory control hardware corrupts or erases part of the memory under low voltage conditions"? There are plenty of forum discussions regarding flash corruption but it almost never comes down to something solid, which is why I asked here. \$\endgroup\$
    – Rev
    Jun 25, 2014 at 13:41
  • \$\begingroup\$ Is it in-chip under-voltage problem or is it related to wrong/random execution of program in bootloader section which AFAIK only can modify FLASH. If the second is issue disabling bootloader execution via FUSE should solve issue. \$\endgroup\$
    – TMa
    Jun 25, 2014 at 13:41
  • \$\begingroup\$ I remember reading about it in the errata of at least one MEGA micro. \$\endgroup\$
    – user
    Jun 25, 2014 at 17:18
4
\$\begingroup\$

The under-voltage is a very likely cause. For example, I once had a project where a brown-out level of 1.8 V frequently caused corruption, and these corruptions could never be reproduced with a brown-out level of 3.5V.

Note, that the faster the processor runs, the more sensitive it is to under-voltage problems. If lowering the CPU frequency is an available option to you, it might be worth a try.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Thanks for answer. We ended up using an external ultra low power brown-out detector and had no corruption problems ever since. \$\endgroup\$
    – Rev
    May 14, 2015 at 19:48
0
\$\begingroup\$

EMC will be your biggest enemy, if one doesn't follow the main rules of PCB design. Here are the most important ones from my own experience: - blocking capacitors on any IC, regardless of what the manufacturers tell you in their datasheets about infernal schematics, put at least one between 100pF - 1nF on each IC's power lines - conducting ground areas on each PCB's layer as much as possible. Those areas shall be contacted through all layers via vias as often as possibe, a grid oft 50mil is a good value. Connect those areas to ground signal. - Never leave unconnected (floating, to no signal connected) copper in your PCB. It acts like an antenna and devinitifely puts electro-magnetic radiation onto the devices - make traces carrying clock signals as short as possible

Find more Details by search engine requests like "guide for emc proof pcb design"

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.