Brown out detection failure on AVR Mega and Xmega

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All

I got various PCBs that use AVR Mega and XMega that are being powered using Li-Poly batteries.

We have noticed that even though we have set the brown out to 1.8v , the flash memory is being corrupted on few PCBs.

Has anyone else experienced flash getting currupted even after brown out being set when connected to a li-poly battery?

Regards

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For example, xmega32E5 seems to have a problem with writing EEP and flash below 2.0V.

 

I have never used them at such a low voltage so I have no experience with those troubles.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

djoshi wrote:
we have set the brown out to 1.8v , the flash memory is being corrupted on few PCBs.

Is the flash memory actually changing, or is it just not running correctly due to corrupted instruction fetch of the flash?

What is the cpu clock rate of the system, is it operating with in spec at that voltage?

Do you have a bootloader on the chip?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kabasan wrote:

For example, xmega32E5 seems to have a problem with writing EEP and flash below 2.0V.

 

I have never used them at such a low voltage so I have no experience with those troubles.

 

Maybe i can start keep all brownout to 2.8V instead now.

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

djoshi wrote:
we have set the brown out to 1.8v , the flash memory is being corrupted on few PCBs.

Is the flash memory actually changing, or is it just not running correctly due to corrupted instruction fetch of the flash?

What is the cpu clock rate of the system, is it operating with in spec at that voltage?

Do you have a bootloader on the chip?

 

Jim

 

 

Yes it seems like that flash is changing, this can be confirmed by compare the extracted hex file to the original hex file.

CPU clock is 8Mhz.

 

Yes there is a boot loader, but its not used, but was kept there to make it full proof. Can this be a problem?

 

 

 

 

 

 

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

djoshi wrote:
Can this be a problem?
Yes; if possible, make flash programming conditional (keyed, signed, etc)

Else, remove dead code.

 

XMEGA are 8ms typical for atomic flash page erase and write; sampled BOD period is 1ms (NVM controller state machine may stop without an exit)

External BOD are more precise, more accurate, an order of magnitude less delay, and less current (approx half)

Some BOD add a watchdog for not much current.

An LVD event will precede a BOD event (LVD - voltage regulator may have an input under-volt comparator)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

djoshi wrote:
I got various PCBs that use AVR Mega and XMega that are being powered using Li-Poly batteries.

We have noticed that even though we have set the brown out to 1.8v , the flash memory is being corrupted on few PCBs.

A cell's ESR will greatly increase near 100% DoD; BOD effectiveness is an issue.

8 - Most Brown-Out Reset Circuits Don't Work | Designing Hardware/Firmware for Low Power MCUs

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Isn't the BOD level related to the clock speed? If you reduce Vcc you limit the max clock speed so if you set 1.8V but then run at a speed that is not viable for 1.81V+ then I guess you may have problems?

 

Off to pull an E5 datasheet and have a look at that graph they usually have that maps the safe operating area between Vcc and speed...

 

EDIT: sorry OP didn't actually say "E5" but anyway...

 

OK so this is the kind of thing I'm talking about. Say you picked to operate at 20MHz but set BOD at 1.8V then the blue cross puts you outside the safe operating area. In fact if you were at 20MHz then I guess you'd have to draw a horizontal line from there and see where you intercept the safe area then set the BOD to that (so it looks like it might be about 2.3V..2.4V in that case):

 

 

So I guess the questions are "what chips?" and "how fast?"

Last Edited: Thu. Sep 12, 2019 - 04:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

djoshi wrote:
Yes there is a boot loader, but its not used, but was kept there to make it full proof. Can this be a problem?

Yes, as only the boot loader can change flash, so improper operation due to low vcc and high speed cpu clock may put you in the bootloader section, and then all bets are off.

So verify in the data sheet, what is the proper BOD level for your cpu speed.

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank You

 

On the Mega i am using 8Mhz

 

And on Xmega it is 11.0592 Mhz.

 

When you say " Yes; if possible, make flash programming conditional (keyed, signed, etc) "

 

Does this simply mean an IF statesmen before the start of the code?

 

 

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

djoshi wrote:
Does this simply mean an IF statesmen before the start of the code?
Yes

A very discharged cell might not have enough capacity to source current for flash programming.

So, if USB VBUS is present then begin flash programming (assumes XMEGA's current source is not only the cell)

 

Keyed - akin to the PDI KEY instruction

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So is it likely that boot loader is causing the flash to be corrupt?

 

 

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes as the SPM instruction can exist only within the bootloader.

When, not if, the NVM controller malfunctioned then the issue is not the bootloader but why the NVM controller terminated without exit (brownout?  over-volt?  EFT?  ESD?  Lightning?  EMI?  etc)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One can never know where a "dying" AVR will enter some code sequence as the power drops away but it *may* help to add some kind of "gate" to your SPM code. 

 

At the very last minute, just before you get to the SPM opcode itself you add some kind of test to do something like checking that TCNT1 contains 0x55AA or whatever (like a "key"). Then in your normal bootloader code you set TCNT1 to that value just before you call the routine that does SPM (and always clear it after). This way, if something "accidentally" falls into the SPM routine then then 55AA gate will not be unlocked so you skip the execution of the SPM. 

 

Of course when it starts to run rogue it could just as easily arrive at the place where you set 55AA and then call the SPM and in that case it will still run OK.

 

But something like this could help.

 

However all this is a bit like papering over the cracks rather than repairing them in the first place!

 

(BTW it doesn't have to be TCNT1 - just use something that is not otherwise used - could be a RAM flag rather than an SFR if you prefer).