This commit checks -U update requests for
- Typos in memory names
- Whether the files can be written or read
- Automatic format detection if necessary
before opening the programmer. This to reduce the chances of the
programming failing midway through.
Minor additional changes:
- Give strerror() system info when files are not read/writeable
- Lift the auto detection message from MSG_INFO to MSG_NOTICE
- Provide fileio_fmt_autodetect() in the AVRDUDE library
- Rename fmtstr() in the AVRDUDE library to fileio_fmtstr() to
avoid name clashes when an application links with it
Example:
$ avrdude -U - -U typo:r:.:h -U eeprom:w:testin:r -p ... -c ...
avrdude: can't auto detect file format for stdin/out, specify explicitly
avrdude: unknown memory type typo
avrdude: file . is not writeable (not a regular or character file?)
avrdude: file testin is not readable. No such file or directory
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).
$ 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
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.
For paged read/write early AVRDUDE implementations of the STK500 v1 protocol
communicated a word address (below a_div=2) or byte address (a_div=1) based
on the following code irrespective of which memories were used:
if(m->op[AVR_OP_LOADPAGE_LO] || m->op[AVR_OP_READ_LO])
a_div = 2;
else
a_div = 1;
This turned out to be a bug: it really should have been a_div=2 for flash and
a_div=1 for eeprom. At the time presumably no one noted because Atmel was at
the cusp of replacing their FW 1.x with FW 2 (and the STK500 v2 protocol).
It seems that the world (optiboot, Arduino as ISP, ...) has compensated for
the bug by assuming AVRDUDE sends *all* eeprom addresses as word addresses.
Actually these programmers overcompensated for the bug because for six out of
the 146 known SPI programmable parts with eeprom and page size > 1, AVRDUDE
would still send the eeprom addresses as byte addresses (ATmega8 ATmega8A
ATmega64 ATmega64A ATmega128 ATmega128A) owing to above code.
It makes no sense to correct the bug now seeing that virtually no one uses
the old 2005 STK 500 v1 firmware. This commit now follows optiboot, Arduino
as ISP and other projects, and simply sends all addresses for paged read or
write as word addresses. There are no longer (little known) exceptions for
ATmega8 et al that surprised some optiboot etc users.
The checks used to be in update.c, but as they are related to
the intended file operation, they are better placed in fileio.c.
The checks affected are to refuse 'm' on output (file write),
and 'd', 'h', 'o', and 'b' formats on input (file read).
The file format specifiers 'h', 'd', 'o', and 'b' are only valid for
outputting data. Reject them with a proper error message when
attempting to use them for input.
The function avr_set_addr_mem(AVRMEM *mem, int opnum, unsigned char *cmd,
unsigned long addr) is meant to replace avr_set_addr(OPCODE *op, unsigned
char *cmd, unsigned long addr) in future.
avr_set_addr_mem() has more information about the context of the task in that
it knows the memory size, memory page size, whether or not the memory is a
flash memory (which gets words addressees supplied) and, crucially, knows
which SPI operation it is meant to compute the address bits for.
avr_set_addr_mem() first computes the interval of bit numbers that must be
supplied for the SPI command to stand a chance to work. The function only
sets those address bits that are needed. Once all avr_set_addr() function
calls have been replaced by avr_set_addr_mem(), the SPI commands that need an
address can afford to declare in avrdude.conf all 16 address bits in the
middle two bytes of the SPI command. This over-declaration will be corrected
during runtime by avr_set_addr_mem(). One consequence of this is that parts
can inherit smaller or larger memories from parents without the need to use
different SPI codes in avrdude.conf. Another consequence is that
avr_set_addr_mem() can, and does, tell the caller whether vital address bits
were not declared in the SPI opcode. During parsing of avrdude.conf this
might be utilised to generate a corresponding warning. This will uncover
problematic SPI codes in avrdude.conf that in the past went undetected.
As the address bit numbers in the SPI opcodes are highly systematic, they
don't really need to be specified. Each bit can therefore be described as one
of the characters 0 (always 0), 1 (always 1), x (don't care, but will be set
as 0), a (a copy of the correct bit of the byte or word address of read,
write, load, pagewrite or load extended address command of memories with more
than one byte), i (input bit for a load/write) or o (output bit from a read).
The bits therefore do not need to be individually separated.
If a string in the list of strings that describe an SPI opcode does *not*
contain a space *and* is longer than 7 characters, it is interpreted as a
compact bit-pattern representation. The characters 0, 1, x, a, i and o will
be recognised as the corresponding bit, whilst any of the characters ., -, _
or / can act as arbitrary visual separators, which are ignored. Examples:
loadpage_lo = "0100.0000--000x.xxxx--xxaa.aaaa--iiii.iiii";
loadpage_lo = "0100.0000", "000x.xxxx", "xxaa.aaaa", "iiii.iiii";
loadpage_lo = "0100.0000", "000x.xxxx.xxaa.aaaa", "iiii.iiii";
loadpage_lo = "0100.0000-000x.xxxx--xxaa.aaaa-iiii.iiii";
loadpage_lo = "0100.0000/000x.xxxx/xxaa.aaaa/iiii.iiii";
The compact format is an extension of the current format, which remains
valid. Both, the compact and the traditional specification can be mixed in
different strings, albeit not in the same string:
load_ext_addr = "0100.1101", "0000.0000.0000", "0 0 0 a16", "0000.0000";
Stefan Rueger
MCUdude
Joerg Wunsch