C:\Users\User\pyupdi-master\updi>pyupdi.py -d tiny414 -c COM2 -b 9600 -f LED_414.hex
Traceback (most recent call last):
File "C:\Users\User\pyupdi-master\updi\pyupdi.py", line 207, in
_main()
File "C:\Users\User\pyupdi-master\updi\pyupdi.py", line 97, in _main
nvm = UpdiNvmProgrammer(comport=args.comport,
File "C:\Users\Dan\AppData\Roaming\Python\Python39\site-packages\updi\nvm.py", line 17, in init
self.application = UpdiApplication(comport, baud, device)
File "C:\Users\Dan\AppData\Roaming\Python\Python39\site-packages\updi\application.py", line 17, in init
self.datalink = UpdiDatalink(comport, baud)
File "C:\Users\Dan\AppData\Roaming\Python\Python39\site-packages\updi\link.py", line 32, in init
raise Exception("UPDI initialisation failed")
Exception: UPDI initialisation failed

Any one know why im failing?

I built a project and compiled it, the program used 520 bytes showed in MPLAB X IDE
But when I executed pyupdi to download my code, terminal replied the information " ihex too large for flash "

Hi,

The -fs option appears broken, at least for attiny 1-series devices,

Traceback (most recent call last):
  File "/home/mark/ve_poo/bin/pyupdi.py", line 182, in <module>
    _main()
  File "/home/mark/ve_poo/bin/pyupdi.py", line 109, in _main
    if not _process(nvm, args):
  File "/home/mark/ve_poo/bin/pyupdi.py", line 131, in _process
    if not _set_fuse(nvm, fusenum, value):
  File "/home/mark/ve_poo/bin/pyupdi.py", line 163, in _set_fuse
    nvm.write_fuse(fusenum, value)
  File "/home/mark/ve_poo/lib/python3.6/site-packages/updi/nvm.py", line 135, in write_fuse
    return self.application.write_fuse(fuse_address, fuse_data)
  File "/home/mark/ve_poo/lib/python3.6/site-packages/updi/application.py", line 406, in write_fuse_v0
    if not self.progmode:
AttributeError: 'UpdiApplication' object has no attribute 'progmode'

Hi, I was wondering if you might be able to point me at some help to understand the pyupdi electronic circuit - connecting Rx and Tx with a resistor. What does that do and how does it help with UPDI? The reason for my question is that I'm using an FTDI board for the updi upload. but also want to use the same board for serial comms on a 4809 UART. I posted on the avrfreaks forum and got a circuit diagram in response which I'm working to understand the logic of, but to do that I have to get my head around what happens when the Tx and Rx on a serial port are connected with a 4k7 resistor. Many thanks for your help,
Paul
btw pyupdi works fine to upload code to my 4809 - thanks.

Hello,

What's your project licence please ?

Have a good day
T. Servuc

Hi!

I'm getting error:

INFO:phy Opening /dev/tty.SLAB_USBtoUART at 115200 baud INFO:phy send : [0x0] INFO:phy incorrect echo : [0x0] Traceback (most recent call last): File "pyupdi.py", line 160, in <module> _main() File "pyupdi.py", line 90, in _main device=Device(args.device)) File "/Users/silardgal/Documents/Dev/SENSA/pecka_pcb/Software/pyupdi/updi/nvm.py", line 17, in __init__ self.application = UpdiApplication(comport, baud, device) File "/Users/silardgal/Documents/Dev/SENSA/pecka_pcb/Software/pyupdi/updi/application.py", line 17, in __init__ self.datalink = UpdiDatalink(comport, baud) File "/Users/silardgal/Documents/Dev/SENSA/pecka_pcb/Software/pyupdi/updi/link.py", line 20, in __init__ self.updi_phy = UpdiPhysical(comport, baud) File "/Users/silardgal/Documents/Dev/SENSA/pecka_pcb/Software/pyupdi/updi/physical.py", line 30, in __init__ self.send([constants.UPDI_BREAK]) File "/Users/silardgal/Documents/Dev/SENSA/pecka_pcb/Software/pyupdi/updi/physical.py", line 85, in send raise Exception("Incorrect echo data") Exception: Incorrect echo data INFO:phy Closing /dev/tty.SLAB_USBtoUART

Any idea? I have everything soldered like in the readme.

Using a 3.3V FTDI Basic serial connection with 4.7k Ohm resistor (as seen in the ASCII schematic in the README)

With pyupdi I can successfully write a bootloader to the device (at least it says that it was successful) and read the fuses. However it does not successfully set the fuses.

This is the bootloader I flashed: https://github.com/SpenceKonde/DxCore/blob/master/megaavr/bootloaders/hex/optiboot_dx128_ser0.hex

When doing something like
python.exe pyupdi.py -d avr128db32 -c COM3 -fs 2:0x01 -b 9600 -v
(that was just for testing, not for changing the oscillator)

I get this response:

Verify error for fuse 2, expected 0x01 read 0x00
Error during processing

The fuses simply stay the same as they were before.

Any idea what the problem could be? When setting fuses of a ATmega4808 I don't have any problems.

Full verbose output when trying to set fuse: https://gist.github.com/Miraculix200/c237eeb85cd46688b02ecc341ae5ba86

Reading fuses: https://gist.github.com/Miraculix200/fe1d25380a1f50111b34e5085431e126

After much puzzling, trying a multitude of serial adapters, and some scope analysis, I've solved my instance of the infamous "UPDI not OK" error.

Cutting to the chase, the root cause was the indicator LEDs on my serial adapters. Desolder the current-limiting resistor next to the RX LED and you should be good to go.

The traces generally looked shapely (sharp transitions, low noise, minimal timing errors) on the oscilloscope, but the levels were off. I'm running the ATtiny at 3.0V for battery life, and my serial adapter was set to 3.3V, so I knew it was already questionable, but across a dozen serial adapters from various manufacturers only 3 worked and those only sometimes. There's a 33k pullup on my board to keep the !reset pin high in normal usage, and pyupdi is trying to drive that pin low through a 4.7k resistor on the TX, so I didn't expect the low side to be 0.00V, but it wasn't as good as I expected and it wasn't consistent. My Attiny was only sometimes catching the initialization pulse, and when it did, my serial adapter failed to see the echo that popped up 13 ms after the 0x55 0x80 data on the break/STCS/LDCS init sequence. I could see it on my scope, but the ground levels were poor.

