This is my first time post, so there might be something difficult to understand.
And I'm not good at English. Sorry.
I had used ATtiny1614 with Arduino Nano (old bootloader) which is installed jtag2updi
on Windows 10.
Once I was able to upload program to ATtiny1614 successfully.
But one day, I suddenly got unable to write program to ATtiny.
Since then, I have not been able to upload program.
Did I brick ATtiny ? What should I do ?
Here's the error I got when I uploaded.
avrdude: Version 6.3-20201216
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/avrdude.conf"
avrdude: warning at C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/avrdude.conf:16457: part t3217 overwrites previous definition C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/avrdude.conf:16002.
Using Port : COM6
Using Programmer : jtag2updi
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
S_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
Serial number: 00:00:00:00:00:00
Device ID: JTAGICE mkII
AVR Part : ATtiny1614
Chip Erase delay : 0 us
PAGEL : P00
BS2 : P00
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 0
StabDelay : 0
CmdexeDelay : 0
SyncLoops : 0
ByteDelay : 0
PollIndex : 0
PollValue : 0x00
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 61 61 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 10 0 0 0 0x00 0x00
fuse0 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse1 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse2 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse4 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse5 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse6 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse7 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse8 0 0 0 0 no 1 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 0 0 0x00 0x00
data 0 0 0 0 no 0 0 0 0 0 0x00 0x00
usersig 0 0 0 0 no 32 32 0 0 0 0x00 0x00
flash 0 0 0 0 no 16384 64 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 256 32 0 0 0 0x00 0x00
Programmer Type : JTAGMKII_PDI
Description : JTAGv2 to UPDI bridge
M_MCU hardware version: 1
M_MCU firmware version: 6.00
S_MCU hardware version: 1
S_MCU firmware version: 6.00
Serial number: 00:00:00:00:00:00
Vtarget : 5.0 V
avrdude: jtagmkII_initialize(): Cannot locate "flash" and "boot" memories in description
avrdude: jtagmkII_reset(): timeout/error communicating with programmer (status -1)
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude: jtagmkII_close(): timeout/error communicating with programmer (status -1)
avrdude: jtagmkII_close(): timeout/error communicating with programmer (status -1)
avrdude done. Thank you.
Thank you for introducing this page.
Acutually I knew jtag2updi is not recommended,
but I didn't want to use other method, because extra cost can't be spent.
So I am searching for solutions to solve this trouble.
Should I give up using jtag2updi and use other ways ?
I did and for precisely the reasons reported by you. That is, its mysterious and unpredictable behaviour.
You may still be able to use your old Nano though as a USB/UART adapter if you haven't got one of these for the newer SerialUPDI method. It may depend on the clone etc. but you may be able to connect its Reset to GND and use the TX/RX for SerialUPDI. Regard the TX/RX labels as reversed in this case. But no guarantees and if anyone contradicts this suggestion, listen to them attentively.
I tried SerialUPDI at 57600 baud,
but I got following error.
SerialUPDI
UPDI programming for Arduino using a serial adapter
Based on pymcuprog, with significant modifications
By Quentin Bolsee and Spence Konde
Version 1.2.0 - June 2021
Using serial port COM5 at 57600 baud.
Target: attiny1614
Set fuses: ['2:0x02', '6:0x04', '8:0x00']
Action: write
File: C:\Users\~myUserName~\AppData\Local\Temp\arduino_build_170053/attiny1614_blink.ino.hex
Traceback (most recent call last):
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/tools/prog.py", line 282, in <module>
main()
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/tools/prog.py", line 131, in main
return_code = pymcuprog_basic(args, fuses_dict)
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4/tools/prog.py", line 198, in pymcuprog_basic
args_start)
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\pymcuprog_main.py", line 544, in _start_session
backend.start_session(sessionconfig)
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\backend.py", line 362, in start_session
sessionconfig.interface_speed)
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\programmer.py", line 83, in setup_device
options=self.options)
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\nvm.py", line 42, in get_nvm_access_provider
accessprovider = NvmAccessProviderSerial(transport, device_info, baud=frequency)
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\nvmserialupdi.py", line 53, in __init__
self.avr = UpdiApplication(port, baud, self.dut)
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\serialupdi\application.py", line 79, in __init__
datalink.init_datalink()
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\serialupdi\link.py", line 41, in init_datalink
self.updi_phy.send_double_break()
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\pymcuprog\serialupdi\physical.py", line 96, in send_double_break
temporary_serial.read(1)
File "C:\Users\~myUserName~\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.5.4\tools\libs\serial\serialwin32.py", line 293, in read
raise SerialException("GetOverlappedResult failed ({!r})".format(ctypes.WinError()))
serial.serialutil.SerialException: GetOverlappedResult failed (PermissionError(13, '�A�N�Z�X�����ۂ���܂����B', None, 5))
serial.serialutil.SerialException: GetOverlappedResult failed (PermissionError(13, '�A�N�Z�X�����ۂ���܂����B', None, 5))
I can't really interpret that traceback but ensure that the serial monitor is closed and the port you've chosen under Tools/Port in the IDE is correct.
If you get nowhere, show a diagram (picture of a hand drawn schematic) of exactly the connections you have made between the USB/UART device and the ATtiny1614 including the labelling of the pins, the values of the components used in between (diodes, resistors etc.).
If you are using the Nano as a USB/UART
(1) The TX/RX pins should be reversed because the labelling refers to the ATmega328P, not the CH340 (or other USB/UART chip) which is what you are interested in here.
(2) The reset pin should be grounded.
(3) state its USB/UART chip type.
The TX/RX pins should be reversed because the labelling refers to the ATmega328P, not the CH340 (or other USB/UART chip) which is what you are interested in here.
So, what should I do?
I appreciate if you explain that with the schematic above.
This schematic http://actrl.cz/blog/wp-content/uploads/nano_ch340_schematics-rev1.pdf could relate to your Nano clone. It is the best I could find during a quick search but is by no means ideal because it they have insisted on explicitly and laboriously showing every connection as a wire, instead of using net labels, resulting in a horrid tangled mess. The good thing that the component labelling is readable.
Anyway, since you are using (misusing) your Nano as a USB/UART adaptor, you are not interested in the ATMEGA328P. If you follow, for example, the path from the TxD pin on the CH340G, which you are interested in, to where is ends up on a header pin, you will find the header pin marked RxD. That is why I said that the labelling is reversed.
So, specifically in answer to your question, if your labelling of Tx and Rx refers to the white silk screen printing on the Nano board, consider it to be reversed and move the resistor and connecting wire accordingly.
You haven't shown a diode. My only experience is with a diode. Not only that, it should be a Schottky diode. A Schottky diode has a forward voltage of about 0.3 volts. Diodes such as a 1n4148 are not Schottky and have a forward voltage of about 0.7volts. These may not work correctly. Having said that, @DrAzzy has a few alternative connection models with only resistors so you may get lucky.
Also, if you want to use a capacitor instead of shorting reset to grounds, ensure there is no sketch in the Nano which could interfere with RX/TX.
I couldn't jump to the attached URL, sorry.
Thank you for telling me that diode is necessary.
I didn't know that.
Adding to this,
Also, if you want to use a capacitor instead of shorting reset to grounds, ensure there is no sketch in the Nano which could interfere with RX/TX.
You mean I should remove capacitor and connect reset to GND, right?
And, since I would like to use Nano as Serial converter, should I upload blank program (meaning that no command was written in source code) to Nano?
That is how I would do it. The capacitor method could also work but then there should be no sketch loaded onto the Nano which would interfere with the TX or RX. A blank sketch would be ideal.
I would not expect a jury rigged nano used as a serial adapter to work for SerialUPDI. Not without removing parts from the pcb and replacing some of them with jumpers. It has a resistor in series with each data line. And an led driven directly by each data like. The former would need to be replaced with jumpers and the latter removed.. Serial adapters are under a dollar each, yo.. or $2 for ones that dont look so shoddily built.... I buy them 5+ at a time,
Oh yes. This gives me a bad feeling of déjà vu so I have just tried some experiments. The "conclusion" is that it might work or might not, depending on the clone (and possibly other factors).
The generic clone appears to match the schematic in an earlier post here. I can't find a usable schematic for the RobotDyn which does appear to work. I can generally say it is a higher quality with a real crystal, two big voltage regulators and a much more fully populated board that the generic clone.
I'm not going to do it here, but I am reasonably sure (based on a memory of some previous experience) that removing the TX/RX Leds (or their series resistors) from the generic clone would make it work for this.
The best advice is to use a purpose made USB/UART adaptor.
edit
The RobotDyn clone has blue leds for the RX/TX activity. The generic clone has red leds. That could just tip it because of the difference in the forward voltage.
