mega0/xTiny Full Chip Erase possible from application section?

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

So I've been playing with the nvm controller on mega0 and xTiny chips...

 

Apparently you can use the "Chip Erase" command from application section code, and it will erase the entire chip.  Including any bootloader that is present.

That seems a bit counter-intuitive.  I would have expected the application to be unable to damage the bootloader!

Bug?  Or am I missing some reason that this is intended behavior?

 

Flash Self-Programming test tool

Cmd: dump 0x8000 16
FFFF8000:  01 C0 D6 C0 11 24 80 91 40 00 28 2F 30 E0 83 FD   .⸮⸮⸮.$⸮⸮@.(/0⸮⸮⸮

Cmd: dump fuses
1280:  00 00 02 FF 00 C4 03 00 02 FF C5 FF FF FF 00 06   ...⸮.⸮...⸮⸮⸮⸮⸮..
1290:  3D 2A 54 D4 85 48 A2 64 2D FF 86 46 94 64 F0 22   =*TԅH⸮d-⸮⸮F⸮d⸮"

Cmd: nvmctrl cher

//  It's gone at this point.
// This happens to be a curiosity nano, so I can do:

WWHackintosh<4875> avrdude -pattiny3217 -ccuriositynano_updi -Pusb -Uflash:r:foo.hex:i
   :
avrdude: Device signature = 0x1e9522 (probably t3217)
avrdude: reading flash memory:

Reading | ################################################## | 100% 6.14s

avrdude: Flash is empty, resulting file has no contents.

 

I've duplicated this on an ATtiny3217 (Curiosity Nano) and an ATmega4809 (Arduino Every)

 

https://github.com/Optiboot/opti...

 

 

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

westfw wrote:
 am I missing some reason that this is intended behavior?

self destruct?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
I would have expected the application to be unable to damage the bootloader!
Are you saying this can be done even when the lockbits are set on the bootloader (I assume the chip has this facility?). Surely the idea of separating app from bootloader is specifically for the reason that the boot section can be separately protected. 

 

Of course if a chip erase can wipe the bootloader even when that area is locked that would seem to be a bit of an oversight !

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

My read of the data sheet suggests that the bootloader sets the BOOTLOCK bit in NVMCTRL.CTRLB register if it wants the bootloader section to be protected.  I guess they leave you the option of shooting yourself in the foot if you want.

Letting the smoke out since 1978

 

 

 

 

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

Are you saying this can be done even when the lockbits are set on the bootloader (I assume the chip has this facility?)

Mega0 doesn't seem to have lockbits in the traditional sense.  They're relying on the boot/app/appdata distinction to handle "write" protection, and the BOOTLOCK bit that digitalDan mentions provides read protection of the bootloader section.  Neither of those seems to affect the operation of the "chip erase" command.

 

The datasheet even says:

 

Chip Erase Command

The Chip Erase command erases the Flash and the EEPROM. The EEPROM is unaltered if the EEPROM Save During Chip Erase (EESAVE) fuse in FUSE.SYSCFG0 is set. The Flash will not be protected by Boot Section Lock (BOOTLOCK) or Application Code Section Write Protection (APCWP) in NVMCTRL.CTRLB. The memory will be all 1’s after the operation.

 

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

In the AVR-Dx chips, the "chip erase" nvctrl command is available only from UPDI.  Which is more along the lines of what I expected.

 

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

westfw wrote:
Or am I missing some reason that this is intended behavior?

 

I can see a use for this.

 

Lets say you have a device that needs to 'phone home' at regular intervals.  Each time it phones home if it does not get a connection it can increment a retry counter.  Should the retry counter hit the limit, wipe the chip rendering the device useless.  Sort of a protection of sorts if you are leasing out the gear and they decide not to pay or what have you.

 

It may be an unintentional 'feature' but hey, ya never know

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

DA don't have an HCF opcode then? ;-)

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

westfw wrote:

Are you saying this can be done even when the lockbits are set on the bootloader (I assume the chip has this facility?)

Mega0 doesn't seem to have lockbits in the traditional sense.  They're relying on the boot/app/appdata distinction to handle "write" protection, and the BOOTLOCK bit that digitalDan mentions provides read protection of the bootloader section.  Neither of those seems to affect the operation of the "chip erase" command.

 

The datasheet even says:

 

Chip Erase Command

The Chip Erase command erases the Flash and the EEPROM. The EEPROM is unaltered if the EEPROM Save During Chip Erase (EESAVE) fuse in FUSE.SYSCFG0 is set. The Flash will not be protected by Boot Section Lock (BOOTLOCK) or Application Code Section Write Protection (APCWP) in NVMCTRL.CTRLB. The memory will be all 1’s after the operation.

 

 

So you're saying that you can write to NVMCTRL.CTRLA and issue a CHER to the CMD bits from the application section?  I would've thought that the designers would have employed the same protection mechanism on the CMD bits as they did on BOOTLOCK and APCWP in NVMCTRL.CTRLB.  Strange indeed.  One would think that only the EEPROM capability would be available from the application provided the bootloader set BOOTLOCK and APCWP.

Letting the smoke out since 1978

 

 

 

 

Last Edited: Thu. Oct 1, 2020 - 09:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>Bug?  Or am I missing some reason that this is intended behavior?

 

Looks like a mistake. It would appear this should be the same as the WFU command and should only be accessible from UPDI.  It works in all cases, so would assume they also thought this was only going to be accessible from UPDI. Someone messed up.

 

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

I have a case submitted to Microchip, and it's gotten past the 1st level response, although it may end up as a "well, we can't change that now!" sort of thing.