The RX LED lit whenever I drove the TX LED, but it was much dimmer, which was weird - it should be digital. That was the clue that I ignored for an embarrassing number of hours. As it turns out, the CH340 and Silabs CP2102 chips do not have RXLED buffers. Yes, an FTDI chip can be configured to use its GPIO pins as an RXLED output, but only one of the FT232 boards I had was wired that way; I suspect counterfeit FTDIs (which is practically every one of them you'll find on Amazon or Alibaba) don't implement the whole CBUS multipurpose IO feature. The designer would need to add a 74xx or something, and they're not going to spend that 5 cents when you're buying them in packs of 5, shipped, for less than the cost of a genuine FTDI chip. They'll instead just load the RX line and not worry about it as long as they get an insufficient number of complaints.

We're effectively dealing with this:

                         Vcc                     Vcc
                        +-+                     +-+
                         |                       |
 +---------------------+ |                       | +--------------------+
 | Serial port         +-+                       +-+        AVR device  |
 |                     |                           |                    |
 |       LED           |                           |                    |
 |  Vcc--|>|--[330]-+  |      +----------+         |    +---[33k]--Vcc  |
 |                  ----------+   4k7    +--------------                |
 |      TX----------+  |      +----------+    |    |    +-----+ UPDI    |
 |                     |                      |    |                    |
 |       LED   cut!    |                      |    |                    |
 |  Vcc--|>|--[330]-+  |                      |    |                    |
 |                  |-------------------------+    |                    |
 |      RX----------+  |                           |                    |
 |                     +--+                     +--+                    |
 +---------------------+  |                     |  +--------------------+
                         +-+                   +-+
                         GND                   GND

which is not the same as the circuit in the README. The TX pin is trying to pull the UPDI line low through a 4.7k resistor, fighting (successfully) against not only the 33k pullup on my target device, but also (unsuccessfully) against a 330 (or 220, or 270, depending on which adapter I used) pullup minus the forward voltage of various indicator LEDs.

I removed the resistor marked "Cut" above. After rectifying this situation, things worked much better.

I use a Raspberry PI without a Resistor between RX and TX and a level converter between ATmega4809 and the Raspberry.

I got this output:

python3 pyupdi.py -d mega4809 -c /dev/ttyAMA0 -fr -v
INFO:phy Opening /dev/ttyAMA0 at 115200 baud
INFO:phy send : [0x0]
INFO:link STCS to 0x03
INFO:phy send : [0x55, 0xc3, 0x8]
INFO:link STCS to 0x02
INFO:phy send : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send : [0x55, 0x80]
INFO:phy receive : []
INFO:link UPDI not OK - reinitialisation required
INFO:phy Sending double break
INFO:phy Opening /dev/ttyAMA0 at 115200 baud
INFO:link STCS to 0x03
INFO:phy send : [0x55, 0xc3, 0x8]
INFO:link STCS to 0x02
INFO:phy send : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send : [0x55, 0x80]
INFO:phy receive : []
INFO:link UPDI not OK - reinitialisation required
Traceback (most recent call last):
File "pyupdi.py", line 178, in
_main()
File "pyupdi.py", line 95, in _main
device=Device(args.device))
File "/home/pi/piupdi/pyupdi/updi/nvm.py", line 17, in init
self.application = UpdiApplication(comport, baud, device)
File "/home/pi/piupdi/pyupdi/updi/application.py", line 17, in init
self.datalink = UpdiDatalink(comport, baud)
File "/home/pi/piupdi/pyupdi/updi/link.py", line 31, in init
raise Exception("UPDI initialisation failed")
Exception: UPDI initialisation failed
INFO:phy Closing /dev/ttyAMA0

I checked the level with a scope, they are correct on the Raspberry Pi side and on the AVR side.
Do you have any advice to get further?

Pretty much what the title says. pyupdi works well on a new chip, but once I set the lockbit fuse to an invalid value (i.e, lock the chip), all other commands fail. Even a "-e" erase command fails, with the output:

Device is locked. Performing unlock with chip erase.
Traceback (most recent call last):
File "pyupdi.py", line 98, in _main
nvm.enter_progmode()
File "/Users/samay/Downloads/pyupdi-master/updi/nvm.py", line 34, in enter_progmode
if self.application.enter_progmode():
File "/Users/samay/Downloads/pyupdi-master/updi/application.py", line 129, in enter_progmode
raise Exception("Failed to enter NVM programming mode")
Exception: Failed to enter NVM programming mode

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "pyupdi.py", line 178, in
_main()
File "pyupdi.py", line 101, in _main
nvm.unlock_device()
File "/Users/samay/Downloads/pyupdi-master/updi/nvm.py", line 54, in unlock_device
self.application.unlock()
File "/Users/samay/Downloads/pyupdi-master/updi/application.py", line 89, in unlock
raise Exception("Failed to chip erase using key")
Exception: Failed to chip erase using key

Not only do all commands fail with this output, the program doesn't run anymore after the attempt (to erase/program/read fuses/anything). Maybe it is getting erased but partially or something.

MPLAB erases the chip fine, and pyupdi works again on the erased chip. Repeated erases/programs etc work fine while the chip is not locked.

Using Python3 and a CP2012 adapter.

anyone tried it only with one GPIO of raspberry?

Hi,
I can Flash and read the FUSEs but when I try to set a fuse it always fail with the error below.

ze-mac:device ze$ pyupdi.py -fs 0:0x00 -c /dev/cu.SLAB_USBtoUART -d tiny202 -b 115200
Device info: {'family': 'tinyAVR', 'nvm': 'P:0', 'ocd': 'D:0', 'osc': '3', 'device_id': '1E9123', 'device_rev': '0.1'}
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/bin/pyupdi.py", line 182, in <module>
    _main()
  File "/Library/Frameworks/Python.framework/Versions/3.7/bin/pyupdi.py", line 109, in _main
    if not _process(nvm, args):
  File "/Library/Frameworks/Python.framework/Versions/3.7/bin/pyupdi.py", line 131, in _process
    if not _set_fuse(nvm, fusenum, value):
  File "/Library/Frameworks/Python.framework/Versions/3.7/bin/pyupdi.py", line 163, in _set_fuse
    nvm.write_fuse(fusenum, value)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/updi/nvm.py", line 135, in write_fuse
    return self.application.write_fuse(fuse_address, fuse_data)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/updi/application.py", line 406, in write_fuse_v0
    if not self.progmode:
AttributeError: 'UpdiApplication' object has no attribute 'progmode'
ze-mac:device ze$

Is it possible to add eeprom read/write to pyupdi? By my understanding, the NVM Controller also allows read/writing to the EEPROM. So it should be just the same approach as flash programming with just different address right?

It seems pyupdi is very broken at the moment, various errors like "UPDI not OK - reinitialisation required", "AttributeError: 'UpdiApplication' object has no attribute 'progmode'".
I managed to find an older copy of this program, and added manually the changes for reading fuses/more devices.
Sadly, it seems mraardvark seems to have little time, and I cant really figure out which changes made the bork.
I hope mraardvaark is OK ?

Cheers and thanks for a very useful tool!
Any thoughts about adding an option to read out the fuse bits? I notice that the underlying code is already there and what's missing is more or less just an argument to the parser.

Support for the ATmega3208/3209/4808/4809 would be great.

I have been trying but could not get it to work.
I am using windows 10 with a standard USB-COM (CP2102 I believe) adapter, running python 3, and trying to flash a attinty1614, on a board I made myself.

Initially, I got
File "C:\Users\linhz\Downloads\pyupdi-master\updi\physical.py", line 103, in receive
response.append(ord(character))
TypeError: ord() expected a character, but string of length 0 found

And the command I used is
python pyupdi.py -d tiny1614 -c COM4 -f "XXXX path to the .hex"

Then I observed that when I turn on the system and run it the first time, it seems to go a bit further. I also suspected a 100k pull-up resistor on my rst line might screw up the interface, so I removed it. I also turned on verbose to get the most info.

The first attempt after power on gives me:
`
INFO:phy Opening COM4 at 9600 baud
INFO:phy send : [0x0]
INFO:link STCS to 0x03
INFO:phy send : [0x55, 0xc3, 0x8]
INFO:link STCS to 0x02
INFO:phy send : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send : [0x55, 0x80]
INFO:phy receive : [0x20]
INFO:link UPDI init OK
UPDI programmer created successfully
INFO:nvm Entering NVM programming mode
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0x82]
INFO:app Entering NVM programming mode
INFO:link Writing key
INFO:phy send : [0x55, 0xe0]
INFO:phy send : [0x20, 0x67, 0x6f, 0x72, 0x50, 0x4d, 0x56, 0x4e]
Device is locked. Performing unlock with chip erase.
INFO:link Writing key
INFO:phy send : [0x55, 0xe0]
INFO:phy send : [0x65, 0x73, 0x61, 0x72, 0x45, 0x4d, 0x56, 0x4e]
Traceback (most recent call last):
File "pyupdi.py", line 88, in _main
nvm.enter_progmode()
File "C:\Users\linhz\Downloads\pyupdi-master\updi\nvm.py", line 30, in enter_progmode
if self.application.enter_progmode():
File "C:\Users\linhz\Downloads\pyupdi-master\updi\application.py", line 96, in enter_progmode
self.datalink.key(constants.UPDI_KEY_64, constants.UPDI_KEY_NVM)
File "C:\Users\linhz\Downloads\pyupdi-master\updi\link.py", line 204, in key
self.updi_phy.send(list(reversed(list(key))))
File "C:\Users\linhz\Downloads\pyupdi-master\updi\physical.py", line 80, in send
self.ser.write([character])
File "C:\ProgramData\Anaconda3\lib\site-packages\serial\serialwin32.py", line 308, in write
data = to_bytes(data)
File "C:\ProgramData\Anaconda3\lib\site-packages\serial\serialutil.py", line 66, in to_bytes
return bytes(bytearray(seq))
TypeError: an integer is required

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "pyupdi.py", line 150, in
_main()
File "pyupdi.py", line 91, in _main
nvm.unlock_device()
File "C:\Users\linhz\Downloads\pyupdi-master\updi\nvm.py", line 50, in unlock_device
self.application.unlock()
File "C:\Users\linhz\Downloads\pyupdi-master\updi\application.py", line 67, in unlock
self.datalink.key(constants.UPDI_KEY_64, constants.UPDI_KEY_CHIPERASE)
File "C:\Users\linhz\Downloads\pyupdi-master\updi\link.py", line 204, in key
self.updi_phy.send(list(reversed(list(key))))
File "C:\Users\linhz\Downloads\pyupdi-master\updi\physical.py", line 80, in send
self.ser.write([character])
File "C:\ProgramData\Anaconda3\lib\site-packages\serial\serialwin32.py", line 308, in write
data = to_bytes(data)
File "C:\ProgramData\Anaconda3\lib\site-packages\serial\serialutil.py", line 66, in to_bytes
return bytes(bytearray(seq))
TypeError: an integer is required
INFO:phy Closing COM4
`

And the subsequent times:

INFO:phy Opening COM4 at 9600 baud
INFO:phy send : [0x0]
INFO:link STCS to 0x03
INFO:phy send : [0x55, 0xc3, 0x8]
INFO:link STCS to 0x02
INFO:phy send : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send : [0x55, 0x80]
Traceback (most recent call last):
File "pyupdi.py", line 150, in
_main()
File "pyupdi.py", line 85, in _main
device=Device(args.device))
File "C:\Users\linhz\Downloads\pyupdi-master\updi\nvm.py", line 13, in init
self.application = UpdiApplication(comport, baud, device)
File "C:\Users\linhz\Downloads\pyupdi-master\updi\application.py", line 15, in init
self.datalink = UpdiDatalink(comport, baud)
File "C:\Users\linhz\Downloads\pyupdi-master\updi\link.py", line 22, in init
if not self.check():
File "C:\Users\linhz\Downloads\pyupdi-master\updi\link.py", line 40, in check
if self.ldcs(constants.UPDI_CS_STATUSA) != 0:
File "C:\Users\linhz\Downloads\pyupdi-master\updi\link.py", line 52, in ldcs
response = self.updi_phy.receive(1)
File "C:\Users\linhz\Downloads\pyupdi-master\updi\physical.py", line 103, in receive
response.append(ord(character))
TypeError: ord() expected a character, but string of length 0 found
INFO:phy Closing COM4

Any hints? I kind of need to fix this issues soon. Any help greatly appreciated. Thanks in advance.

Hi
Is there a way to write the User Row of the EEPROM with pyupdi?
Or is there a reason why adding this would be a bad idea? I could give it a try.
Thanks!

pyupdi -d tiny1624 -c COM8 -b 38400 -fs 10:0x00

This works with tiny1614, but not tiny1624, as the device is not recognized.

PYMUCPROG doesn't support burning the lock fuse, or I haven't found a way to do it, so I've been using pyupdi for all my lockbit needs.

I am running on Raspberry PI using GPIO 14 & 15, i.e. pins 8,10, using 4.7k resistor between TX and RX. I get the following output:

$ python pyupdi.py -d tiny814 -c /dev/ttyAMA0 -e -f firmware.hex -v
INFO:phy Opening /dev/ttyAMA0 at 115200 baud
INFO:phy send : [0x0]
INFO:phy incorrect echo : [0x0]
Traceback (most recent call last):
File "pyupdi.py", line 160, in
_main()
File "pyupdi.py", line 90, in _main
device=Device(args.device))
File "/home/pi/Documents/PY/updi/nvm.py", line 17, in init
self.application = UpdiApplication(comport, baud, device)
File "/home/pi/Documents/PY/updi/application.py", line 17, in init
self.datalink = UpdiDatalink(comport, baud)
File "/home/pi/Documents/PY/updi/link.py", line 20, in init
self.updi_phy = UpdiPhysical(comport, baud)
File "/home/pi/Documents/PY/updi/physical.py", line 30, in init
self.send([constants.UPDI_BREAK])
File "/home/pi/Documents/PY/updi/physical.py", line 85, in send
raise Exception("Incorrect echo data")
Exception: Incorrect echo data

