mraardvark / pyupdi Goto Github PK
View Code? Open in Web Editor NEWPython UPDI driver for programming "new" tinyAVR and megaAVR devices
License: MIT License
Python UPDI driver for programming "new" tinyAVR and megaAVR devices
License: MIT License
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$
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 ?
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?
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:
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.
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.
Hi is there a support for the atmega1609?
Will it work if I add parameters in the device.py ?
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?
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.
anyone tried it only with one GPIO of raspberry?
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
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
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 modeDuring 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.
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
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:
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.
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.
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
self.ser.read()
right now its a mess, and should use subclasses for the 16 and 24 bit UPDI modes as well as the two NVM controllers
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.
Hello,
What's your project licence please ?
Have a good day
T. Servuc
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.
Any chance of we can see support for 16k devices in the future?
Attiny1614, 1617 and their big brother 3217...
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.
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?
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.)
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.
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'
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:
Teensy | intermediates | ATtiny1614 |
---|---|---|
GND | -- | GND on 14 |
Rx2 (Pin 9) | -- | UPDI on 10 |
Tx2 (Pin 10) | 4k7 resistor | UPDI on 10 |
3.3v | -- | VDD on 1 |
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
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
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
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?
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.
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
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, 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
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?
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,
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'
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 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/
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.
Support for the ATmega3208/3209/4808/4809 would be great.
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.
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!
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.