Atmel Studio Compatible?

[MadTooler]

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.

[mraardvark]

Hi MadTooler,

Good question. Studio support was not the intention here, but it should be possible to setup an "External Tool" in Studio which makes it call pyupdi. I will give it a try myself when I have some time.

pyupdi should work on any OS where Python can access a CDC/Virtual COM port. Its tested on py27 only.

Tiny414 is not in there, but tweak the parameters in device.py and it will work - all of these parts have essentially the same UPDI interface.

[MadTooler]

Thanks!

I will tinker around when I have a few PCBs made up and see what happens.

Please update any results that you may find.

[dingdinglhz]

Have you got it working? I have been trying but could not get it to work.
I am using windows 10 with a standard USB-COM adapter, running python 3, and trying to flash a attinty1614, on a board I made myself. 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"

[MadTooler]

I have not had the opportunity to try. I may pick up on of the Ice programmers to save some time for now, but I would like to see this work for others to help extend the list of those developing.

[aimylios]

I have set up pyupdi as a Custom Programming Tool in Atmel Studio 7.0.1931 on Windows 7.

Under Project -> Properties -> Tool select Custom Programming Tool and then add the command how to call pyupdi on your system.

Both the serial port (e.g., COM22) and the device name (e.g., tiny412) need to be hardcoded. I would prefer to use the environment variable $(avrdevice), but it evaluates to the full device name (e.g., ATtiny412) instead of the abbreviated name which is expected by pyupdi (e.g., tiny412). At least the path to the HEX file can be substituted with $(OutputDirectory)\$(OutputFileName).hex.

You can now program your device via Debug -> Start Without Debugging.

Executing Custom tool:
       Command: C:\Python27\python.exe D:\PUBLIC\pyupdi\pyupdi.py -d tiny412 -c COM22 -f D:\PRIVATE\Test\ATtiny412_Test\Release\ATtiny412_Test.hex
       Parsed executable: C:\Python27\python.exe
       Parsed arguments: D:\PUBLIC\pyupdi\pyupdi.py -d tiny412 -c COM22 -f D:\PRIVATE\Test\ATtiny412_Test\Release\ATtiny412_Test.hex
Process exited with code 0
[stdout] Programming successful

[MadTooler]

I finally am trying this for myself. Here is what I have:

Windows 10, Atmel Studio 7.0.1931, attiny414

custom programming tool command:
C:\Python27\python.exe C:\pyupdi\pyupdi.py -d tiny414 -c COM3 -f $(OutputDirectory)$(OutputFileName).hex

and I am getting the error:
[stderr] pyupdi.py: error: unrecognized arguments: (my hex file here)

Also, I am not sure how/where to view the more indepth outputs... well, I added "-v" and I think I found something more useful:

Executing Custom tool:
	Command: C:\Python27\python.exe C:\pyupdi\pyupdi.py -v -d tiny414 -c COM3 -f C:\Users\JMT\Documents\Atmel Studio\7.0\First414project\First414project\Debug\First414project.hex
	Parsed executable: C:\Python27\python.exe
	Parsed arguments: C:\pyupdi\pyupdi.py -v -d tiny414 -c COM3 -f C:\Users\JMT\Documents\Atmel Studio\7.0\First414project\First414project\Debug\First414project.hex
Process exited with code 2
[stderr] usage: pyupdi.py [-h] -d
[stderr]                  {mega3208,mega3209,mega4808,mega4809,tiny1614,tiny1616,tiny1617,tiny202,tiny204,tiny212,tiny214,tiny3216,tiny3217,tiny402,tiny404,tiny406,tiny412,tiny414,tiny416,tiny417,tiny814,tiny816,tiny817}
[stderr]                  -c COMPORT [-e] [-b BAUDRATE] [-f FLASH] [-r]
[stderr]                  [-fs [FUSES [FUSES ...]]] [-v]
[stderr] pyupdi.py: error: unrecognized arguments: Studio\7.0\First414project\First414project\Debug\First414project.hex

[MadTooler]

Well, figured out it was throwing the error because of the "Atmel Studio" file location with a space in the folder name. Removed the space and it went a little further. Now I get this error that I assume is a port issue:

Executing Custom tool:
	Command: C:\Python27\python.exe C:\pyupdi\pyupdi.py -v -d tiny414 -c COM3 -f C:\Users\JMT\Documents\AtmelStudio\7.0\First414project\First414project\Debug\First414project.hex
	Parsed executable: C:\Python27\python.exe
	Parsed arguments: C:\pyupdi\pyupdi.py -v -d tiny414 -c COM3 -f C:\Users\JMT\Documents\AtmelStudio\7.0\First414project\First414project\Debug\First414project.hex
[stderr] INFO:phy Opening COM3 at 115200 baud
[stderr] INFO:phy send : [0x0]
[stderr] INFO:phy incorrect echo : [0xff]
[stderr] Traceback (most recent call last):
[stderr]   File "C:\pyupdi\pyupdi.py", line 160, in <module>
[stderr]     _main()
[stderr]   File "C:\pyupdi\pyupdi.py", line 90, in _main
[stderr]     device=Device(args.device))
[stderr]   File "C:\pyupdi\updi\nvm.py", line 17, in __init__
[stderr]     self.application = UpdiApplication(comport, baud, device)
[stderr]   File "C:\pyupdi\updi\application.py", line 17, in __init__
[stderr]     self.datalink = UpdiDatalink(comport, baud)
[stderr]   File "C:\pyupdi\updi\link.py", line 20, in __init__
[stderr]     self.updi_phy = UpdiPhysical(comport, baud)
[stderr]   File "C:\pyupdi\updi\physical.py", line 30, in __init__
[stderr]     self.send([constants.UPDI_BREAK])
[stderr]   File "C:\pyupdi\updi\physical.py", line 85, in send
[stderr]     raise Exception("Incorrect echo data")
[stderr] Exception: Incorrect echo data
[stderr] INFO:phy Closing COM3
Process exited with code 1

[mraardvark]

Each character sent should be received as well since RX and TX are joined with a resistor. The echo error suggests that data sent is not being read...

[MadTooler]

I am using an FTDI based USB cable. I have had it attached to my scope the whole time and also have noticed no output.

[MadTooler]

Further testing with the scope shows what appears as a single pulse low of about 85us with nothing further.

With the 4.7k resistor, the RX side is above a volt (with 3.3 vcc). I tried a lower resistor to pull it further closer to the TX, but it still gives the same errors.

THEN, I tried it on python 3.7. Same errors as with 2.7 with the 4.7k resistor. With a 3K resistor, Success!

[mraardvark]

Ah, nice.
Various USB-COM adapters might have different output capabilities. (I use mainly the CDC on the Atmel Xplained / Microchip Curiosity boards.)