I checked the Tx and Rx line with a scope and confirmed a 88usec logic "0" pulse, which I think is the 0x0 being sent at 115200 baud. But the output says: INFO:phy incorrect echo : [0x0]. Why is that incorrect echo ? A 0x0 is sent, the echo is 0x0.

Hi, we've been using pyupdi to program ATTiny devices from an i.MX6 SL. This works for our development, but we'd like to avoid running having to include/run python on the linux board.

I've looked at the updi/physical.py implementation that uses pyserial to establish a serial port connection, and believe it should be possible to implement a "remote serial port connection" by exposing the serial port over tcp/ip using ser2net. I imagine we could implement a common UpdiConnection interface that is basically, send, receive, sib, and send_double_break, which UpdiPhysical and a potential UpdiSer2Net could both implement. This would allow updi/link.py to remain unchanged in how it uses the UpdiConnection interface, and just allow the constructor to configure whether it creates a physical connection or a remote connection over tcp/ip.

I have a couple questions

• Does this sound like a reasonable approach and thing to do? I'm not too familiar with serial/tty devices, but my understanding is that this should work
• Does this sound like something you'd be interested in taking upstream? We haven't done the work yet, but plan on taking it on for our own purposes. I'm happy to open a pull request once it's functional and we can discuss the implementation approach in more detail.

Thanks!

Hi, Mraardvark:
Thank for your Python code of UPDI interface programming. I'm Pitter Liao from MICROCHIP/ATMEL, I made a C version of this program based on your program and extend the interface include Save flash data to hex file, operating memory ... ， so it could be embedded into client upper computer, I attached the link here:

https://github.com/PitterL/cupdi.git

Is your driver recognized by Atmel Studio?

I am unclear on running the driver. Will it work in Win 10 64b by simply running it from python?

Which version of python?

Any idea of this works with the new attiny414 family?

Thanks.

Traceback (most recent call last):
File "/usr/local/bin/pyupdi", line 8, in
sys.exit(_main())
File "/usr/local/lib/python3.8/dist-packages/updi/pyupdi.py", line 111, in _main
if not _process(nvm, args):
File "/usr/local/lib/python3.8/dist-packages/updi/pyupdi.py", line 136, in _process
return _flash_file(nvm, args.flash)
File "/usr/local/lib/python3.8/dist-packages/updi/pyupdi.py", line 151, in _flash_file
nvm.write_flash(start_address, data)
File "/usr/local/lib/python3.8/dist-packages/updi/nvm.py", line 111, in write_flash
return self._write_mem(address, data, self.device.flash_pagesize, use_word_access=True)
File "/usr/local/lib/python3.8/dist-packages/updi/nvm.py", line 133, in _write_mem
self.application.write_nvm(address, page, use_word_access=use_word_access)
TypeError: write_nvm_v1() got an unexpected keyword argument 'use_word_access'
INFO:phy Closing port '/dev/ttyUSB0'
make: *** [makefile:18: upload] Error 1

I found your program, and based on this idee i devellopped a small interface board to be used as a Serial interface / Programmer for all processors with a UPDI interface.
It is basic, does not support High Voltage reset for the ATTiny devices in case the UPDI pin is fused to be used for i/o or reset, but it can be used in to modes: USB Serial device, for sending/receiving data, and Programming mode: Used to program a UPDI microprocessor.
The principle is very simple: After power up, the device acts as a normal serial interface, it even handles the RTS line (not DTR) to generate a reset puls for Arduino style boards.
To put the board in Programming mode, a special sequence must be followed:

