mraardvark / pyupdi

Python UPDI driver for programming "new" tinyAVR and megaAVR devices
MIT License
210 stars 73 forks source link

problem with Attiny817 #12

Closed gtortone closed 6 years ago

gtortone commented 6 years ago

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

ajowsey commented 6 years ago

Hey @gtortone. Exact same deal for me.

I disconnected the ISP programming micro and used pyupdi on the 817 directly. No response. Write messages were verified with a logic analyzer but not reads occur. Not sure if the tiny is unable to pull the line low or something...

I reconnected the ISP and scoped its signals. They are nearly identical. Except the chip uses [0x55, 0x43, 0x88] instead of [0x55, 0xc3, 0x8]. I modded pyupdi to do that sts write afterwards but still no response from the chip. The ISP programmer continues to work as well so I know its not a hardware failure.

Did you have any luck?

gtortone commented 6 years ago

Hi @ajowsey, no, I have not any good news on pyupdi on Attiny817...

I switched to jtag2updi (https://github.com/ElTangas/jtag2updi) because on the same board I have an ATMEGA328P.

wmzart commented 6 years ago

I had success with flashing an Attiny817 on ubuntu 16.04 Prerequisites

Flashing:

The first time the flashing did not work. I got the same error "UPDI not OK - reinitialisation required". To solve this I did the following:

gtortone commented 6 years ago

Him @wmzart, thanks for sharing this, but it does not work for me...

I'm already working with .hex file and output for me is this (also if I convert .hex to ihex):

$ ./pyupdi.py -d tiny817 -c /dev/ttyUSB3 -e -v -f file_ihex.hex 
INFO:phy Opening /dev/ttyUSB3 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
ajowsey commented 6 years ago

@wmzart That's really good to hear. Can you detail what you are using for your serial from your dev machine? I've tried with with Rpi uart pins and 3v3 FTDI. Resistor included.

@gtortone Based on my logic analyzer, that verbose output is just saying the chip hasnt isnt pulling the UPDI line low in response.

wmzart commented 6 years ago

I use a USB TTL Adapter with PL-2303HX chipset, Art-Nr.: RB-TTL from JOY-iT Europe GmbH,

dmesg output:

[ 2237.956079] usb 6-1: new full-speed USB device number 5 using uhci_hcd
[ 2238.117064] usb 6-1: New USB device found, idVendor=067b, idProduct=2303
[ 2238.117070] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2238.117074] usb 6-1: Product: USB-Serial Controller
[ 2238.117078] usb 6-1: Manufacturer: Prolific Technology Inc.
[ 2238.119137] pl2303 6-1:1.0: pl2303 converter detected
[ 2238.131265] usb 6-1: pl2303 converter now attached to ttyUSB0

The controller is marked as ATMEL AT817F

A picture of the hardware: img_20180710_124956

The UPDI pin from the controller is directly connected to the USB TTL Adapter, as shown in the schematics at the picture. There is no pull-up or pull-down on the circuit board.

For flashing I created a simple script, so I can reproduce easily:

#!/bin/sh
cd pyupdi
./pyupdi.py -d tiny817 -c /dev/ttyUSB0 -e -v -f ../output.hex

After powering on, I waited somewhere between 3 to 10 seconds and then issued the command from above. Also, the power for the controller is not taken from the USB TTL Adapter, but taken from a separated power supply. The whole procedure I repeated 5 times, for 5 circuit boards in total. All of them flashed instantaneously without any error.

The output I got while flashing:

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 : [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 : [0x1]        <--- THIS BLOCK REPEATS ABOUT 12 TIMES
INFO:link LDCS from 0x0B        <--- =================================
...
INFO:phy send : [0x55, 0x8b]
INFO:link LDCS from 0x0B
INFO:phy send : [0x55, 0x8b]
INFO:phy receive : [0x1]
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: tinyAVR P:0D:0-3
INFO:app Family ID = tinyAVR
INFO:app NVM revision = 0
INFO:app OCD revision = 0
INFO:app PDI OSC = 3MHz
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, 0x93, 0x20]
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 = 1E9320 rev B
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 Loading from hexfile '../output.hex'
INFO:nvm Loaded 3370 bytes from ihex starting at address 0x0000
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]
...
...
...
Programming successful
INFO:nvm Leaving NVM programming mode
INFO:app Leaving NVM programming mode
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 STCS to 0x03
INFO:phy send : [0x55, 0xc3, 0xc]
INFO:phy Closing /dev/ttyUSB0
mraardvark commented 6 years ago

I have fixed what I think could cause failure to recover using double-break mechanism (see branch).
Tested on linux with py27 using tiny817-xmini with TX strapped to RX with 4k7 and RX wired to PA0. Worth a try at least...

ajowsey commented 6 years ago

That fixed my problem!

Thanks!

mraardvark commented 6 years ago

Good to hear!