programming : jtag2updi VS SerialUPDI

[PM04290]

I usually use jtag2updi to program the attiny and it works perfectly; for a particular project I will have to program the ATtiny with an ESP32, my first attempts with the Adafjuit AVRprog library did not work, I wanted to check that my wiring was correct, so I tried with a SerialUPDI programmer via a USB module based on CH340; nothing works and none of the programmer configurations work.
I tried several resistance values, with or without diode. Currently, the best result is with a simple 1K resistor between TX and RX. I operate in 3.3v on both sides. below is the trace of what I can have at best... I don't know where to look anymore.

SerialUPDI
UPDI programming for Arduino using a serial adapter
Based on pymcuprog, with significant modifications
By Quentin Bolsee and Spence Konde
Version 1.2.3 - Jan 2022
Using serial port COM5 at 57600 baud.
Target: attiny3216
Set fuses: ['0:0b00000000', '2:0x02', '6:0x04', '7:0x00', '8:0x00']
Action: write
File: C:\Users\Admin\AppData\Local\Temp\arduino_build_700534/attiny3216-blink.ino.hex
pymcuprog.programmer - INFO - Setting up programming session for 'attiny3216'
pymcuprog.deviceinfo.deviceinfo - INFO - Looking for device attiny3216
pymcuprog.serialupdi.physical - INFO - Opening port 'COM5' at '57600' baud
pymcuprog.serialupdi.link - INFO - STCS 08 to 0x03
pymcuprog.serialupdi.link - INFO - STCS 06 to 0x02
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
pymcuprog.serialupdi.link - INFO - UPDI init OK
pymcuprog.serialupdi.link - INFO - STCS 06 to 0x02
pymcuprog.serialupdi.link - INFO - Setting UPDI clock to 4 MHz
pymcuprog.serialupdi.link - INFO - STCS 03 to 0x09
pymcuprog.serialupdi.physical - INFO - Switching to '57600' baud
pymcuprog.serialupdi.application - INFO - SIB: 'tinyAVR P:0D:0-3M2 (01.59B15.0)'
pymcuprog.serialupdi.application - INFO - Device family ID: 'tinyAVR'
pymcuprog.serialupdi.application - INFO - NVM interface: 'P:0'
pymcuprog.serialupdi.application - INFO - Debug interface: 'D:0'
pymcuprog.serialupdi.application - INFO - PDI oscillator: '3M2'
pymcuprog.serialupdi.application - INFO - Extra info: '(01.59B15.0)'
pymcuprog.serialupdi.application - INFO - Using 16-bit UPDI
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
pymcuprog.serialupdi.application - INFO - PDI revision = 0x02
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.application - INFO - Entering NVM programming mode
pymcuprog.serialupdi.link - INFO - LDCS from 0x07
pymcuprog.serialupdi.application - INFO - Apply reset
pymcuprog.serialupdi.link - INFO - STCS 59 to 0x08
pymcuprog.serialupdi.application - INFO - Release reset
pymcuprog.serialupdi.link - INFO - STCS 00 to 0x08
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.nvm - INFO - No specific initializer for this provider
Pinging device...
pymcuprog.programmer - INFO - Reading device ID...
pymcuprog.serialupdi.application - INFO - SIB: 'tinyAVR P:0D:0-3M2 (01.59B15.0)'
pymcuprog.serialupdi.application - INFO - Device family ID: 'tinyAVR'
pymcuprog.serialupdi.application - INFO - NVM interface: 'P:0'
pymcuprog.serialupdi.application - INFO - Debug interface: 'D:0'
pymcuprog.serialupdi.application - INFO - PDI oscillator: '3M2'
pymcuprog.serialupdi.application - INFO - Extra info: '(01.59B15.0)'
pymcuprog.serialupdi.application - INFO - Using 16-bit UPDI
pymcuprog.serialupdi.link - INFO - LDCS from 0x00
pymcuprog.serialupdi.application - INFO - PDI revision = 0x02
pymcuprog.serialupdi.link - INFO - LDCS from 0x0B
pymcuprog.serialupdi.application - INFO - Device ID from pyupdi = '1E9421' rev 'B'
pymcuprog.nvm - INFO - Device ID: '1E9421'
pymcuprog.nvm - WARNING - ID read ('1E9421') does not match expected device id! ('1E9521')
Device ID mismatch! Stopping.
pymcuprog.serialupdi.application - INFO - Leaving NVM programming mode
pymcuprog.serialupdi.application - INFO - Apply reset
pymcuprog.serialupdi.link - INFO - STCS 59 to 0x08
pymcuprog.serialupdi.application - INFO - Release reset
pymcuprog.serialupdi.link - INFO - STCS 00 to 0x08
pymcuprog.serialupdi.link - INFO - STCS 0C to 0x03
pymcuprog.serialupdi.physical - INFO - Closing port 'COM5'
Une erreur est survenue lors du transfert du croquis

[MX682X]

pymcuprog.nvm - WARNING - ID read ('1E9421') does not match expected device id! ('1E9521')

0x1E 0x94 0x21 is an ATtiny1616
0x1E 0x95 0x21 is an ATtiny3216

Now the question is, which one do you expect to have and which one is on the board?

[SpenceKonde]

Do we even need to ask? We know what's going on here - he selected a 3216 and is attempting to upload to a 1616. SerialUPDI correctly issues an error notice with a very clear error message....

[MX682X]

Well, there was a case somehwere in the Discussions, where the fab put an 816 on the board, while a 416 was ordered.
Also, if they expect to have a 3216, but have a 1616, it's nice to know what seller to avoid.

[PM04290]

It's so obvious....
Argh, a day wasted because a 1616 got mixed up in the middle of my 3216.
So it works perfectly. Now i can continue my ESP32 standalone programmer.
Many again.

[PM04290]

All is perfect with SerialUSB (3.3v powering, wiring compliant), but with my ESP32 program (3.3v) , the command LDCS 0x00 have no response. Have you an idea of the issue ?

[MX682X]

There are plenty ideas. With the currently available information it is extremly hard to say. The first thing to check is the behaviour of the physical line with an oscilloscope. This helps to verify the connections and the software.

[PM04290]

this is 2 screen of each updi initialsation
i checked all datas sent : BREAK ...... 55 C3 08 .... 55 C2 06 .... 55 80 ..... no response
time line is the same
red line is at end of 55 80 to show the difference

[MX682X]

Hmm. Hard to say what's wrong. My best guess at this point is that the ESP is too slow. at least the red line is significantly further right.
Edit: Try reading the status register first, then the LDCS. This could help figure out if the problems lie in the timings.
Also, the datasheet mentioned that it might be sensible to send two BKEAKs, to make sure that they count.