1. Open the serial port, with RTS Off (+5v).
2. Start a BREAK
3. Set RTS ON (0 volt)
4. Clear break
   The serial port pins are now connected to the UPDI interface, and programming can be done.
   To end programming simply set RTS OFF (+5Volt), this will end programming mode, and will reactivate the normal serial interface function.
   I included a ZIP file with the schematics and a short explanation. If you are interested I can also send you a working prototype of the PCB. (Still working om improvements, but this prototype is tested and it works. In order to make this board fully supported by your program some extra code has to be put in the program to handle the programming mode sequence and end-of-program sequence. This will not effect the working of your program.
   More details in the attached ZIP file

UPDI Project.zip

In your send command for Physical.py, your pyserial read appears to add an additional 1 second delay between sent bytes. Not sure if its needed. I was able to reproduce it on multiple devices

Line 83

Echo

self.ser.read()

trying to program ATtiny402
seem to be able to run
python3 pyupdi.py -d tiny402 -c /dev/ttyUSB0 -e
to Erase the chip
but when running

python3 pyupdi.py -d tiny402 -c /dev/ttyUSB0 -v -f SbusSwitchATtiny.hex

INFO:phy Opening /dev/ttyUSB0 at 115200 baud
INFO:phy send : [0x0]
INFO:link STCS to 0x03
INFO:phy send : [0x55, 0xc3, 0x8]
INFO:link STCS to 0x02
INFO:phy send : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send : [0x55, 0x80]
INFO:phy receive : []
INFO:link UPDI not OK - reinitialisation required
INFO:phy Sending double break
INFO:phy Opening /dev/ttyUSB0 at 115200 baud
INFO:link STCS to 0x03
INFO:phy send : [0x55, 0xc3, 0x8]
INFO:link STCS to 0x02
INFO:phy send : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send : [0x55, 0x80]
INFO:phy receive : [0x20]
INFO:link UPDI init OK
INFO:nvm Entering NVM programming mode
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0x82]
INFO:app Entering NVM programming mode
INFO:link Writing key
INFO:phy send : [0x55, 0xe0]
INFO:phy send : [0x20, 0x67, 0x6f, 0x72, 0x50, 0x4d, 0x56, 0x4e]
INFO:link LDCS from 0x07
INFO:phy send : [0x55, 0x87]
INFO:phy receive : [0x10]
INFO:app Key status = 0x10
INFO:app Apply reset
INFO:link STCS to 0x08
INFO:phy send : [0x55, 0xc8, 0x59]
INFO:app Release reset
INFO:link STCS to 0x08
INFO:phy send : [0x55, 0xc8, 0x0]
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0x21]
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0x8]
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0x8]
INFO:app Now in NVM programming mode
INFO:nvm Reading device info
INFO:phy send : [0x55, 0xe5]
INFO:app SIB read out as: b'tinyAVR P:0D:0-3'
INFO:app Family ID = b'tinyAVR'
INFO:app NVM revision = 48
INFO:app OCD revision = 48
INFO:app PDI OSC = 51MHz
INFO:link LDCS from 0x00
INFO:phy send : [0x55, 0x80]
INFO:phy receive : [0x20]
INFO:app PDI revision = 0x2
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0x8]
INFO:app Reading 3 bytes from 0x1100
INFO:link ST to ptr
INFO:phy send : [0x55, 0x69, 0x0, 0x11]
INFO:phy receive : [0x40]
INFO:link Repeat 3
INFO:phy send : [0x55, 0xa1, 0x2, 0x0]
INFO:link LD8 from ptr++
INFO:phy send : [0x55, 0x24]
INFO:phy receive : [0x1e, 0x92, 0x25]
INFO:app Reading 1 bytes from 0x0F01
INFO:link ST to ptr
INFO:phy send : [0x55, 0x69, 0x1, 0xf]
INFO:phy receive : [0x40]
INFO:link LD8 from ptr++
INFO:phy send : [0x55, 0x24]
INFO:phy receive : [0x1]
INFO:app Device ID = 1E9225 rev B
INFO:nvm Loading from hexfile 'SbusSwitchATtiny.hex'
INFO:nvm Loaded 3317 bytes from ihex starting at address 0x2000
INFO:nvm Adjusting flash offset to address 0x8000
INFO:app Chip erase using NVM CTRL
INFO:app Wait flash ready
INFO:link LD from 0x1002
INFO:phy send : [0x55, 0x4, 0x2, 0x10]
INFO:phy receive : [0x0]
INFO:app NVMCMD 5 executing
INFO:link ST to 0x1000
INFO:phy send : [0x55, 0x44, 0x0, 0x10]
INFO:phy receive : [0x40]
INFO:phy send : [0x5]
INFO:phy receive : [0x40]
INFO:app Wait flash ready
INFO:link LD from 0x1002
INFO:phy send : [0x55, 0x4, 0x2, 0x10]
INFO:phy receive : [0x0]
INFO:nvm Padding to blocksize 64 with 0xFF
INFO:nvm Paging into 64 byte blocks
INFO:nvm Writing page at 0xA000
INFO:app Wait flash ready
INFO:link LD from 0x1002
INFO:phy send : [0x55, 0x4, 0x2, 0x10]
INFO:phy receive : [0x0]
INFO:app Clear page buffer
INFO:app NVMCMD 4 executing
INFO:link ST to 0x1000
INFO:phy send : [0x55, 0x44, 0x0, 0x10]
INFO:phy receive : [0x40]
INFO:phy send : [0x4]
INFO:phy receive : [0x40]
INFO:app Wait flash ready
INFO:link LD from 0x1002
INFO:phy send : [0x55, 0x4, 0x2, 0x10]
INFO:phy receive : [0x0]
INFO:link ST to ptr
INFO:phy send : [0x55, 0x69, 0x0, 0xa0]
INFO:phy receive : [0x40]
INFO:link Repeat 32
INFO:phy send : [0x55, 0xa1, 0x1f, 0x0]
INFO:link ST16 to *ptr++
INFO:phy send : [0x55, 0x65, 0x19, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x33, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x32, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x31, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x30, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x2f, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x2e, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x2d, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x2c, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x2b, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x2a, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x29, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x28, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x27, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x26, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x25, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x24, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x23, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x22, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x21, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x20, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x1f, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x4f, 0xc5]
INFO:phy receive : [0x40]
INFO:phy send : [0x77, 0xc5]
INFO:phy receive : [0x40]
INFO:phy send : [0x1c, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x1b, 0xc0]
INFO:phy receive : [0x40]
INFO:phy send : [0x11, 0x24]
INFO:phy receive : [0x40]
INFO:phy send : [0x1f, 0xbe]
INFO:phy receive : [0x40]
INFO:phy send : [0xcf, 0xef]
INFO:phy receive : [0x40]
INFO:phy send : [0xcd, 0xbf]
INFO:phy receive : [0x40]
INFO:phy send : [0xdf, 0xe3]
INFO:phy receive : [0x40]
INFO:phy send : [0xde, 0xbf]
INFO:phy receive : [0x40]
INFO:app Committing page
INFO:app NVMCMD 1 executing
INFO:link ST to 0x1000
INFO:phy send : [0x55, 0x44, 0x0, 0x10]
INFO:phy receive : [0x40]
INFO:phy send : [0x1]
INFO:phy receive : [0x40]
INFO:app Wait flash ready
INFO:link LD from 0x1002
INFO:phy send : [0x55, 0x4, 0x2, 0x10]
INFO:phy receive : [0x4]
INFO:app NVM error
Traceback (most recent call last):
File "pyupdi.py", line 157, in
_main()
File "pyupdi.py", line 98, in _main
if not _process(nvm, args):
File "pyupdi.py", line 122, in _process
return _flash_file(nvm, args.flash)
File "pyupdi.py", line 132, in _flash_file
nvm.write_flash(start_address, data)
File "./pyupdi/updi/nvm.py", line 106, in write_flash
self.application.write_nvm(address, page)
File "./pyupdi/updi/application.py", line 267, in write_nvm
raise Exception("Timeout waiting for flash ready after page write ")
INFO:phy Closing /dev/ttyUSB0

Would you guys have any thoughts on adding some debugging functions? I'd be willing to try to implement it and do some initial dogfooding, I'd just like to know if that's a feature you guys would be willing to include it in your library, and if you had any thoughts on how it should be designed

Hi,
I'm trying to write a hex on ATtiny1604 using pyupdi.py but getting "INFO:link UPDI not OK"
The host OS is Windows10
The serial adapter is USB -> TTL.

