Enable stdin file verification and display correct number of bytes written/verified #1051
Conversation
This file contains 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
…rified
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
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.
Examples:
$ 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>
with 16 bytes in 1 section within [0, 0xf]
using 4 pages and 0 pad bytes
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.
stefanrueger
added
bug
|
Thank you Stefan! I can confirm that #1005 and #1044 is resolved by this PR Without this PR:Arduino sketch with bootloader in the same hex file: Write to EEPROM from stdin: With this PR:Arduino sketch with bootloader in the same hex file: Write to EEPROM from stdin: |
|
Another thing to point out is that previously, a memory with size 0 would be ignored, but now it doesn't continue. This is how the "fake" efuse defined for ATmega8 in avrdude.conf. This trick is currently being used by Arduino IDE. Without this PR: With this PR: |
@MCUdude Great catch! I have relaxed the sanity checks, so memory size zero is OK again File reads are limited to the memory they are destined for, which explains the 0 bytes read (of the immediate file with one byte). |
stefanrueger
changed the title
|
I can confirm that #441 and #1005 are now fixed. |
|
#1044 is also okay now. |
Fix the following build failure without a C++ compiler: CMake Error at CMakeLists.txt:24 (project): No CMAKE_CXX_COMPILER could be found. Tell CMake where to find the compiler by setting either the environment variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
…errors The new file type I is essentially Intel HEX that, on download, inserts comments next to data records with the resolved effective address and an ASCII dump of that same record. On upload the `I` format is permissive with respect to check sum errors, eg, after manipulated an Intel HEX file for debugging.
…on -p \* -p \*/c check address bits in SPI commands -p \*/d description of core part features -p \*/o opcodes for SPI programming parts and memories -p \*/s show avrdude.conf entries of parts -p \*/ss show full avrdude.conf entry as tab separated table -p \*/w wd_... constants for ISP parts -p \*/\* all of the above except -p \*/s -p \* same as -p\*/\*
When an SPI command has a lone 'a' the initialisation now is as would be expected by all commands that take an address. Atmel's opcodes for SPI programming are consistent in this respect. This commit makes specifying the bit number in avrdude.conf optional. Instead of read_lo = "0 0 1 0 0 0 0 0 0 0 a13 a12 a11 a10 a9 a8 a7 a6 a5 a4 a3 a2 a1 a0 o o o o o o o o"; one can now use read_lo = "0 0 1 0 0 0 0 0 0 0 a a a a a a a a a a a a a a o o o o o o o o";
…ndaries 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.
…no as ISP
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.
in order to resolve issue avrdudes#1037
|
@stefanrueger I think something went wrong when updating your fork. You just added 44 commits to this PR, and all of them have already been merged into main. |
|
@MCUdude One of my goals in July was to understand git rebase upstream/main main followed by a local rebase of my branch followed by an elegant git push upstream without using a clickety-dickety web interface ... and I failed (again): git reports diverging branches, refuses to do what I think needs doing and suggests a solution that works but is inelegant: Technically, the PR is still what need doing (I can tell by looking at the changes that this PR effects), but has the disadvantage of a non-linear history (as you spotted redoing commits that already were done). I can abandon this PR and copy over the changed files for a new attempt (OK because I did not have an elaborate commit history for this PR) or we tolerate the non-linear history. Thoughts? I am OK either way. |
|
It's fairly easy to just drop the commits that doesn't belong in this PR.
|
|
@MCUdude Thanks for tips. I can confirm this has worked, and the source stayed the same. git log shows me that I am where I want to be (I think!): a rebased branch with the additions at the end. However, now the branch on my fork is 48 commits ahead, 57 commits behind avrdudes:main. So, it looks like if I was to merge this we'd be at some weird commit history (again). The git guru in my company reckons there is a simple solution: delete my repositories, remove my account, recursively delete my home directory, uninstall the OS, raze my disks, give notice, apply for a new identity, relocate under a witness protection scheme, and start again :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR fixes Issues #1044, #441 and #1005, and should help for 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, minor changes:
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: