Report: Incorrect SerialUPDI control of AVR64EA32

[askn37]

Report: Incorrect SerialUPDI control of AVR64EA32

This is a known bug as of commit 481a91d.

1. You are trying to read the "Chip Silicon Revision" register without checking the status of the target device. This will fail if the target device is "resetting" or "sleeping".
2. The address width used to access the flash area is incorrectly set to 16 bits. Therefore, the IO memory area is accessed instead of the flash area. The correct address width must be 24 bits.(Shouldn't we send 0x55 0x6A 0x00 0x00 0x80 here?)

case.1 Debug log

avrdude: sending 2 bytes [0x55, 0xe6]
avrdude: send: U [55] . [e6] 
avrdude: recv: U [55] . [e6] 
avrdude: recv: A [41] V [56] R [52]   [20]   [20]   [20]   [20]   [20] P [50] : [3a] 3 [33] D [44] : [3a] 1 [31] - [2d] 3 [33] M [4d] 2 [32]   [20] ( [28] B [42] 1 [31] . [2e] 5 [35] 9 [39] F [46] 0 [30] 2 [32] . [2e] 0 [30] ) [29] . [00] 
avrdude: received 32 bytes [0x41, 0x56, 0x52, 0x20, 0x20, 0x20, 0x20, 0x20, 0x50, 0x3a, 0x33, 0x44, 0x3a, 0x31, 0x2d, 0x33, 0x4d, 0x32, 0x20, 0x28, 0x42, 0x31, 0x2e, 0x35, 0x39, 0x46, 0x30, 0x32, 0x2e, 0x30, 0x29, 0x00]
avrdude: received SIB: [AVR     P:3D:1-3M2 (B1.59F02.0)]
avrdude: Device family ID: AVR     
avrdude: NVM interface: P:3
avrdude: Debug interface: D:1
avrdude: PDI oscillator: 3M2 
avrdude: Extra information: (B1.59F02.0)
avrdude: NVM type 3: 16-bit, page oriented
avrdude: reading 1 bytes from 0x000F01
avrdude: ST_PTR to 0x000F01
avrdude: sending 4 bytes [0x55, 0x69, 0x01, 0x0f]
avrdude: send: U [55] i [69] . [01] . [0f] 
avrdude: recv: U [55] i [69] . [01] . [0f] 
avrdude: ser_recv(): programmer is not responding
avrdude: serialupdi_recv(): programmer is not responding
avrdude: UPDI ST_PTR recv failed on ACK
avrdude: ST_PTR operation failed
avrdude serialupdi_initialize() [serialupdi.c:636] error: Reading chip silicon revision failed
avrdude main() [main.c:1404] error: initialization failed, rc=-1
        - double check the connections and try again
        - use -b to set lower baud rate, e.g. -b 57600
        - use -F to override this check

case.2 Debug log

avrdude: processing -U flash:r:avr64ea32/Flash.hex:i
avrdude: reading flash memory ...
avrdude: reading 128 bytes from 0x800000
avrdude: ST_PTR to 0x800000
avrdude: sending 4 bytes [0x55, 0x69, 0x00, 0x00]
avrdude: send: U [55] i [69] . [00] . [00] 
avrdude: recv: U [55] i [69] . [00] . [00] 
avrdude: recv: @ [40] 
avrdude: received 1 bytes [0x40]
avrdude: repeat 128
avrdude: sending 3 bytes [0x55, 0xa0, 0x7f]
avrdude: send: U [55] . [a0] . [7f] 
avrdude: recv: U [55] . [a0] . [7f] 
avrdude: LD8 from ptr++
avrdude: sending 2 bytes [0x55, 0x24]
avrdude: send: U [55] $ [24] 
avrdude: recv: U [55] $ [24] 
avrdude: recv: . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [ff] . [7f] . [02]   [20] . [00] . [07] . [00]   [20] . [00] . [07] . [00]   [20] . [00] . [07] . [00]   [20] . [00] . [07] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [07] . [00] . [00] . [00] . [00] . [00] . [00] . [05] . [00] . [00] . [00] . [00] * [2a] . [00] . [06] . [00] . [00] . [00] . [00] . [00] . [00] . [10] . [00] . [00] . [00] . [2e] . [00] . [00] . [00] . [00] . [00] . [00] 
avrdude: received 128 bytes [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x7f, 0x02, 0x20, 0x00, 0x07, 0x00, 0x20, 0x00, 0x07, 0x00, 0x20, 0x00, 0x07, 0x00, 0x20, 0x00, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x2a, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x2e, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]

Need additional information?

I design my own program writer and create firmware that meets various practical needs. This time, we also acquired control including HV programming using AVR64EA32. I noticed this problem when I was doing comparison testing with other programmers.

• NVMCTRL version 3 can correctly interpret 24-bit extended addresses. Although this is clearly stated in the datasheet, NVMCTRL_ADDRESS is a 24-bit register. This allows 16-bit address commands for UPDI access to correspond to LD/ST instructions, and 24-bit address commands to correspond to ELPM/SPM instructions. To treat the flash memory area linearly, you need to set his MSB of this address. In other words, the setting value is 0x800000 or higher. This behavior is equivalent to the AVR_Dx series (NVMCTRL version 2).

• This series has a maximum flash capacity of 64KiB, so there is no RAMPZ register. The FLMAP field, which switches the latter bank of data space, also uses only one bit. However, there is no need to manipulate these from UPDI.

• REVID register 0xF01 is a register in the IO memory space, so it can only be read when the CPU is active or in his NVMPROG mode. The current implementation of SerialUPDI probably does not take into account the existence of power-saving devices that regularly use CPU sleep.

• (Supplement) Use PF6 (RESET pad) to enable high voltage mode. The datasheet states the absolute rating is 9V. Therefore, a suitable high voltage here is 8.2 V when using a Zener diode. However, PICkit4 can exceed this voltage and violate ESD protection.

Further additional information

There are two execution result logs here. Both are displayed when -vvvvq is specified. One result is the target device is asleep, and the other result is the target device is running.

test_run.log test_sleep.log

[mcuee]

Strange part:

"updi_read_sib" is called after checking "UPDI_ASI_SYS_STATUS". This is strange. This is because "UPDI_ASI_SYS_STATUS" expands with each version of his NVMCTRL. v0 has meaning on 5 bits, v2 has meaning on 6 bits, and v3 has meaning on all 8 bits. Therefore, you need to check the version of NVMCTRL by calling 'updi_read_sib' and reading 'UPDI_ASI_SYS_STATUS'. There are no particular problems with v2. However, v3 added an important "BOOTDONE" bit. Set to 1 when the CPU completes the "power-on reset" boot process. Otherwise, you are not ready to run "serialupdi_enter_progmode". So you have to read "UPDI_ASI_SYS_STATUS" again and wait until it becomes 1, or try a few times and abort on timeout. And that should be done before any other investigation.

What I know:

For NVMCTRLv0/2, it is safe to run "serialupdi_enter_progmode" when "RSTSYS=0", "INSLEEP=any", "NVMPROG=any", "UROWPROG=0", "LOCKSTATUS=0". v3 also requires "BOOTDONE=1". (At the same time, for v3, this may make it less susceptible to the negative effects of DTR/RTS control.) ('INSLEEP=1' can be ignored as 'ASI_RESET' is used to enable 'NVMPROG_KEY'. However, at this stage if 'NVMPROG=1' use 'RSTSYS =0') is needed.)

@dbuchwald Please review this part and comment. Thanks.