When serving a vector bootloader, both -c urclock and now -c dryboot used
to protect two vectors in the vector table, the reset vector and the
dedicated vector to jump to the application.
Only the reset vector needs protecting to avoid the vector bootloader to
be bricked. While overwriting the other vector might turn out not helpful,
it's the same as with many other interventions, so much so that the driver
should not prevent that. Hence, this commit withdraws the protection of
the jmp-to-application vector.
For Linux udev, the new rules files could be read at runtime by
reloading them, rather than requiring a reboot. My experience says
this is always needed, not just for HID devices, and it's always
required to replug them afterwards.
The relatively complex and redundant @node pointers in the avrdude.texi
documentation are easy to get wrong. makeinfo knows how it should be from
a previous @menu command and does the right thing irrespective of what
@node claims to want to link to. Makeinfo does complain, though, about
inconsistent @node pointers. This commit fixes the @node pointers to
suppress these warnings.
There are new(!) classic parts: ATmegaS64M1 and ATmegaS128. These
cosmic-ray tolerant "space" versions are functionally the same as the
corresponding models without S. The user won't know this from looking at
the part name printed on the part, so they receive a new mcuid.
The device packs define other genuinely new parts:
- AVR16LA14 AVR16LA20 AVR16LA28 AVR16LA32
- AVR32LA14 AVR32LA20 AVR32LA28 AVR32LA32
They receive their own data structures in the avr intelligence files
avrintel.c and libavrdude-avrintel.h.
Microchip decided to introduce new USART signals AUX0 and AUX1 for these
parts in addition to the known ones (RXD, TXD, XCK, XDIR, USCK, RTS and
CTS). This necessitates an extension of the Usart_conf structure with aux0
and aux1 components. Note the data sheets are not yet available.
When disassembling AVRDUDE uses known labels for ldi operations that
initialise a register pair, eg,
ldi r30, lo8(nvm.ctrla) ; 0xcb = 203
ldi r31, hi8(nvm.ctrla) ; 0x01 = 1
out cpu.ccp, r24
st Z, r18
This is meant to illustrate a possible intention of the code. It is not
unusual to see a base register loaded, for example the USARTC0 register
base, into the Y or Z register pair and read write with displacement from
specific USARTC0 register bytes using the ldd and std opcodes.
However, sometimes these labels are misleading when, eg, the register pair
is just initialised as a counter. In particular that can easily happen for
I/O register addresses for which there are fewer use cases to put them
into a register pair as the in/out opcodes are short and no savings would
be made using ldd/std. For example,
ldi r28, lo8(gpio.gpior9) ; 0x09 = 9
ldi r29, hi8(gpio.gpior9) ; 0x00 = 0
is most likely used as a 16-bit counter initialised with 9. This would
better be disassembled as
ldi r28, 0x09 ; 9
ldi r29, 0x00 ; 0
This commit does so by removing the use of registers in I/O space as
symbolic ldi operands when loading a register pair.
