Remember that for other ATtinys than the ATtiny402, this may not work in the same way. You will have to work out your own chip's VCC, GND and UPDI pins but they probably won't look too different to the setup here
We're following the same setup as shown in the jtag2updi repository, except that V_target = V_programmer. This doesn't always have to be the case but you will need to take care about logic levels if your V_prog and V_tgt are significantly different. One microcontroller's 1 can be another's 0... ElTangas hasn't tried it with logic level converters according to the link above but while we are programming the chips at 5V and the components around them can handle 5V, we don't need to worry.
Just for clarity on the ATtiny402:
- Arduino GND -> ATtiny402 GND = pin 8
- Arduino 5V -> ATtiny402 VCC = pin 1
- Arduino D6 -> 4.7k resistor -> ATtiny402 pin 6
Open up a command prompt (I'm using Win10, so you will have to adapt this to another OS you may be using). If you haven't done this before, it's easily done by typing command into the Windows search/magnifying glass bar in the bottom left of the desktop, next to the Windows button:
When you click on the Command Prompt app, it will launch into something like a white text on black background saying something like:
Microsoft Windows [Version 10.0.17763.475] (c) 2018 Microsoft Corporation. All rights reserved. C:\Users\"YOUR_PROFILE_NAME">
Where YOUR_PROFILE_NAME is the account name you use on Windows. This isn't where we installed avrdude.exe (the application file) to, so we need to go there now before we can use it. To do this, type:
cd c:\avrdude
(or wherever you installed avrdude to) and press enter.
Don't forget to plug in your Arduino to a USB port and confirm which COM port it is connected to, either using the Arduino IDE or looking in Windows Device Manager. Remember this from an earlier step:
In my case, we were uploading to the Arduino Nano on COM 6. We'll need this now.
The first check we're going to do is read the device signature and check if it is locked for programming. We should find a new chip unlocked for programming and there is a troubleshooting step for locked chips at the jtag2updi repository. The avrdude programme runs on text commands from the command prompt. We type in a string of characters and it interprets these as detailed commands about what you want the programme to try and do. To try an initial communication with the chip and find out if it is locked, we type:
avrdude -c jtag2updi -P com6 -p t402
Where:
- "avrdude" starts the programme
- "-c jtag2updi" sets the programming interface type
- "-P com6" is the COM port we are asking to connect to the chip over (capitals make a difference in avrdude letter commands)
- "-p t402" means the part we are trying to talk to. In the avrdude.conf file, an ATtiny402 is given the nickname "t402" to save typing effort in the avrdude command string!
Here's my command and this is the response I got....
c:\avrdude>avrdude -c jtag2updi -P com6 -p t402 avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.31s avrdude: Device signature = 0x1e9225 (probably t406) avrdude: Expected signature for ATtiny402 is 1E 92 27 Double check chip, or use -F to override this check. avrdude done. Thank you.
Oh dear. What kind of chip have I connected? In this state, avrdude won't let me upload code because it thinks I have made a mistake and connected a different chip. Uploading code compiled for the ATtiny402 to a different chip could brick it, so avrdude is trying to protect me from bricking my attached chip. On the plus side, the Arduino Nano with jtag2updi loaded and avrdude controlling them were able to read the device signature - HOORAY!
You may remember me prattling on about hardware bugs in a previous step - this is one of them. Some of the ATtiny402 chips that Microchip has sent out and sold don't have the right device signature burned into their memory. The datasheet says they should be:
So avrdude is correct when it is looking for 0x1e9227 or 1E 92 27. Sadly my chip and maybe yours is suffering from the wrong device signature. In order to program ATtiny402 chips with signature 1E 92 25, I wrote a workaround in the avrdude.conf file and thankfully ElTangas has incorporated it into the jtag2updi repository, so if you download your avrdude.conf from there, it will include the option for a "new" part, called ATtiny402 Workaround, nicknamed for avrdude as "t402w". The workaround was really simple and you can see what I did here:
Back to achieving comms with our chip. With the new command for the t402w, this is what I get:
c:\avrdude>avrdude -c jtag2updi -P com6 -p t402w avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.32s avrdude: Device signature = 0x1e9225 (probably t406) avrdude done. Thank you.
Perfect - this is what we want! We can go home now.
But we don't want to stop here, do we? We want to get adventurous and satisfy ourselves that not only can we read the chip's device signature but we can bend the internal memory to our will! How about a blink programme?
So making sure we also connect:
ATtiny402 pin 2 (Port A, Pin 6 in the ATtiny402 internal map) -> 220ohm or higher resistor -> LED -> GND
We can try to upload a hex file that I have already compiled for you (to save diverting into Atmel Studio for now - that's coming later). I have saved the hex file in the project files and you can download it here.
Now save it in the folder where avrdude.exe lives. This time, we need some separate commands to try and upload a file, although you will recognise some elements from our first foray with the chip signature retrieval:
avrdude -c jtag2updi -P com6 -p t402w -U flash:w:ATtiny402_PA6_blink_1s.hex
- "-U" tells avrdude to perform a memory operation
- "flash:" says it's going to be performed on the flash memory, where programs live!
- "w:" says it's going to be a write (as opposed to e.g. read) operation
- "ATtiny402_PA6_blink_1s.hex" is the file we want avrdude to write to the flash memory
Here are my Command Prompt command and results:
c:\avrdude>avrdude -c jtag2updi -P com6 -p t402w -U flash:w:ATtiny402_PA6_blink_1s.hex avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.32s avrdude: Device signature = 0x1e9225 (probably t406) avrdude: NOTE: Programmer supports page erase for Xmega devices. Each page will be erased before programming it, but no chip erase is performed. To disable page erases, specify the -D option; for a chip-erase, use the -e option. avrdude: reading input file "ATtiny402_PA6_blink_1s.hex" avrdude: input file ATtiny402_PA6_blink_1s.hex auto detected as Intel Hex avrdude: writing flash (126 bytes): Writing | ################################################## | 100% 0.06s avrdude: 126 bytes of flash written avrdude: verifying flash memory against ATtiny402_PA6_blink_1s.hex: avrdude: load data flash data from input file ATtiny402_PA6_blink_1s.hex: avrdude: input file ATtiny402_PA6_blink_1s.hex auto detected as Intel Hex avrdude: input file ATtiny402_PA6_blink_1s.hex contains 126 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 0.04s avrdude: verifying ... avrdude: 126 bytes of flash verified avrdude done. Thank you.
All looks good so far and here's the verification that it worked!
In future, we'll learn how to do the basics in Atmel Studio, so you can upload your own program and also connect the hardware programmer to Atmel Studio, speeding up your code/upload/refactor/re-upload iterations.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Why not simply adding -F flag to avrdude?
Are you sure? yes | no
Thanks ever so much - I have been scratching round trying to get to grips with these ATtiny series 0 and 1 MCUs - specifically t402.
I bolstered up the courage to glue one to an 8 pin through hole adaptor and followed your very clear description.
I'm confident I'll get there now as I am a previous Studio 7 user (ATtiny13a / ATtiny85) and have already managed to set up a USBASP as an external programmer on this (I wish there was a Pololu ISP programmer equivalent for UPDI - as this is almost plug and play with a nice fuse reading / setting GUI).
I got the your blinky to fly from the AVRDUE command line via an Uno I had lying around. But my ATtiny402 returned an ID of 1E9221 - I added to your t402w method and it worked but I noticed that there is already an entry for this code as t416 and this is the device it feeds back on command line.
I guess this is not serious as blinky flew OK.
I am real keen to use these devices - I have a v low power app in mind and the events thing and RTC seem to be where I need to go.
I know where I want to run but I can't even crawl yet.
I've seen articles about using modified serial programmers in place of Arduinos - could you aim me at any you rate?
Thanks again.
Peter
Are you sure? yes | no
Many thanks .
Are you sure? yes | no