Multi-memory file handling #1828
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It is crucial not to skip empty flash memory: otherwise the output file cannot distinguish between flash having been deliberately dropped by the user or it having been empty.
... to avoid tears when mistakenly restoring a backup from another part
$ avrdude -c dryrun -p t167 -U all:r:backup.hex:I
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9487 (probably t167)
avrdude: processing -U all:r:backup.hex:r
reading multiple memories ...
eeprom | ################################################## | 100% 0.00s
flash | ################################################## | 100% 0.00s
lfuse | ################################################## | 100% 0.00s
hfuse | ################################################## | 100% 0.00s
efuse | ################################################## | 100% 0.00s
lock | ################################################## | 100% 0.00s
signature | ################################################## | 100% 0.00s
calibration | ################################################## | 100% 0.00s
writing 16904 bytes to output file backup.hex
avrdude done. Thank you.
$ avrdude -c urclock -p m328p -b 115200 -P /dev/ttyUSB0 -U all:v:backup.hex:I
avrdude -c urclock -p m328p -b 115200 -P /dev/ttyUSB0 -U all:v:backup.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: processing -U all:v:backup.hex:i
avrdude: verifying 16904 bytes of multiple memories against input file backup.hex
avrdude error: signature of ATmega328P does not match file (ATtiny167, ATA5505, ATA6617C, ATA664251)
use -F to override this check
avrdude done. Thank you.
$ avrdude -c dryrun -p m328p -U all:w:backup.hex:I -F
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: processing -U all:w:backup.hex:I
avrdude: reading 16904 bytes for multiple memories from input file backup.hex
avrdude: 512 bytes eeprom in 1 section [0, 0x1ff]: 128 pages and 0 pad bytes
writing 512 bytes to eeprom ...
writing | ################################################## | 100% 0.00s
reading | ################################################## | 100% 0.00s
512 bytes of eeprom verified
avrdude: 16384 bytes flash in 1 section [0, 0x3fff]: 128 pages and 0 pad bytes
writing 16384 bytes to flash ...
writing | ################################################## | 100% 0.00s
reading | ################################################## | 100% 0.00s
16384 bytes of flash verified
avrdude: 1 byte lfuse in 1 section [0, 0]
writing 1 byte to lfuse (0x62), 1 byte written, 1 verified
avrdude: 1 byte hfuse in 1 section [0, 0]
writing 1 byte to hfuse (0xdf), 1 byte written, 1 verified
avrdude: 1 byte efuse in 1 section [0, 0]
writing 1 byte to efuse (0xff), 1 byte written, 1 verified
avrdude: 1 byte lock in 1 section [0, 0]
writing 1 byte to lock (0xff), 1 byte written, 1 verified
avrdude done. Thank you.
Collaborator
|
Nice feature. |
Collaborator
|
I like the "ALL" option as well. |
Collaborator
|
@stefanrueger |
Collaborator
|
Here is the output when writing a multimem file to the ATmega4809, when specifying the fuses in the program itself, like so. It took me a while to figure out how the struct should look like, due to the reserved memories in there, so we should mention this in the docs. FUSES =
{
0x01, // WDTCFG
0x02, // BODCFG
0x03, // OSCCFG
0xFF,
0xFF,
0x06, // SYSCFG0
0x07, // SYSCFG1
0x08, // APPEND
0x09, // BOOTEND
};Is it necessary to mention all the memories the file didn't contain, with the full filename and everything? The hex file was compiled using Arduino IDE, and I feel the output is a bit verbose. How about something like this? Way less text, but no critical information have been left out |
/mem has the meaning of ALL\mem in set theory, which could cause confusion.
Collaborator
Author
|
@MCUdude @dl8dtl @mcuee Thanks all round for tests and comments.
I have had second thoughts.
Correct. The signature check is triggered by the presence of a signature in the file, and not by the presence of the I have, however, written a function
Sure, the full pathname is not needed. I have reduced that now to the filename component of the path. I feel that AVRDUDE should warn whenever the file didn't contain requested memories: in the example the user explicitly asked for ALL memories to be set/checked, so they should receive a warning if something they asked for is not available. The user can reduce the warnings by only specifying what's in the file, eg, Let me know if I have missed some of the comments and/or any problems where this PR breaks something. And, yes, once this PR is settled, I will (as always) contribute documentation. It would be great if @MCUdude could contribute examples how to generate multi-memory |
Collaborator
|
The commit looks good! Tested with ATmega324A/P/PA.It only compares devices that are truly SW compatible. So even though a hex file compiled for the ATmega88 will work on the ATmega168, they aren't back to back compatible, and will fail the test.
Thanks! The output looks suddenly much better. And a warning is fine by me.
Sure! I can provide examples for classic AVRs and AVRs with UPDI. Embedding the fuses is pretty straight forward, but I haven't figured out how/if it's possible to embed EEPROM content as well. |
AVRDUDE will happily generate all sorts of file formats from multiple memories, but only understands hex, srec and elf files.
Collaborator
Author
|
@MCUdude Thanks for checking
Yes, this is deliberate. For example, if an application for the ATmega88 makes use of the urclock metadata and urboot I have in the meantime found (and fixed) an error: AVRDUDE erases the chip automatically if one of the Also added documentation. Would like to merge soon, unless there are further comments. We can still put examples how to generate multi-memory .hex files by compiling sketches into the documentation later on. Generally, to generate multi-memory files for distribution I recommend to carefully prepare everything in a chip as it should be and then use |
Collaborator
Author
Some dryrun testsSome real tests |
Collaborator
|
@stefanrueger you mentioned that you wanted to include a few Arduino examples on how the fuses could be added to the the docs. Arduino sketch for ATmega4809 to store fuses in the output hex file: #include <avr/fuse.h>
FUSES = {
0x00, // WDTCFG
0x00, // BODCFG
0x7E, // OSCCFG
0xFF, // Reserved
0xFF, // Reserved
0xF6, // SYSCFG0
0xFF, // SYSCFG1
0x00, // APPEND
0x00, // BOOTEND
};
void setup() {
}
void loop() {
}Arduino sketch for ATmega328P to store fuses in the output hex file: #include <avr/fuse.h>
FUSES = {
0x62, // LFUSE
0xD9, // HFUSE
0xFF, // EFUSE
};
void setup() {
}
void loop() {
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1817
This PR handles r/w/v of multi-memory files that use a flat address space (as in .elf). Apparently Microchip use these
New functionality includes
flash,ee,fusesfrom multi-memory filesallas an abbreviation for a list of all memories except submemoriesALLas an abbreviation for a list of all memories a part hasetcas the same asall: can usesig,etcwhich putssignaturefirst in list (looks nicer thansig,all)\(without) operator as inall\bootrow-U [all | <list> | <list>\<list>]:w:file.hex:i-U [<list>|all]:v:...allmemories to write a multi-memory file as backupbackup <memlist> <file>[:format]restore <memlist> <file>[:format]verify <memlist> <file>[:format]In order to be able to test the new functionality, this PR also provides options
-xinitfor the dryrun programmer.That is kinda fun, particularly, when you view the generated outputs using the
:Iformat (.hex with comments). TrySo, feel free to do your worst to try to break the new, rewritten, update mechanism.