Enable stdin verification and display correct number of bytes written/verified #1053

stefanrueger · 2022-08-02T23:47:19Z

(This is a recreated PR #1051 owing to a rebase gone astray.)
This PR fixes Issues #1044, #441 and #1005, and solves PR #1036

Counting the number of bytes written to a memory and/or verified is not trivial owing to potential holes in the input file and to potential trailing 0xff bytes in flash memory that are not written per default (but see -A). The new function memstats(), which is best called just after an input file has been read into mem->buf/mem->tags, computes the right number of bytes written and allows easy computation of the number of bytes verified.

This PR also changes the strategy for the default verification after writing to a chip memory, so that the input file only needs reading once thus enabling successful verification of stdin input files.

Other changes:

Exits during parsing of command line if a -U memory is unknown for all parts
Skips -U updates if memory is unknown for this part
Improving the grammar of AVRDUDE output, eg, 1 byte written instead of 1 bytes written
Better description of the input file structure in terms of its sections, the interval it spans, the number of pages, the number of padding bytes in pages, and the number of actually cut off trailing 0xff bytes for flash
Printing <stdin> or <stdout> instead of - in the update routines
Option -V no longer needs to be specified before option -U in order to work

As an aside this PR also provides useful helper functions for printing plural(), inname(), outname() and interval() all of which return strings fit for printing.

Examples using blink-mega2560+lext-test.hex and sketch-ending-in-ff.hex:

$ avrdude -qp ATmega2560 -c ... -U blink-mega2560+lext-test.hex

avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e9801 (probably m2560)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: input file blink-mega2560+lext-test.hex auto detected as Intel Hex
avrdude: reading input file blink-mega2560+lext-test.hex
         with 1346 bytes in 4 sections within [0, 0x3106d]
         using 7 pages and 446 pad bytes
avrdude: writing 1346 bytes flash ...
avrdude: 1346 bytes of flash written
avrdude: verifying flash memory against blink-mega2560+lext-test.hex
avrdude: 1346 bytes of flash verified

avrdude done.  Thank you.

$ avrdude -qp ATmega328P -c ... -U sketch-ending-in-ff.hex

avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: input file sketch-ending-in-ff.hex auto detected as Intel Hex
avrdude: reading input file sketch-ending-in-ff.hex
         with 2160 bytes in 1 section within [0, 0x888]
         using 17 pages and 16 pad bytes, cutting off 25 trailing 0xff bytes
avrdude: writing 2160 bytes flash ...
avrdude: 2160 bytes of flash written
avrdude: verifying flash memory against sketch-ending-in-ff.hex
avrdude: 2185 bytes of flash verified

avrdude done.  Thank you.

$ echo "Hello, world..." | avrdude -qp ATmega328P -c ... -U eeprom:w:-:r

avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: reading input file <stdin>
avrdude: writing 16 bytes eeprom ...
avrdude: 16 bytes of eeprom written
avrdude: verifying eeprom memory against <stdin>
avrdude: 16 bytes of eeprom verified

avrdude done.  Thank you.

…/verified Counting the number of bytes written to a memory and/or verified is not trivial owing to potential holes in the input file and to potential trailing 0xff bytes in flash memory that are not written per default (but see -A). The new function memstats(), which is best called just after an input file has been read into mem->buf/mem->tags, computes the right number of bytes written and allows easy computation of the number of bytes verified. This commit also changes the strategy for the default verification after writing to a chip memory, so that the input file only needs reading once thus enabling successful verification of stdin input files. Other, minor changes: - Improving the grammar of AVRDUDE output, eg, 1 byte written instead of 1 bytes written - Better description of the input file structure in terms of its sections, the interval it spans, the number of pages, the number of padding bytes in pages, and the number of actually cut off trailing 0xff bytes for flash - Printing <stdin> or <stdout> instead of - in the -U routines - Option -V no longer needs to be specified before option -U in order to work As an aside this commit also provides useful helper functions for printing plural(), inname(), outname() and interval() all of which return strings fit for printing. $ avrdude -qp ATmega2560 -c usbtiny -U blink-mega2560+lext-test.hex avrdude: AVR device initialized and ready to accept instructions avrdude: Device signature = 0x1e9801 (probably m2560) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: input file blink-mega2560+lext-test.hex auto detected as Intel Hex avrdude: reading input file blink-mega2560+lext-test.hex for flash with 1346 bytes in 4 sections within [0, 0x3106d] using 7 pages and 446 pad bytes avrdude: writing 1346 bytes flash ... avrdude: 1346 bytes of flash written avrdude: verifying flash memory against blink-mega2560+lext-test.hex avrdude: 1346 bytes of flash verified avrdude done. Thank you. $ avrdude -qp ATmega328P -c usb-bub-ii -U sketch-ending-in-ff.hex avrdude: AVR device initialized and ready to accept instructions avrdude: Device signature = 0x1e950f (probably m328p) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: input file sketch-ending-in-ff.hex auto detected as Intel Hex avrdude: reading input file sketch-ending-in-ff.hex for flash with 2160 bytes in 1 section within [0, 0x888] using 17 pages and 16 pad bytes, cutting off 25 trailing 0xff bytes avrdude: writing 2160 bytes flash ... avrdude: 2160 bytes of flash written avrdude: verifying flash memory against sketch-ending-in-ff.hex avrdude: 2185 bytes of flash verified avrdude done. Thank you. $ echo "Hello, world..." | avrdude -qp ATmega328P -c ... -U eeprom:w:-:r avrdude: AVR device initialized and ready to accept instructions avrdude: Device signature = 0x1e950f (probably m328p) avrdude: reading input file <stdin> for eeprom avrdude: writing 16 bytes eeprom ... avrdude: 16 bytes of eeprom written avrdude: verifying eeprom memory against <stdin> avrdude: 16 bytes of eeprom verified avrdude done. Thank you.

$ avrdude -qp ATmega2560 -c usbtiny -U flesh:w:blink-mega2560+lext-test.hex:i avrdude: unknown memory type flesh avrdude: error parsing update operation 'flesh:w:blink-mega2560+lext-test.hex:i'

$ avrdude -qp m8 -c ... -U efuse:w:0xff:m && echo OK avrdude: AVR device initialized and ready to accept instructions avrdude: skipping -U efuse:... as memory not defined for part ATmega8 avrdude done. Thank you. OK

MCUdude · 2022-08-03T08:58:33Z

Thanks for bringing #1036 into this PR!

However, It doesn't continue when an invalid memory is specified:

$ ./avrdude -cusbasp -patmega328p -Uinvalidfuse:w:0x00:m -Uefuse:w:0xfd:m
avrdude: unknown memory type invalidfuse
avrdude: error parsing update operation 'invalidfuse:w:0x00:m'

mcuee · 2022-08-03T09:04:59Z

I remember the closed PR #1051 only helps but not replace #1036.

Enable stdin file verification and display correct number of bytes written/verified #1051 (comment)

This PR fixes Issues #1044, #441 and #1005, and should help for PR #1036.

Ignore target memories not present in avrdude.conf #1036 (comment)

stefanrueger · 2022-08-03T11:28:55Z

This PR is permissive for known memories that do not exist in this part, eg, efuse on the ATmega8:

$ avrdude -qp m8 -c ... -U eeprom:w:0xc0,0xde:m -U efuse:w:0xff:m -U lock:r:-:h && echo OK

avrdude: AVR device initialized and ready to accept instructions
avrdude: reading input file 0xc0 for eeprom
avrdude: writing 2 bytes eeprom ...
avrdude: 2 bytes of eeprom written
avrdude: verifying eeprom memory against 0xc0
avrdude: 2 bytes of eeprom verified
avrdude: skipping -U efuse:... as memory not defined for part ATmega8
avrdude: reading lock memory ...
avrdude: writing output file <stdout>
0xff

avrdude done.  Thank you.

OK

Notice the skipping -U efuse:... message and the "OK" exit value evidenced by && echo OK.

However, this PR also detects typos in memories at parse time and rejects the whole command if so. A typo is a memory that does not exist in any of the parts in avrdude.conf or the private ~/.avrdude.conf. For example, flesh instead of flash:

$ avrdude -qp ATmega2560 -c usbtiny -U lock:w:0xff:m -U flesh:w:blink-mega2560+lext-test.hex:i  -U lock:w:0xc0:m
avrdude: unknown memory type flesh
avrdude: error parsing update operation 'flesh:w:blink-mega2560+lext-test.hex:i'

I could not think of a good use case for being permissive for typos in memories (whilst I accept there are good use cases for allowing sth like efuse for the ATmega8). Actullay, while I think of it, -U parsing should also check before connecting to the device whether input files (other than stdin) are readable or output files (other than stdout) are writeable. It can take minutes to download a copy of ATmega2560 flash and it's a bit of a downer to be told then that AVRDUDE cannot write to the output file (permissions, mistyped directory name, etc). But that's for another day...

mcuee · 2022-08-03T11:36:44Z

@stefanrueger

I see that now PR #1036 has been incorporated into this new PR.

I could not think of a good use case for being permissive for typos in memories (whilst I accept there are good use cases for allowing sth like efuse for the ATmega8).

I will agree with this.

Actullay, while I think of it, -U parsing should also check before connecting to the device whether input files (other than stdin) are readable or output files (other than stdout) are writeable. It can take minutes to download a copy of ATmega2560 flash and it's a bit of a downer to be told then that AVRDUDE cannot write to the output file (permissions, mistyped directory name, etc). But that's for another day...

That seems to be a good enhancement idea. Thanks.

Testing results are good (to see if it can replace #1036 or not).

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1053.exe -c avrispmkii -p m16a -U efuse:r:-:h 
-U lfuse:r:-:h -U hfuse:r:-:h

avrdude_pr1053.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude_pr1053.exe: Device signature = 0x1e9403 (probably m16a)
avrdude_pr1053.exe: skipping -U efuse:... as memory not defined for part ATmega16A
avrdude_pr1053.exe: reading lfuse memory ...

Reading | ################################################## | 100% 0.00s

avrdude_pr1053.exe: writing output file <stdout>
0xff
avrdude_pr1053.exe: reading hfuse memory ...

Reading | ################################################## | 100% 0.00s

avrdude_pr1053.exe: writing output file <stdout>
0x9

avrdude_pr1053.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1051.exe -c avrispmkii -p m16a 
-U efuse:r:-:h -U lfuse:r:-:h -U hfuse:r:-:h

avrdude_pr1051.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude_pr1051.exe: Device signature = 0x1e9403 (probably m16a)
efuse memory type not defined for part ATmega16A

avrdude_pr1051.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1036.exe -c avrispmkii -p m16a
 -U efuse:r:-:h -U lfuse:r:-:h -U hfuse:r:-:h

avrdude_pr1036.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude_pr1036.exe: Device signature = 0x1e9403 (probably m16a)
avrdude_pr1036.exe: warning: "efuse" memory type not defined for part "ATmega16A"

avrdude_pr1036.exe: reading lfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude_pr1036.exe: writing output file "<stdout>"
0xff
avrdude_pr1036.exe: reading hfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude_pr1036.exe: writing output file "<stdout>"
0x9

avrdude_pr1036.exe done.  Thank you.

MCUdude · 2022-08-03T12:56:52Z

This PR is permissive for known memories that do not exist in this part, eg, efuse on the ATmega8:

Great, I didn't realize that. However, it looks like the way this is implemented, Avrdude can't support memories with other names that specified in the avr_mem_order array.

const char *avr_mem_order[100] = {
   "eeprom",       "flash",        "application",  "apptable",
   "boot",         "lfuse",        "hfuse",        "efuse",
   "fuse",         "fuse0",        "wdtcfg",       "fuse1",
   "bodcfg",       "fuse2",        "osccfg",       "fuse3",
   "fuse4",        "tcd0cfg",      "fuse5",        "syscfg0",
   "fuse6",        "syscfg1",      "fuse7",        "append",
   "codesize",     "fuse8",        "fuse9",        "bootend",
   "bootsize",     "fuses",        "lock",         "lockbits",
   "tempsense",    "signature",    "prodsig",      "sernum",
   "calibration",  "osccal16",     "osccal20",     "osc16err",
   "osc20err",     "usersig",      "userrow",      "data",
 };

As a test, I added this "new" fuse to the ATmega8 entry in avrdude.conf to see how it would handle new names. It's identical to lfuse, but it only has a different name.

    memory "lfuse"
        size            = 1;
        min_write_delay = 2000;
        max_write_delay = 2000;
        read            = "0 1 0 1  0 0 0 0   0 0 0 0  0 0 0 0",
                          "x x x x  x x x x   o o o o  o o o o";

        write           = "1 0 1 0  1 1 0 0   1 0 1 0  0 0 0 0",
                          "x x x x  x x x x   i i i i  i i i i";
      ;

    memory "fakefuse"
        size            = 1;
        min_write_delay = 2000;
        max_write_delay = 2000;
        read            = "0 1 0 1  0 0 0 0   0 0 0 0  0 0 0 0",
                          "x x x x  x x x x   o o o o  o o o o";

        write           = "1 0 1 0  1 1 0 0   1 0 1 0  0 0 0 0",
                          "x x x x  x x x x   i i i i  i i i i";
      ;

$ ./avrdude -cusbasp -patmega8 -Ufakefuse:w:0xff:m -Ulfuse:w:0xff:m
avrdude: unknown memory type fakefuse
avrdude: error parsing update operation 'fakefuse:w:0xff:m'

Shouldn't Avrdude be able to accept memories that's present in avrdude.conf?

stefanrueger · 2022-08-03T14:33:08Z

Shouldn't Avrdude be able to accept memories that's present in avrdude.conf?

Yes, it should and (against my expectation) it doesn't. The reason is that avr_add_mem_order() adds to that list memories encountered during avrdude.conf etc parsing, but parsing of -U happens before parsing of avrdude.conf. Duh! Great job you checked, @MCUdude

I will move the check of -U memory strings further down in the code.

MCUdude · 2022-08-03T16:25:42Z

Another detail that this PR "breaks" is the way you can use only part of a memorable name. AFAIK this is undocumented behavior, but I stumbled across this "feature" when working on memory name aliases. I don't think this will cause any issues.

However, this "feature" prevented us from adding a memory name that was a substring of another name.
For ATmega4809, this meant that error memory osc16err could not be named osccal16err like I would prefer, since osccal16 was already present.

Without this PR:

$ ./avrdude -cusbasp -patmega8 -Ulf:w:0xff:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9307 (probably m8)
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:

Reading | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse verified

avrdude done.  Thank you.

With this PR:

$ ./avrdude -cusbasp -patmega8 -Ulf:w:0xff:m
avrdude: unknown memory type lf
avrdude: error parsing update operation 'lf:w:0xff:m'

The check for typos in -U memory names against a list of known memory names now happens after the config files have been read, so newly declared memory names can be considered. This commit also weakens the check against existence of a known memory: it is now sufficent for a name to pass when it could be the initial string of any known memory of any part. Any -U memory that cannot possibly be matched up with a known memory is considered a typo and leads to an exit before the programmer is opened. This to protect users from typos that leave a device partially programmed. When every -U memory name might be matching one of the known memories, the programming is attempted. If the part to be programmed turns out not to have a particular -U memory, AVRDUDE warns the user and skips this -U update. This to support unifying interfaces that call AVRDUDE with potentially more memories than the actual part has (eg, efuse on ATmega8).

stefanrueger · 2022-08-03T23:54:03Z

you can use only [the initial] part of a memorable name

Thanks, @MCUdude, important insight and easy to fix: I replaced strcmp(memname, str) with strncmp(memname, str, strlen(str)); for good measure I renamed the function from avr_mem_is_known() to avr_mem_might_be_known() as this weakens the typo-detection. I find it important to keep continuity, even of undocumented features, particularly when they are useful (less typing :).

I also moved the typo check to after the config files have been read, so new memory names are actually considered.

BTW, rwcheck.c is a draft for whether a given filename might be readable or writeable. This to check all -U filenames before opening the programmer. I fear it won't work in Windows but should under MacOS as all functions are POSIX compliant (I think). I assume we could still use this in an #if !defined(WIN32) branch?

mcuee · 2022-08-04T00:20:25Z

BTW, rwcheck.c is a draft for whether a given filename might be readable or writeable. This to check all -U filenames before opening the programmer. I fear it won't work in Windows but should under MacOS as all functions are POSIX compliant (I think). I assume we could still use this in an #if !defined(WIN32) branch?

@stefanrueger
It works without issues under Windows if using MinGW. I am not so sure about msvc but I think it is not difficult to get it work under MSVC either.

$ gcc -o rwcheck rwcheck.c

$ ./rwcheck.exe rwcheck.c
rwcheck.c readable
rwcheck.c writeable

$ ./rwcheck.exe noname.hex
noname.hex not readable
noname.hex writeable

mcuee · 2022-08-04T00:43:29Z

The latest version seems to be fine now with PR #1036.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1053v2.exe -c usbasp -p m16a 
-U ef:r:-:h  -U lf:r:-:h -U hf:r:-:h

avrdude_pr1053v2.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude_pr1053v2.exe: Device signature = 0x1e9403 (probably m16a)
avrdude_pr1053v2.exe: skipping -U ef:... as memory not defined for part ATmega16A
avrdude_pr1053v2.exe: reading lfuse memory ...

Reading | ################################################## | 100% 0.00s

avrdude_pr1053v2.exe: writing output file <stdout>
0xbf
avrdude_pr1053v2.exe: reading hfuse memory ...

Reading | ################################################## | 100% 0.00s

avrdude_pr1053v2.exe: writing output file <stdout>
0x4

avrdude_pr1053v2.exe done.  Thank you.

mcuee · 2022-08-04T07:56:05Z

@MCUdude Thanks. I did not know that avrdude got so many memory types.

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1053v2.exe -c usbasp -p m2560 
-U lf:r:-:h -U hf:r:-:h -U ef:r:-:h -U lock:r:-:h -U calibration:r:-:h
 -U signature:r:-:h -U tempsense:r:-:h

avrdude_pr1053v2.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude_pr1053v2.exe: Device signature = 0x1e9801 (probably m2560)
avrdude_pr1053v2.exe: reading lfuse memory ...

Reading | ################################################## | 100% 0.00s

avrdude_pr1053v2.exe: writing output file <stdout>
0xf7
avrdude_pr1053v2.exe: reading hfuse memory ...

Reading | ################################################## | 100% 0.00s

avrdude_pr1053v2.exe: writing output file <stdout>
0xd6
avrdude_pr1053v2.exe: reading efuse memory ...

Reading | ################################################## | 100% 0.00s

avrdude_pr1053v2.exe: writing output file <stdout>
0xfd
avrdude_pr1053v2.exe: reading lock memory ...

Reading | ################################################## | 100% 0.00s

avrdude_pr1053v2.exe: writing output file <stdout>
0xff
avrdude_pr1053v2.exe: reading calibration memory ...

Reading | ################################################## | 100% 0.00s

avrdude_pr1053v2.exe: writing output file <stdout>
0xbc
avrdude_pr1053v2.exe: reading signature memory ...

Reading | ################################################## | 100% 0.01s

avrdude_pr1053v2.exe: writing output file <stdout>
0x1e,0x98,0x1
avrdude_pr1053v2.exe: skipping -U tempsense:... as memory not defined for part ATmega2560

avrdude_pr1053v2.exe done.  Thank you.

MCUdude · 2022-08-04T11:49:00Z

Thanks @stefanrueger! Now the PR works well with initial names like hfand ef too. And as you can see in the Avrdude output below, #981 has been elegantly resolved.

$ ./avrdude -cusbasp -patmega8 -Ulf:r:-:h -Utempsense:r:-:h -Uhfuse:r:-:h -Uef:w:0xff:m -Ulock:r:-:h -Ucal:r:-:h -Usignature:r:-:h

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9307 (probably m8)
avrdude: reading lfuse memory ...

Reading | ################################################## | 100% 0.00s

avrdude: writing output file <stdout>
0xff
avrdude: skipping -U tempsense:... as memory not defined for part ATmega8
avrdude: reading hfuse memory ...

Reading | ################################################## | 100% 0.00s

avrdude: writing output file <stdout>
0xc2
avrdude: skipping -U ef:... as memory not defined for part ATmega8
avrdude: reading lock memory ...

Reading | ################################################## | 100% 0.00s

avrdude: writing output file <stdout>
0xff
avrdude: reading calibration memory ...

Reading | ################################################## | 100% 0.00s

avrdude: writing output file <stdout>
0xc3,0xc2,0xbc,0xbc
avrdude: reading signature memory ...

Reading | ################################################## | 100% 0.00s

avrdude: writing output file <stdout>
0x1e,0x93,0x7

avrdude done.  Thank you.

stefanrueger · 2022-08-04T16:58:50Z

OK, thanks for thorough testing and for commenting, @MCUdude and @mcuee. I have now merged this PR.

stefanrueger · 2022-08-12T14:05:13Z

@MCUdude

However, [matching initial strings for memories] prevented us from adding a memory name that was a substring of another name. For ATmega4809, this meant that error memory osc16err could not be named osccal16err like I would prefer, since osccal16 was already present.

It is possible to make AVRDUDE accept a memory name (eg, oscal16) as the correct one even if a longer memory name with the same start exists (eg, oscal16err). The three avr_alias_mem*() functions would need a subtle change. For example, in

avrdude/src/avrpart.c

Lines 562 to 565 in 5f5002e

    
           if (strncmp(desc, m->desc, l) == 0) { 
        
             match = m; 
        
             matches++; 
        
           }

I would insert the lines

      if(m->desc[l] == 0)  {                   // Complete match with this memory
        matches = 1;
        break;
     }

after match = m. In the example, oscal16 would match (because there is a memory that's exactly so named), but oscal1 would not (as it's ambiguous). oscal16e would then again match (assuming oscal16err is the only memory starting with oscal16e. Could also use "if(strcmp(m->desc, desc) == 0) in the modification, which is easier to read but redundant b/c the desc-len first characters have already been checked by strncmp().

In other words, specifying the full memory name would always be fine (no matter how the others are called), but in absence of that any shorter unique start is also accepted.

MCUdude · 2022-08-13T17:19:56Z

It is possible to make AVRDUDE accept a memory name (eg, oscal16) as the correct one even if a longer memory name with the same start exists (eg, oscal16err)

IMO, this would definitely be the best option. This lets us name memories as we want, and not have to deal with Avrdude's naming quirks.

stefanrueger added 4 commits August 2, 2022 23:26

Add ordered list of known memories to avr.c with access functions

42c8169

Check -U option for unknown memories during parsing

9604a3e

$ avrdude -qp ATmega2560 -c usbtiny -U flesh:w:blink-mega2560+lext-test.hex:i avrdude: unknown memory type flesh avrdude: error parsing update operation 'flesh:w:blink-mega2560+lext-test.hex:i'

Ignore target memories not present in part

648f331

$ avrdude -qp m8 -c ... -U efuse:w:0xff:m && echo OK avrdude: AVR device initialized and ready to accept instructions avrdude: skipping -U efuse:... as memory not defined for part ATmega8 avrdude done. Thank you. OK

stefanrueger added bug Something isn't working enhancement New feature or request labels Aug 2, 2022

MCUdude mentioned this pull request Aug 3, 2022

Ignore target memories not present in avrdude.conf #1036

Closed

stefanrueger merged commit 5f01d90 into avrdudes:main Aug 4, 2022

This was referenced Aug 4, 2022

Automatic verification is designed to fail for stdin #1044

Closed

[bug #50087] option parse error: after -U flash:w:program_to_upload.hex, subsequent -V ignored #441

Closed

Wrong number of bytes displayed when input file has holes #1005

Closed

umbynos mentioned this pull request Aug 5, 2022

Added fake EFUSE to atmega8 part. #981

Closed

umbynos added a commit to arduino/avrdude-packing that referenced this pull request Aug 5, 2022

superseded by avrdudes/avrdude#1053

f866732

umbynos mentioned this pull request Aug 5, 2022

remove patch 0001 arduino/avrdude-packing#16

Merged

mcuee mentioned this pull request Aug 17, 2022

Upload to Uno WiFi Rev2 fails on fuse5 verification when using AVRDUDE 7.0 arduino/ArduinoCore-megaavr#119

Open

umbynos added a commit to arduino/avrdude-packing that referenced this pull request Nov 2, 2022

superseded by avrdudes/avrdude#1053

4bdec89

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enable stdin verification and display correct number of bytes written/verified #1053

Enable stdin verification and display correct number of bytes written/verified #1053

stefanrueger commented Aug 2, 2022 •

edited

Loading

MCUdude commented Aug 3, 2022

mcuee commented Aug 3, 2022 •

edited

Loading

stefanrueger commented Aug 3, 2022

mcuee commented Aug 3, 2022 •

edited

Loading

MCUdude commented Aug 3, 2022

stefanrueger commented Aug 3, 2022

MCUdude commented Aug 3, 2022

stefanrueger commented Aug 3, 2022

mcuee commented Aug 4, 2022 •

edited

Loading

mcuee commented Aug 4, 2022 •

edited

Loading

mcuee commented Aug 4, 2022 •

edited

Loading

MCUdude commented Aug 4, 2022

stefanrueger commented Aug 4, 2022

stefanrueger commented Aug 12, 2022

MCUdude commented Aug 13, 2022

Enable stdin verification and display correct number of bytes written/verified #1053

Enable stdin verification and display correct number of bytes written/verified #1053

Conversation

stefanrueger commented Aug 2, 2022 • edited Loading

MCUdude commented Aug 3, 2022

mcuee commented Aug 3, 2022 • edited Loading

stefanrueger commented Aug 3, 2022

mcuee commented Aug 3, 2022 • edited Loading

MCUdude commented Aug 3, 2022

stefanrueger commented Aug 3, 2022

MCUdude commented Aug 3, 2022

stefanrueger commented Aug 3, 2022

mcuee commented Aug 4, 2022 • edited Loading

mcuee commented Aug 4, 2022 • edited Loading

mcuee commented Aug 4, 2022 • edited Loading

MCUdude commented Aug 4, 2022

stefanrueger commented Aug 4, 2022

stefanrueger commented Aug 12, 2022

MCUdude commented Aug 13, 2022

stefanrueger commented Aug 2, 2022 •

edited

Loading

mcuee commented Aug 3, 2022 •

edited

Loading

mcuee commented Aug 3, 2022 •

edited

Loading

mcuee commented Aug 4, 2022 •

edited

Loading

mcuee commented Aug 4, 2022 •

edited

Loading

mcuee commented Aug 4, 2022 •

edited

Loading