UPDI Failing #585

GeorgeIoak · 2021-12-27T18:28:24Z

GeorgeIoak
Dec 27, 2021

I wanted to do a quick test on a ATtiny1626 part and confirm that I could program it but I'm not having much luck.

I have a CP2102 serial adapter and have confirmed that it has no series resistors or LEDs on the Tx/Rx lines. Oddly enough the board is marked Tx/Rx but Tx is actually connected to the CP2102 pin 25 with is Rx on the CP2102.
I have the 1626 mounted on a breakout board with a 100nF cap on Vcc as well as rest/updi
On the breadboard I have a BAT54C in SOT23 package with pins soldered onto pins 1&3
I go from [CP2102-Tx] --> [Cathode BAT54C] --> [Anode BAT54C] --> [470Ω] --> [1626-pin16(UPDI)]

I just get the generic pymcuprog.pymcuprog_errors.PymcuprogError: UPDI initialisation failed error in Arduino 1.8.16 with version 2.5.4 of megaTinyCore

I'm attaching a picture of my setup as well as a capture of the traffic. This is the first time for me using UPDI so I'm not sure what the proper sequence should look like

Answered by apws

Dec 27, 2021

well, datasheet tells about cap to ground, in case the pin is reset, but by default, most important function of PA0/RESET/UPDI pin is UPDI where capacitor is tackling with signal probably ... you reset the device with power-up well... in case you will move to optiboot (which has other quirks now, hopefully fixed soon) then you can have real reset on PB4 with autoreset RC circuit as below... I have BAT85+470ohm and also 10k from Vcc to RX (read somewhere here to overcome rx led on my CH340, dont know if its important though)

View full answer

mechatroniks-git · 2021-12-27T21:10:16Z

mechatroniks-git
Dec 27, 2021

I struggled with other UPDI programmers until the CH340G. It has been very reliable.

Arduino 1.8.19 Megatinycore 2.5.4
Programmer: SerialUPDI with 4.7k resistor or diode [TURBO 4.5v + 460800 baud)
Chip powered with 3.3v DC.

[CH340G-Tx] --> [402Ω] [Cathode BAT54C - pin 3] --> [Anode BAT54C - pins 1*2] --> --> [CH340G-RX (UPDI)]

You can try slowing down the baud to 57600.

This is what a good programming event looks like:

SerialUPDI
UPDI programming for Arduino using a serial adapter
Based on pymcuprog, with significant modifications
By Quentin Bolsee and Spence Konde
Version 1.2.0 - June 2021
Using serial port COM9 at 460800 baud.
Target: attiny1624
Set fuses: ['2:0x02', '6:0x07', '8:0x00']
Action: write
File: C:\Users\win10\AppData\Local\Temp\arduino_build_108744/ATtiny.ino.hex
Pinging device...
Ping response: 1E942A
Setting fuse 0x2=0x2
Writing literal values...
Verifying literal values...
Action took 0.03s
Setting fuse 0x6=0x7
Writing literal values...
Verifying literal values...
Action took 0.03s
Setting fuse 0x8=0x0
Writing literal values...
Verifying literal values...
Action took 0.02s
Finished writing fuses.
Chip/Bulk erase,
Memory type eeprom is conditionally erased (depending upon EESAVE fuse setting)
Memory type flash is always erased
Memory type lockbits is always erased
...
Erased.
Action took 0.01s
Writing from hex file...
Writing flash...
[==================================================] 246/246
Action took 2.19s
Verifying...
[==================================================] 31/31
Verify successful. Data in flash matches data in specified hex-file
Action took 0.56s

If I disconnect UPDI from the chip, I get your error.

pymcuprog.pymcuprog_errors.PymcuprogError: UPDI initialisation failed

1 reply

GeorgeIoak Dec 27, 2021
Author

Thanks for showing a working setup. I do have some CHG340 based adapters coming but I don't think I'll get them until the end of the week.
I'm measuring close to 5V at the actual VCC pin of the ATtiny1626 and I also confirmed which pin of the adapter is Tx by starting a serial monitor, typing a character, and watching the logic analyzer.
I've tried switching things around just to see if I've got anything connected wrong but nothing works. I even just installed pymcuprog and am running that from the command prompt and am getting the same error.

I see the adapter Tx send a low pulse of ~85us to start the communication
UPDI pin goes low ~28us after the Tx pin goes low.
UPDI pin then has a high pulse ~500us later and then another 40us after that one
Then it looks like about 4 bytes of data is sent by the adapter

The traffic starts with this:

and then ends with this:

So I see traffic on both lines but I think I should be seeing all the traffic on the UPDI pin since it's a 1-wire interface.

apws · 2021-12-27T21:28:06Z

apws
Dec 27, 2021

hi, why the cap on UPDI to Vcc ??

1 reply

GeorgeIoak Dec 27, 2021
Author

Because that's what the datasheet says to do:

On my actual board (which hasn't been fabricated yet) I also have a button for reset but on this breadboard I left the button out for now.

apws · 2021-12-27T21:42:44Z

apws
Dec 27, 2021

well, datasheet tells about cap to ground, in case the pin is reset, but by default, most important function of PA0/RESET/UPDI pin is UPDI where capacitor is tackling with signal probably ... you reset the device with power-up well... in case you will move to optiboot (which has other quirks now, hopefully fixed soon) then you can have real reset on PB4 with autoreset RC circuit as below... I have BAT85+470ohm and also 10k from Vcc to RX (read somewhere here to overcome rx led on my CH340, dont know if its important though)

0 replies

GeorgeIoak · 2021-12-27T21:51:52Z

GeorgeIoak
Dec 27, 2021
Author

Thanks for sharing an actual schematic. You've got a good point about the UPDI pin and reset. I'll pull that cap off and see what happens. But what happens with the parts that don't have the "extra" reset pin, you don't have a way to reset the part other than by cycling power?

I've seen some references to pulling the UPDI pin high (looking at an errata for the MPLAB SNAP programmer) and I tried that briefuly with no help but maybe the cap was holding me back.

8 replies

apws Dec 27, 2021

try it slower, or edit advanced properties o usb-serial (latency) if its FTDI (i dont have one), or try the 10k resistor for rx too...
my CH340 runs even 400k on 3.3V with this schematic

GeorgeIoak Dec 27, 2021
Author

Yeah, 57600 speed seems to work. Adding the 10kΩ PU to UPDI allows the faster programming but not the turbo speed but maybe the CP2102 can't do 460800

GeorgeIoak Dec 27, 2021
Author

I spoke too soon. Seems very unreliable at 23400 for some reason. I guess I got lucky when I did the first test with the 10k pull up.

mechatroniks-git Dec 28, 2021

If you command line it, you can set whatever baud rate you want.

Turn on verbose upload (Arduino -> File -> Preferences -> Show Verbose Output During: upload

That will show you the sting

C:\Users\win10\AppData\Local\Arduino15\packages\megaTinyCore\tools\python3\3.7.2-post1/python3 -u C:\Users\win10\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/tools/prog.py -t uart -u COM9 -b 460800 -d attiny1624 --fuses 2:0x02 6:0x07 8:0x00 -fC:\Users\win10\AppData\Local\Temp\arduino_build_338766/ATtiny.ino.hex -a write

change -b 460800 to -b 9600

Also, you can try installing pymcuprog and issue some commands like erase and read eeprom...

pymcuprog -t uart -u COM5 -d attiny1626 erase -C

pymcuprog -t uart -u COM5 -d attiny1626 read -m eeprom

GeorgeIoak Dec 28, 2021
Author

Thanks, I did install pymcuprog and confirmed that I could ping when troubles first started happening (ping didn't work until removal of the cap on the UPDI pin).
It could be my breadboard setup as it seems to be reliable at 57600 in the Arduino IDE.

What steps can I take to try and see what it preventing the faster speeds, the LA captures look basically the same so it might not be easy (or worth it)

apws · 2021-12-27T21:57:04Z

apws
Dec 27, 2021

yes, for 0/1 parts or below 20pin 2 parts, there is no reset pin, if you want button here, idea is some disconecting switch on Vcc (enough mA)

1 reply

GeorgeIoak Dec 27, 2021
Author

Well now I need to go back and change my schematic to connect to PB4 instead of the UPDI/RESET pin, I could get into HV programming but I don't think I want to mess with that, especially for rev 1 of the board.

GeorgeIoak · 2021-12-27T22:08:13Z

GeorgeIoak
Dec 27, 2021
Author

So after removing the cap from the UPDI pin I was able to get the ping command to work but going back to Arduino and trying to program the part doesn't work. Here's what happens, looks like fuse writing is OK but my blank sketch fails to write

`Sketch uses 354 bytes (2%) of program storage space. Maximum is 16384 bytes.
Global variables use 4 bytes (0%) of dynamic memory, leaving 2044 bytes for local variables. Maximum is 2048 bytes.
SerialUPDI
UPDI programming for Arduino using a serial adapter
Based on pymcuprog, with significant modifications
By Quentin Bolsee and Spence Konde
Version 1.2.0 - June 2021
Using serial port COM5 at 230400 baud.
Target: attiny1626
Set fuses: ['2:0x02', '6:0x04', '8:0x00']
Action: write
File: C:\Users\george\AppData\Local\Temp\arduino_build_396415/sketch_dec26a.ino.hex
Pinging device...
Ping response: 1E9429
Setting fuse 0x2=0x2
Writing literal values...
Verifying literal values...
Action took 0.01s
Setting fuse 0x6=0x4
Writing literal values...
Verifying literal values...
Action took 0.01s
Setting fuse 0x8=0x0
Writing literal values...
Verifying literal values...
Action took 0.01s
Finished writing fuses.
Chip/Bulk erase,
Memory type eeprom is conditionally erased (depending upon EESAVE fuse setting)
Memory type flash is always erased
Memory type lockbits is always erased
...
Erased.
Action took 0.01s
Writing from hex file...
Writing flash...
[======== ] 1/6Traceback (most recent call last):
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/tools/prog.py", line 282, in
main()
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/tools/prog.py", line 131, in main
return_code = pymcuprog_basic(args, fuses_dict)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/tools/prog.py", line 254, in pymcuprog_basic
pagewrite_delay=args.writedelay)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/tools/prog.py", line 141, in run_pymcu_action
status = func(backend, *args, args_pymcu)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\pymcuprog_main.py", line 340, in _action_write
_write_memory_segments(backend, result, args.verify, blocksize=args.blocksize, pagewrite_delay=args.pagewrite_delay)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\pymcuprog_main.py", line 387, in _write_memory_segments
backend.write_memory(segment.data, memory_name, segment.offset, blocksize=blocksize, pagewrite_delay=pagewrite_delay)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\backend.py", line 526, in write_memory
self.programmer.write_memory(data=data, memory_name=memory_name, offset=offset_byte, blocksize=blocksize, pagewrite_delay=pagewrite_delay)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\programmer.py", line 190, in write_memory
self.device_model.write(memory, offset, data, blocksize=blocksize, pagewrite_delay=pagewrite_delay)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\nvmserialupdi.py", line 175, in write
self.avr.nvm.write_flash(offset_aligned, chunk, blocksize=blocksize, bulkwrite = bulk, pagewrite_delay=pagewrite_delay)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\serialupdi\nvm.py", line 117, in write_flash
return self.write_nvm(address, data, use_word_access=True, blocksize=blocksize, bulkwrite=bulkwrite, pagewrite_delay=pagewrite_delay)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\serialupdi\nvm.py", line 199, in write_nvm
self.execute_nvm_command(nvmcommand)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\serialupdi\nvm.py", line 76, in execute_nvm_command
return self.readwrite.write_byte(self.device.nvmctrl_address + constants.UPDI_NVMCTRL_CTRLA, command)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\serialupdi\readwrite.py", line 64, in write_byte
return self.datalink.st(address, value)
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\serialupdi\link.py", line 332, in st
return self._st_data_phase([value & 0xFF])
File "C:\Users\george\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\serialupdi\link.py", line 278, in _st_data_phase
raise PymcuprogError("Error with st")
pymcuprog.pymcuprog_errors.PymcuprogError: Error with st
pymcuprog.pymcuprog_errors.PymcuprogError: Error with st

6 replies

GeorgeIoak Dec 28, 2021
Author

But when I run pymcuprog version 3.10.2.133 from the command line using pymcuprog -t uart -u COM5 -b 230400 -d attiny1626 -f readTempVcc.ino.t1626.20c0.mB1.pfF.v254.hex write --verify it works every single time. For some reason running through Arduino it fails every time unless I lower the speed.

I have scopes and logic analyzers so I can check everything closer if I know what to start looking at.

GeorgeIoak Dec 28, 2021
Author

Sorry, when you said latest Arduino did you mean 1.8.16 or the new 2.0 IDE? I'm also running on Win10

apws Dec 28, 2021

yes, 1.8.16 ... your experience with flashing is weird, but as I remember from reading all the docs here, CP2102 had really issues at some speeds, see here, bit chaotic, ya .... https://github.com/SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md
it seems it will need some tweaks also :-)

apws Dec 28, 2021

first link from here is also interesting, its production thing, parts in schematic may be reliable
#556

GeorgeIoak Dec 28, 2021
Author

Perhaps my issues are with the CP2102 but it's still odd that the programming appears to be very stable with the original pymcuprog and immediately fails with the modified version included with MTC. Maybe I should open an issue so this can be discussed and looked at?

I like the post to that auto programmer, I'll have to take a closer look at the design. As a side note, I wish the jtag2updi.md page would get updated with actual schematics instead of ASCII art. I personally would find it much easier to follow. That page has A LOT of information on it and it might be good to have a short version with links to more detailed information. Just show what you should do if you have a FTDI, CP2102, or CH340G. I was looking for that when I started and got lost with all the information.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

UPDI Failing #585

{{title}}

Replies: 6 comments 17 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

UPDI Failing #585

Replies: 6 comments · 17 replies

GeorgeIoak Dec 27, 2021 Author

GeorgeIoak Dec 27, 2021 Author

GeorgeIoak Dec 27, 2021 Author

GeorgeIoak Dec 27, 2021 Author

GeorgeIoak Dec 27, 2021 Author

GeorgeIoak Dec 28, 2021 Author

GeorgeIoak Dec 27, 2021 Author

GeorgeIoak Dec 27, 2021 Author

GeorgeIoak Dec 28, 2021 Author

GeorgeIoak Dec 28, 2021 Author

GeorgeIoak Dec 28, 2021 Author

Replies: 6 comments 17 replies

GeorgeIoak Dec 27, 2021
Author

GeorgeIoak Dec 27, 2021
Author

GeorgeIoak
Dec 27, 2021
Author

GeorgeIoak Dec 27, 2021
Author

GeorgeIoak Dec 27, 2021
Author

GeorgeIoak Dec 28, 2021
Author

GeorgeIoak Dec 27, 2021
Author

GeorgeIoak
Dec 27, 2021
Author

GeorgeIoak Dec 28, 2021
Author

GeorgeIoak Dec 28, 2021
Author

GeorgeIoak Dec 28, 2021
Author