mega0/xTiny Full Chip Erase possible from application section?

Log in or register to post comments
Go To Last Post
11 posts / 0 new
Author
Message
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4699 View posts
Location: SF Bay area
#1
Posted by westfw: Thu. Oct 1, 2020 - 09:09 AM
  • 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...

 

 

Tags:

AVR Microcontrollers, AVR and XMEGA
Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 20885 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Thu. Oct 1, 2020 - 09:54 AM
  • 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 oscillator: https://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...
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 100760 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Oct 1, 2020 - 10:18 AM
  • 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 !

Top
digitalDan
digitalDan's picture
Level: Resident
Joined: Sat. Nov 1, 2008
Posts: 580 View posts
Posted by digitalDan: Thu. Oct 1, 2020 - 12:41 PM
  • 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

 

 

 

 

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4699 View posts
Location: SF Bay area
Posted by westfw: Thu. Oct 1, 2020 - 06:36 PM
  • 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.

 

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4699 View posts
Location: SF Bay area
Posted by westfw: Thu. Oct 1, 2020 - 06:38 PM
  • 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.

 

Top
jgmdesign
jgmdesign's picture
Level: Moderator
Joined: Mon. Mar 19, 2007
Posts: 17616 View posts
Location: Long Island New York
Posted by jgmdesign: Thu. Oct 1, 2020 - 07:04 PM
  • 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

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 100760 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Oct 1, 2020 - 08:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
digitalDan
digitalDan's picture
Level: Resident
Joined: Sat. Nov 1, 2008
Posts: 580 View posts
Posted by digitalDan: Thu. Oct 1, 2020 - 09:10 PM
  • 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
Top
curtvm
curtvm's picture
Level: Raving Lunatic
Joined: Wed. Sep 21, 2005
Posts: 3105 View posts
Posted by curtvm: Sat. Oct 10, 2020 - 10:10 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.

 

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4699 View posts
Location: SF Bay area
Posted by westfw: Sat. Oct 10, 2020 - 11:54 PM
  • 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.

 

Top