$ pyupdi.py -d tiny1604 -c COM4 -b 9600 -f Blink.ino.hex -v
INFO:phy Opening COM4 at 9600 baud
INFO:phy send 1 bytes
INFO:phy data: : [0x0]
INFO:link STCS 0x08 to 0x03
INFO:phy send 3 bytes
INFO:phy data: : [0x55, 0xc3, 0x8]
INFO:link STCS 0x80 to 0x02
INFO:phy send 3 bytes
INFO:phy data: : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send 2 bytes
INFO:phy data: : [0x55, 0x80]
INFO:phy receive : []
INFO:link UPDI not OK - reinitialisation required
INFO:phy Sending double break
INFO:phy Opening COM4 at 9600 baud
INFO:link STCS 0x08 to 0x03
INFO:phy send 3 bytes
INFO:phy data: : [0x55, 0xc3, 0x8]
INFO:link STCS 0x80 to 0x02
INFO:phy send 3 bytes
INFO:phy data: : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send 2 bytes
INFO:phy data: : [0x55, 0x80]
INFO:phy receive : []
INFO:link UPDI not OK - reinitialisation required
Traceback (most recent call last):
File "C:\python\pyupdi-master\pyupdi.py", line 182, in
_main()
File "C:\python\pyupdi-master\pyupdi.py", line 95, in _main
nvm = UpdiNvmProgrammer(comport=args.comport,
File "C:\python\pyupdi-master\updi\nvm.py", line 17, in init
self.application = UpdiApplication(comport, baud, device)
File "C:\python\pyupdi-master\updi\application.py", line 17, in init
self.datalink = UpdiDatalink(comport, baud)
File "C:\python\pyupdi-master\updi\link.py", line 32, in init
raise Exception("UPDI initialisation failed")
Exception: UPDI initialisation failed
INFO:phy Closing port 'COM4'

What I am doing incorrect? Seems it supposed to work for tiny1604

Hi Folks,

Can anyone help me with following error screen shots?

Setup TTL to uart converter: CH340G
TX connected to RX with 4.7K connected to UPDI (PIN6)
VCC of UART & ATT402 shorted to 5V
GND: ATT402 shorted to TTL GND

At power on, connecting a momentary pulse of 12V to UPDI pin and then running following command

command: python pyupdi.py -d tiny402 -f att402.hex -c COM4 -v
result:
INFO:phy Opening COM4 at 115200 baud
INFO:phy send 1 bytes
INFO:phy data: : [0x0]
INFO:link STCS 0x08 to 0x03
INFO:phy send 3 bytes
INFO:phy data: : [0x55, 0xc3, 0x8]
INFO:link STCS 0x80 to 0x02
INFO:phy send 3 bytes
INFO:phy data: : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send 2 bytes
INFO:phy data: : [0x55, 0x80]
INFO:phy receive : []
INFO:link UPDI not OK - reinitialisation required
INFO:phy Sending double break
INFO:phy Opening COM4 at 115200 baud
INFO:link STCS 0x08 to 0x03
INFO:phy send 3 bytes
INFO:phy data: : [0x55, 0xc3, 0x8]
INFO:link STCS 0x80 to 0x02
INFO:phy send 3 bytes
INFO:phy data: : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send 2 bytes
INFO:phy data: : [0x55, 0x80]
INFO:phy receive : []
INFO:link UPDI not OK - reinitialisation required
Traceback (most recent call last):
File "pyupdi.py", line 182, in
_main()
File "pyupdi.py", line 95, in _main
nvm = UpdiNvmProgrammer(comport=args.comport,
File "..\pyupdi\updi\nvm.py", line 17, in init
self.application = UpdiApplication(comport, baud, device)
File "..\pyupdi\updi\application.py", line 17, in init
self.datalink = UpdiDatalink(comport, baud)
File "..\pyupdi\updi\link.py", line 32, in init
raise Exception("UPDI initialisation failed")
Exception: UPDI initialisation failed
INFO:phy Closing port 'COM4'

Hi is there a support for the atmega1609?
Will it work if I add parameters in the device.py ?

AVR-DA has a vastly different NVM block to previous AVR UPDI devices. For example flash writes are word-oriented and there is no page buffer.
In addition there is the need to access 128k parts, which means enabling 24-bit UPDI mode for these parts.

Hello, I read the readme file and I am looking to program atmega 4809 which uses updi as a programming method. Also using Platformio IDE. When I look at the pyupdi circuit diagram, it looks like an FTDI board on the left, but my question is, could an arduino be used instead of the FTDI? If it's possible to use an Arduino Uno, what software would be needed on the Uno?

thanks for help with this.
Paul

right now its a mess, and should use subclasses for the 16 and 24 bit UPDI modes as well as the two NVM controllers

Writing an hex file with a non zero base (example 0x200, as produced by the Arduino IDE) on Attiny814 results in verify errors, as it is read back from (0x8000), the base address of the flash (pyupdi:154), not the offset address passed as parameter and calculated at nvm:217
Changing the line pyupdy:154 to
readback = nvm.read_flash(start_address, len(data))
solves the problem apparently.

Hi there,

First off - thanks for writing and publishing this. It has been a great help to me in writing my own UPDI-talking code.

I would like to draw your attention to a curious quirk of the way the chips work, that can sometimes be hard to get out of. I discussed it on

https://www.avrfreaks.net/forum/attiny814-not-accepting-nvmprog-key#comment-2706166

but in summary: if you write a bad fuse value to SYSCFG0 it requires you to load both CHIPERASE and NVMPROG keys at the same time before you issue the system reset request, in order to get out of it.

I have a added an option to do that to my own code, you may wish to add similar to yours.

I've recently updated my pyupdi copy and see that the tx echo check was removed. This was the major source of failures for me in the past.

Now it still happens from time to time that the read verification reports incorrect bytes. Often just one or two, sometimes a lot more. I've hacked the code in a way that it just tries reading it all a second time if something was incorrect. And then, it often works without any errors, or sometimes with another number of wrong bytes at other positions.

So the read verification doesn't seem to be very reliable either. I'm thinking about changing the code so that it re-reads the failed pages once again, and also re-writes these pages if the error persists. The idea is to make the flash process reliable with minimal NVM write wear.

Is this something you'd be interested in? Could you give me some hints about how to do that? I've never written anything in Python before so I'll have to figure out the syntax and language basics on the way. (I already started this for my first pull request here today.)

I'm just starting with the ATtiny 1-series and tried my first program today. I'm using an ATtiny 1614 that I just unpacked and soldered to an adapter PCB. The USB-serial-adapter is an FT232RL that you get from online sellers. It shows up in Windows 10 as COM6. I've set things up as explained and tried to upload the compiled executable. I'm using Atmel Studio 7 and have written a simple program that should enable an output pin. I've connected an LED through a resistor to it to see the result. The integration in Atmel Studio didn't work. First it actually ran pyupdi and told me I missed to install the serial module. I installed that and Atmel Studio would from then on never try to run pyupdi again. So I'm doing this on the command line now.

After installing more dependencies, the output now looks like this:

>python C:\Source\Mikrocontroller\pyupdi\pyupdi.py -d tiny1614 -c COM6 -f ATTinyTest1.hex
Device is locked. Performing unlock with chip erase.
Traceback (most recent call last):
  File "C:\Source\Mikrocontroller\pyupdi\pyupdi.py", line 98, in _main
    nvm.enter_progmode()
  File "C:\Source\Mikrocontroller\pyupdi\updi\nvm.py", line 34, in enter_progmode
    if self.application.enter_progmode():
  File "C:\Source\Mikrocontroller\pyupdi\updi\application.py", line 129, in enter_progmode
    raise Exception("Failed to enter NVM programming mode")
Exception: Failed to enter NVM programming mode

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Source\Mikrocontroller\pyupdi\pyupdi.py", line 178, in <module>
    _main()
  File "C:\Source\Mikrocontroller\pyupdi\pyupdi.py", line 101, in _main
    nvm.unlock_device()
  File "C:\Source\Mikrocontroller\pyupdi\updi\nvm.py", line 54, in unlock_device
    self.application.unlock()
  File "C:\Source\Mikrocontroller\pyupdi\updi\application.py", line 89, in unlock
    raise Exception("Failed to chip erase using key")
Exception: Failed to chip erase using key

What does that mean? What should I do next?

Any chance of we can see support for 16k devices in the future?
Attiny1614, 1617 and their big brother 3217...

Maybe I'm misusing the application, but I'm running into the following error when I attempt to program an ATtiny1614 via a Teensy 3.2 as a serial adapter.

Error below:

INFO:phy Opening COM8 at 115200 baud
INFO:phy send : [0x0]
INFO:link STCS to 0x03
INFO:phy send : [0x55, 0xc3, 0x8]
INFO:link STCS to 0x02
INFO:phy send : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send : [0x55, 0x80]
INFO:phy receive : [0x30]
INFO:link UPDI init OK
INFO:nvm Entering NVM programming mode
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0x35]
INFO:app Entering NVM programming mode
INFO:link Writing key
INFO:phy send : [0x55, 0xe0]
INFO:phy send : [0x20, 0x67, 0x6f, 0x72, 0x50, 0x4d, 0x56, 0x4e]
INFO:link LDCS from 0x07
INFO:phy send : [0x55, 0x87]
INFO:phy receive : [0x30]
INFO:app Key status = 0x30
INFO:app Apply reset
INFO:link STCS to 0x08
INFO:phy send : [0x55, 0xc8, 0x59]
INFO:app Release reset
INFO:link STCS to 0x08
INFO:phy send : [0x55, 0xc8, 0x0]
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0xd]
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0x33]
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0x31]
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0xa]
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0xd]
INFO:app Now in NVM programming mode
INFO:nvm Reading device info
INFO:phy send : [0x55, 0xe5]
INFO:app SIB read out as: b'6\r\n'
INFO:app Family ID = b'6\r\n'
Traceback (most recent call last):
  File "C:\Users\NeruA\Desktop\ATtiny1614 programming\pyupdi-master\pyupdi.py", line 157, in <module>
    _main()
  File "C:\Users\NeruA\Desktop\ATtiny1614 programming\pyupdi-master\pyupdi.py", line 96, in _main
    nvm.get_device_info()
  File "C:\Users\NeruA\Desktop\ATtiny1614 programming\pyupdi-master\updi\nvm.py", line 27, in get_device_info
    return self.application.device_info()
  File "C:\Users\NeruA\Desktop\ATtiny1614 programming\pyupdi-master\updi\application.py", line 29, in device_info
    self.logger.info("NVM revision = {}".format(sib[10]))
