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";
This commit changes the philosophy whenever avrdude.conf encounters the
same memory of a part for the second time or whenever a memory is
described that, through inheritance, already existed: AVRDUDE no longer
zaps the memory, it rather extends it.
Therefore, avrdude.conf.in's entry for ATmega128RFA1, which inherits from
the ATmega2561, needs a line `load_ext_addr = NULL;` in its flash memory
description to zap the inherited load_ext_addr SPI command.
Other than this, avrdude.conf.in needs no other change in order to effect
the same internal representation proving earlier updates to the .conf.in
file correct that manually ensured inheritance of memory contents.
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";
Some 90% of the space of AVRPART and some 50% of PROGRAMMER is occupied by a
4 kB array config_file[] that contains the configuration file name. In
preparation of developer options that output a raw dump of the part
descriptions, this commit changes the config_file components from a large
array, which is duplicated in each part and programmer description, to a
cached string for each config file allowing for smaller raw dumps.
This commit also changes the config file name to its realpath(), eg, shortens
unwarranted `/bin/../etc/` file name components. It also changes the global
variable names `infile` and `fileno` to cfg_infile and cfg_fileno for an ever
so slight improvement of code clarity.
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.
Usbtiny has a protocol or firmware problem that prevents it from reading
flash above 64 kB in page mode (used by -U flash:r:... and -U flash✌️...).
This commit fixes that problem by falling back on byte access for flash paged
reads above 64k. It also issues the correct load extended address command for
parts with more than 128 kB flash thus extending support to ATmega2560 et al.
Some C libraries assign true to isalpha(0xff), isdigit(0xff) or
ispunct(0xff), which means that the Operating System terminal sees a
character 0xff which it may not have a useful display character for.
This commit only outputs printable ASCII characters for an AVRDUDE
terminal dump reducing the risk of the OS terminal not being able
to print the character properly.
Error messages are written to stderr whilst normal terminal output is stdout.
When redirecting output to pipelines or files these two streams can get
separated as they are buffered separately. To avoid this, term.c now provides
a function terminal_message() that works just like avrdude_message() but
flushes stderr and stdout before printing on stderr, and it flushes stderr
afterwards.
This commit replaces all avrdude_message() calls except for progress report
with terminal_message() to ensure stdout and stderr streams keep together.
This enables the new quell terminal command to switch on and off progress
reports to the terminal. The code for this was moved from main.c to term.c.
It can be used as library call for other frontends than main.c
Sets the quell_progress global variable that can be, and is, consulted by
programmers.
Setting quell_progress to a positive number also switches off progress
bars. It is currently not possible to switch on progress bars again: that
is enabled in main.c once at the start of AVRDUDE.
That code in main should move to avr.c to enable report_update() to consult
quell_progress directly. Will do at another time when touching main.c and
avr.c. smr
The code no longer accepts valid mantissa-only doubles that are integer
rejects, eg, 078 or ULL overflows. These are most likely input errors by
the user: 8 is not an octal digit, they might have typed 17 hex digits,
not 16. It's just too hard to explain that 0xffffFFFFffffFFFFf writes
0x4430000000000000, which is the correct double representation of the
valid 17-digit hex mantissa that strtod() is perfectly happy to accept.
Integers can be hexadecimal, decimal or octal. An optional case-insensitive
suffix specifies their size: HH: 8 bit, H/S: 16 bit, L: 32 bit, LL: 64 bit
An optional U suffix makes a number unsigned. Ordinary 0x hex numbers are
always treated as unsigned. +0x or -0x hex numbers are treated as signed
unless they have a U suffix. Unsigned integers cannot be larger than 2^64-1.
If n is an unsigned integer then -n is also a valid unsigned integer as in C.
Signed integers must fall into the [-2^63, 2^63-1] range or a correspondingly
smaller range when a suffix specifies a smaller type. Out of range signed
numbers trigger a warning.
Ordinary 0x hex numbers with n hex digits (counting leading zeros) use
the smallest size of 1, 2, 4 and 8 bytes that can accommodate any n-digit hex
number. If a suffix specifies a size explicitly the corresponding number of
least significant bytes are written. Otherwise, signed and unsigned integers
alike occupy the smallest of 1, 2, 4, or 8 bytes needed to accommodate them
in their respective representation.
Using strtoll() can only return numbers in the range [-2^63, 2^63-1]. This
means that 0xffffFFFFffffFFFF (2^64-1) will be out of range and is written as
max LL. Actually, every 64-bit number with high-bit set will wrongly be
written as max LL.
This commit uses strtoull() instead to fix this, and checks for unsiged out-
of-range error. strtoull() also has the neat benefit that input with a minus
sign is treated like C unsigned numbers, ie, -u is also a valid unsigned
number if only u is one. In case the input is meant to be treated as signed,
it is therefore still OK to use strtoull() in the first instance only that in
this case a second check against the range of the signed domain is necessary.
The paged read in pickit2.c has two errors:
- It drops load extended address commands unless a paged read happens at a
64k byte boundary; this is invalid when reading files with holes
- It wrongly assumed that flash memory is byte addressed
The fix is to carry out a load extended address command, if needed, at the
beginning of each paged flash read with the correct word address. Although the
pickit2_paged_load() has independent parameters page_size, addr and n_bytes,
AVRDUDE only ever calls paged read/write functions with page_size and n_bytes
both set to mem->page_size and addr aligned with a page boundary. Therefore, it
is sufficient to set the load extended address at the beginning of each page
read.
In certain situations (CRC failure, device locked), that JTAG3
read functions need to return an indication to the caller that
it is OK to proceed, and allow erasing the device anyway.
Historically, the JTAG3 code passed the respective protocol
errors directly (and unexplained) up to the caller, leaving
the decision to the caller how to handle the situation.
Replace that by a more common return value API. New code should
prefer this API instead of any hardcoded return values.
-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\*/\*
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>
In certain situations (CRC failure, device locked), that JTAG3
read functions need to return an indication to the caller that
it is OK to proceed, and allow erasing the device anyway.
Historically, the JTAG3 code passed the respective protocol
errors directly (and unexplained) up to the caller, leaving
the decision to the caller how to handle the situation.
Replace that by a more common return value API. New code should
prefer this API instead of any hardcoded return values.
In terminal mode, there are two forms of "write", one that
explicitly mentions all data values, and a second one that
instead specifies a total range to write, where the last data
value given is replicated as needed.
Alas, MacOS doesn't handle nonstandard baud rates like other systems
in regular tcsetattr() calls. Instead, they invented a new ioctl
(IOSSIOSPEED). So, if we notice we are going to configure a
nonstandard rate on MacOS, issue that ioctl after configuring
everything else using tcsetattr().
Stefan Rueger
MCUdude
Jan Egil Ruud
Joerg Wunsch
Stefan Rueger
prchal
Fabrice Fontaine
Marius Greuel
Ebben Aries
Subhaditya Nath
Tomasz 'CeDeROM' CEDRO
Alexander Smirnov
Nav