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().
This means that you can use ... to read the "rest" of the memory.
$ read eeprom ... will dump the entire memory
$ read eeorm 0x80 ... will dump the memory from address 0x80 to the end address
If you run the following command: $ write eeprom 0x00 0x10 A B C ...
It will write the following data to EEPROM:
|ABCCCCCCCCCCCCCC|
starting from address 0x00
It breaks the alias handling completely as the search happens
way too late. So instead, just keep any possibly duplicate
name as it won't be in our way anyway.
Implementation for an "alias" keyword.
By now, only applied inside memory descriptions.
* Make "mem_alias" a separate nonterminal.
The previous implementation attempt caused a syntax error in
yacc code, and separating mem_alias on the same level as
mem_spec appears to be the cleaner solution anyway.
* Maintain real memory aliases.
Instead of duplicating the aliased memory with a new name, maintain a
second list of memory aliases (per device) that contains a pointer to
the memory area it is aliased to. That way, a memory name can be
clearly distinguished between the canonical one and any aliases.
* Check p->mem_alias != NULL before touching it
* Add avr_find_memalias()
This takes a memory region as input, and searches whether an
alias can be found for it.
* We need to add a list structure for the mem_alias list, always.
By that means, mem_alias won't ever be NULL, so no need to check
later.
Also, in avr_dup_part(), duplicate the alias list.
* In a memory alias, actually remember the current name.
* In avr_dup_part(), adjust pointers of aliased memories
While walking the list of memories, for each entry, see if there is an
alias pointing to it. If so, allocate a duplicated one, and fix its
aliased_mem pointer to point to the duplicated memory region instead
of the original one.
* Add avr_locate_mem_noalias()
When looking whether any memory region has already been defined for
the current part while parsing the config file, only non-aliased names
must be considered. Otherwise, a newly defined alias would kick out
the memory definition it is being aliased to.
* When defining a mem_alias, drop any existing one of that name.
* Actually use avr_find_memalias() to find aliases
* Add declaration for avr_find_memalias()
* When defining a memory, also search for an existing alias
If the newly defined name has the same as an existing alias, the alias
can be removed.
Note that we do explicitly *not* remove any memory by the same name of
a later defined alias, as this might invalidate another alias'es
pointer. If someone defines that, the alias name just won't ever be
found by avr_locate_mem().
This feature has been designed with the sometimes quite flakey direct
(parallel or serial port attached) bitbang programming adapters in
mind that were quite common about two decades ago.
With parallel ports vanishing from modern PCs almost completely, and
the advent of various USB-attached low-cost programming devices,
this class of programmers disappeared almost completely.
Furthermore, the fuse combinations that were covered by the feature
are no longer around on all recent AVR devices, so for an ever
increasing number of devices, safemode already became meaningless and
was turned off anyway.
With the prospective version 7.x release, it's a good point in time to
introduce a major change like this one.
With the split CMakeLists.txt infrastructure avrdude.conf
will be created in the build/src and not build folder. Hence,
fix its location in the install command.
The main CMakeLists.txt file in the project's root directory takes
care of the main project settings like project name and version,
handling the options, finding dependencies, etc.
The src/CMakeLists.txt handles options that are necessary to build
libavrdude library and avrdude binary.
Previously, all libusb-1.0 error strings have been translated
by libusb_to_errno() into an errno-like integer, only in order
to pass that one straight into strerror().
For unhandled libusb-1.0 error codes, ERANGE was returned, which
is just nonsense ("Result too large", bug #848).
Instead, use a single function errstr() now that either can
use strerror() on some well-defined errno-like code, or otherwise
just return a string that mentions the numeric value.