IndexError: index out of range
INFO:phy Closing COM8

Teensy configuration:

#define Uart Serial2

void setup()
{
  Uart.begin(115200);
  Serial.begin(115200);
}

void loop() {
  byte usb_data;
  byte uart_data;
  if (Serial.available() > 0) {
    usb_data = Serial.read();
    Uart.println(usb_data);
  }
    

  if (Uart.available() > 0) {
    uart_data = Uart.read();
    Serial.println(uart_data);
  }
}

Wiring:

Hi
I'm using a CH330N as serial chip an connected rxd and txd with a 4.7k resistor as described.
When communicating with the attiny3217 over pyupdi it always needs to reinitialize no matter what baud rate. The 2nd attempt always works, but it makes the process to flash quite slow.
Any hints what I could try?
Here the output:

INFO:phy Opening /dev/cu.wchusbserial1430 at 115200 baud
INFO:phy send 1 bytes
INFO:phy data:  : [0x0]
INFO:link STCS 0x08 to 0x03
INFO:phy send 3 bytes
INFO:phy data:  : [0x55, 0xc3, 0x8]
INFO:link STCS 0x80 to 0x02
INFO:phy send 3 bytes
INFO:phy data:  : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send 2 bytes
INFO:phy data:  : [0x55, 0x80]
INFO:phy receive : []
INFO:link UPDI not OK - reinitialisation required
INFO:phy Sending double break
INFO:phy Opening /dev/cu.wchusbserial1430 at 115200 baud
INFO:link STCS 0x08 to 0x03
INFO:phy send 3 bytes
INFO:phy data:  : [0x55, 0xc3, 0x8]
INFO:link STCS 0x80 to 0x02
INFO:phy send 3 bytes
INFO:phy data:  : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send 2 bytes
INFO:phy data:  : [0x55, 0x80]
INFO:phy receive : [0x40]
INFO:link UPDI init OK
...

Hi,
I'm trying to program with pyupdi an Attiny817 on a Attiny-Explained-M demoboard (http://ww1.microchip.com/downloads/en/DeviceDoc/50002657A.pdf);

I'm using Python 2.7 on a Linux machine and when I launch pyupdi the program hangs after
some seconds...

./pyupdi.py -d tiny817 -c /dev/ttyUSB0  -e -v
INFO:phy Opening /dev/ttyUSB0 at 115200 baud
INFO:phy send : [0x0]
INFO:link STCS to 0x03
INFO:phy send : [0x55, 0xc3, 0x8]
INFO:link STCS to 0x02
INFO:phy send : [0x55, 0xc2, 0x80]
INFO:link LDCS from 0x00
INFO:phy send : [0x55, 0x80]
INFO:phy receive : []
INFO:link UPDI not OK - reinitialisation required
INFO:phy Sending double break

can you give me some hints on what to investigate on ?

the board works properly if programmed by Atmel software suite or by UPDI with jtag2updi
software (https://github.com/ElTangas/jtag2updi)

Thanks,
Gennaro

Hi

I maintain megaTinyCore ( https://github.com/SpenceKonde/megaTinyCore ) which lets these parts be used through the Arduino IDE. Right now we are telling people to use a jtag2updi firmware on a nano/promini/etc to program these parts. This looks like a great solution in terms of not needing additional hardware, just a serial adapter. I would like to make it possible to use this programming method from the Arduino IDE - I see two approaches.

Am I correct in concluding that we can't bully AVRDude into doing this?

That would mean that we would, instead need to create a new "tool" for this. Is there a way to make a self-contained version of pyupdi that board manager could pull in with tools_dependencies (ie, will work without having to install a python runtime or anything else)? my understanding is that if that were possible, I could have my core pull that in upon installation and have a programmer option that would use pyupdi to upload with just a serial port.

Thanks

Hello,

may I ask how the programmer works internally? Normally there is a read process after writing to check. "Verify Flash after Programming".
The Tx data are however passed on as far as I see 1:1 to the Rx pin by means of a resistor. Is it possible to install a real read test? Or is that withheld from the hardware programmers?

I'm delighted to find pyupdi; I'm looking at options for making embedded interfaces. I've got it working through an FTDI FT230X, but not through the preferred solution of an ATSAMD11C running a USB-UART bridge. I'd like to review what pyupdi needs to be able to configure in the serial interface that's being missed by the simple byte bridge code I tested.

For integration with other tools that uses avr-gcc and Avrdude (Like Arduino IDE and PlatformIO) would be great if pyupdi supported the same target names as avr-gcc and Avrdude uses.

In other words, it would be great if we also could refer to chips as atmega4809 and not just mega4809.

As you can see in the PlatformIO configuration for pyupdi uploads below, mega4809 actually has to be "manually" specified in the upload flags. It would be much more elegant if it could use the underlying atmega4809 name instead so I could refer to the chip with ${board_build.mcu} instead.

[env:pyupdi_upload]
platform = atmelmegaavr
framework = arduino
board = ATmega4809
upload_speed = 115200
upload_flags =
  -d
  mega4809
  -c
  $UPLOAD_PORT
  -b
  $UPLOAD_SPEED
upload_command = pyupdi $UPLOAD_FLAGS -f $SOURCE

Would you accept a PR where "extra" attiny and atmega targets are added in device.py?

Hi,

When using pyupdi to flash a ATtiny1614 using a SAMD11C, I experienced some very specific bug forcing me to send data in chunks smaller than 64 bytes. I documented the issue here:
http://fabacademy.org/2020/labs/ulb/students/quentin-bolsee/projects/d11c_ftdi-updi/#arduino-core

I propose the following patch to handle this kind of issue:
chunk_patch.txt

Basically, the send() function in physical.py is modified to slice up data in chunks of a given max size. I think it's reasonable to use chunks when waiting for the echo, otherwise you can easily fill up some buffers on the USB serial, leading to strange behaviors.

I know this issue has been raised for different devices, but I feel in my case I have a different condition.
I am using a Raspberry Pi and a FT232R USB UART adapter. The Tiny does not have the UPDI pin configured as an i/o pin. Yet it keeps giving me the error that it failed to be initialized.
I have tried both the GPIO serial and USB2TTL. I changed the GPIO setup according to the link too. but no success.
My terminal output is
python3 pyupdi.py -v -d tiny404 -c /dev/ttyUSB0 -b 115200 -f /home/pi/Desktop/test.hex INFO:phy Opening /dev/ttyUSB0 at 115200 baud INFO:phy send : [0x0] INFO:link STCS to 0x03 INFO:phy send : [0x55, 0xc3, 0x8] INFO:link STCS to 0x02 INFO:phy send : [0x55, 0xc2, 0x80] INFO:link LDCS from 0x00 INFO:phy send : [0x55, 0x80] INFO:phy receive : [] INFO:link UPDI not OK - reinitialisation required INFO:phy Sending double break INFO:phy Opening /dev/ttyUSB0 at 115200 baud INFO:link STCS to 0x03 INFO:phy send : [0x55, 0xc3, 0x8] INFO:link STCS to 0x02 INFO:phy send : [0x55, 0xc2, 0x80] INFO:link LDCS from 0x00 INFO:phy send : [0x55, 0x80] INFO:phy receive : [] INFO:link UPDI not OK - reinitialisation required Traceback (most recent call last): File "pyupdi.py", line 178, in <module> _main() File "pyupdi.py", line 95, in _main device=Device(args.device)) File "/home/pi/Downloads/pyupdi-master/updi/nvm.py", line 17, in __init__ self.application = UpdiApplication(comport, baud, device) File "/home/pi/Downloads/pyupdi-master/updi/application.py", line 17, in __init__ self.datalink = UpdiDatalink(comport, baud) File "/home/pi/Downloads/pyupdi-master/updi/link.py", line 31, in __init__ raise Exception("UPDI initialisation failed") Exception: UPDI initialisation failed INFO:phy Closing /dev/ttyUSB0

Any help or suggestions will be greatly appreciated.

Hi guys, just to inform you that we had the same problems, but the cause wasn't related to the software.
We used some pl2303 usb-serial converters with the 'low' level too high to be reconnized by the Attiny and a really noisy 3v3 power supply (200Khz sawtooth, probably due to the internal DC/DC converte missing cap).
We solved it using a ceramic capacitor between GND and 3v3, that also stabilize the TX and RX voltage.
The Low level was at 1.18 volts. We solved the problem adding a bulk pnp, drived by TX, between the RX line and GND.
After this simple operation everything works great.
I made a simple explanation, with scope details and the used schematic, here:
https://www.xtendsenses.com/en/analisys-of-a-low-quality-usb-serial-converter/

I've got some functionality from the library; I can read info and fuses:

$ python3 pyupdi.py -d tiny1614 -c /dev/ttyUSB0 -fr
Device info: {'family': 'tinyAVR', 'nvm': 'P:0', 'ocd': 'D:0', 'osc': '3', 'device_id': '1E9422', 'device_rev': '0.0'}
Fuse:Value
0:0x00
1:0x00
2:0x02
3:0xFF
4:0x00
5:0xF6
6:0x07
7:0x00
8:0x00
9:0xFF
10:0xC5

But when I go to actually flash my device, it either errors out with Can't decode 0xB6 in position 33: invalid start byte:

$ python3 pyupdi.py -d tiny1614 -c /dev/ttyUSB0 -e -b 9600 -f ./image.elf 
Device info: {'family': 'tinyAVR', 'nvm': 'P:0', 'ocd': 'D:0', 'osc': '3', 'device_id': '1E9422', 'device_rev': '0.0'}
Traceback (most recent call last):
  File "pyupdi.py", line 182, in <module>
    _main()
  File "pyupdi.py", line 109, in _main
    if not _process(nvm, args):
  File "pyupdi.py", line 134, in _process
    return _flash_file(nvm, args.flash)
  File "pyupdi.py", line 142, in _flash_file
    data, start_address = nvm.load_ihex(filename)
  File "/home/kevinv/Documents/Boeing 6652 IPSS/pyupdi/pyupdi/updi/nvm.py", line 168, in load_ihex
    ih.loadhex(filename)
  File "/home/kevinv/.local/lib/python3.7/site-packages/intelhex/__init__.py", line 210, in loadhex
    for s in fobj:
  File "/usr/lib/python3.7/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb6 in position 33: invalid start byte

or if I enable verbose output, it sits in a loop doing

$ python3 pyupdi.py -d tiny1614 -c /dev/ttyUSB0 -e -b 9600 -f ./image.elf -v
....
INFO:phy send 2 bytes
INFO:phy data:  : [0x55, 0x8b]
INFO:phy receive : [0x82]
INFO:app Wait for NVMPROG
INFO:link LDCS from 0x0B

indefinitely. When I hit ctrl-C to break out of this, it shows me Exception: Key not accepted.

What am I doing wrong? Do I have the wrong microcontroller configured in my compiler when I build the ELF file?