Closed mcuee closed 1 year ago
For example, with the xml files from the archive here, the original Microchip AVROSP.exe seems to work with ATmega328P (quite slow though). I verified with USBASP as well. https://avr.ru/tools/avrosp https://avr.ru/int/Files/Dounload/instruments/AvrOspII.rar
PS C:\work\avr\avrdude_test\others\avr910\AVR911\bin> .\AVROSP -dATmega328p -ofm328p -rf
AVR Open-source Programmer $Revision: 1163 $ (C) 2004 Atmel Corp.
Serial port timeout set to 5 sec.
Scanning COM ports for supported programmer...
COM1...
COM2...
COM3...
COM4...
COM5...
Found AVR ISP on COM5!
Entering programming mode...
Parsing XML file for device parameters...
Parsing '.\ATmega328p.xml'...
#################################
...
Saving cached XML parameters...
Signature matches device!
Reading Flash contents...
#################################
...
Writing HEX output file...
#################################
...
Leaving programming mode...
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -qqp m328p
-U flash:v:m328p.hex:i && echo OK
OK
The xml files from this github repo has even more parts (193 parts, including xmega parts). https://github.com/Mes-ser/xplained-easy-config
c:\work\avr\avrdude_test\others\avr910\AVR911\bin>ls *.xml
AT86RF401.xml ATmega164PA.xml ATmega32U6.xml ATtiny25.xml
AT89S51.xml ATmega165.xml ATmega406.xml ATtiny26.xml
AT89S52.xml ATmega165A.xml ATmega48.xml ATtiny261.xml
AT90CAN128.xml ATmega165P.xml ATmega48A.xml ATtiny261A.xml
AT90CAN32.xml ATmega165PA.xml ATmega48P.xml ATtiny28.xml
AT90CAN64.xml ATmega168.xml ATmega48PA.xml ATtiny4.xml
AT90PWM1.xml ATmega168A.xml ATmega64.xml ATtiny40.xml
AT90PWM2.xml ATmega168P.xml ATmega640.xml ATtiny4313.xml
AT90PWM216.xml ATmega168PA.xml ATmega644.xml ATtiny43U.xml
AT90PWM2B.xml ATmega169.xml ATmega644A.xml ATtiny44.xml
AT90PWM3.xml ATmega169A.xml ATmega644P.xml ATtiny44A.xml
AT90PWM316.xml ATmega169P.xml ATmega644PA.xml ATtiny45.xml
AT90PWM3B.xml ATmega169PA.xml ATmega645.xml ATtiny461.xml
AT90PWM81.xml ATmega16A.xml ATmega6450.xml ATtiny461A.xml
AT90S1200.xml ATmega16HVA.xml ATmega6450A.xml ATtiny48.xml
AT90S2313.xml ATmega16HVA2.xml ATmega645A.xml ATtiny5.xml
AT90S2323.xml ATmega16HVB.xml ATmega649.xml ATtiny84.xml
AT90S2343.xml ATmega16M1.xml ATmega6490.xml ATtiny84A.xml
AT90S4414.xml ATmega16U2.xml ATmega6490A.xml ATtiny85.xml
AT90S4433.xml ATmega16U4.xml ATmega649A.xml ATtiny861.xml
AT90S4434.xml ATmega2560.xml ATmega649P.xml ATtiny861A.xml
AT90S8515.xml ATmega2561.xml ATmega64A.xml ATtiny87.xml
AT90S8515comp.xml ATmega32.xml ATmega64C1.xml ATtiny88.xml
AT90S8535.xml ATmega323.xml ATmega64HVE.xml ATtiny9.xml
AT90S8535comp.xml ATmega324A.xml ATmega64M1.xml ATxmega128A1.xml
AT90SCR100H.xml ATmega324P.xml ATmega8.xml ATxmega128A3.xml
AT90USB1286.xml ATmega324PA.xml ATmega8515.xml ATxmega128A3U.xml
AT90USB1287.xml ATmega325.xml ATmega8535.xml ATxmega128D3.xml
AT90USB162.xml ATmega3250.xml ATmega88.xml ATxmega16A4.xml
AT90USB646.xml ATmega3250P.xml ATmega88A.xml ATxmega16A4U.xml
AT90USB647.xml ATmega3250PA.xml ATmega88P.xml ATxmega16D4.xml
AT90USB82.xml ATmega325A.xml ATmega88PA.xml ATxmega192A3.xml
ATA6289.xml ATmega325P.xml ATmega8A.xml ATxmega192A3U.xml
ATmega103.xml ATmega325PA.xml ATmega8HVA.xml ATxmega192D3.xml
ATmega103comp.xml ATmega328.xml ATmega8U2.xml ATxmega256A3.xml
ATmega128.xml ATmega328P.xml ATtiny10.xml ATxmega256A3B.xml
ATmega1280.xml ATmega329.xml ATtiny11.xml ATxmega256A3BU.xml
ATmega1281.xml ATmega3290.xml ATtiny12.xml ATxmega256A3U.xml
ATmega1284.xml ATmega3290P.xml ATtiny13.xml ATxmega256D3.xml
ATmega1284P.xml ATmega3290PA.xml ATtiny13A.xml ATxmega32A4.xml
ATmega128A.xml ATmega329A.xml ATtiny15.xml ATxmega32A4U.xml
ATmega128RFA1.xml ATmega329P.xml ATtiny1634.xml ATxmega32D4.xml
ATmega16.xml ATmega329PA.xml ATtiny167.xml ATxmega64A1.xml
ATmega161.xml ATmega32A.xml ATtiny20.xml ATxmega64A3.xml
ATmega161comp.xml ATmega32C1.xml ATtiny22.xml ATxmega64A3U.xml
ATmega162.xml ATmega32HVB.xml ATtiny2313.xml ATxmega64D3.xml
ATmega163.xml ATmega32M1.xml ATtiny2313A.xml
ATmega164A.xml ATmega32U2.xml ATtiny24.xml
ATmega164P.xml ATmega32U4.xml ATtiny24A.xml
@dl8dtl
I understand that AVR910 based programmers have largely been replaced with more modern programmers (eg: USBASP, USBtinyISP, etc), even though AVR109 based bootloaders seem to be still popular (but not as popular as STK500v1/v2 based bootloaders).
If you think there is no point doing this, then I will close the issue as not planned.
Well, I have no real opinion on that. The only AVR910 programmer I know of is the bootloader (actually, a separate chip, used to be AT90S1200, later ATtiny2313) on the STK500.
If one can still by them at Aliexpress, it might be worth the while. Biggest issue IIRC is that the protocol uses a single byte to identify the target controller, and that single ID byte has only ever been standardized for very old AVRs.
I bought the serial AVR910 from AliExpress: the thing is rather cheap but shipping is rather expensive compared to the part cost. The good thing is that there is a jumper for you to upgrade the FW of the ATtiny2313. https://www.aliexpress.com/item/555008131.html
BTW, I bought the other three low cost items from the same shop. 1) SI-Prog from the same shop and it seems to work with avrdude as well. https://www.aliexpress.com/item/555027336.html
2) The STK500v2 clone is not bad and works fine, using CH340C (built-in oscillator), 74HC165D and the main MCU ATmega8535 (same main MCU as the real STK500). https://www.aliexpress.com/item/554989751.html
3) Then I also got the low cost cheap AVRISP mkii compatible
programmer from the same shop and expect it to be a low cost ATmega8A based clone and expected not work under Windows 10/11. And indeed it is true (using ATmega8A and low speed CDC-ACM V-USB based implemenation). It seems to work under Linux though. Not really worth buying -- I am just getting it for curiosity.
https://www.aliexpress.com/item/32687012093.html
Pictures of the 4.
BTW, I have ordered another USB AVR910 from Taobao and it is quite a bit more expensive (still on the way). I believe it is similar to the following AliExpress item and based on ATmega8535. Not really worth buying -- I am just getting it for testing avrdude. https://www.aliexpress.com/item/1267121534.html
I think we should make sure we at least can support targets that have an "established" AVR910 device code.
@mcuee do you know if there exist other AVR910 implementations other than the official one?
avrdude.conf.in contains a list of various AVR910 device codes. However, it seems like some devices have multiple device codes. I'm not sure what's correct here.
Here's what I suggest we do:
avr910_devcode
lines, and perhaps update the header where all the device codes are listed.From avrdude.conf:
# The following table lists the devices in the original AVR910
# appnote:
# |Device |Signature | Code |
# +-------+----------+------+
# |tiny12 | 1E 90 05 | 0x55 |
# |tiny15 | 1E 90 06 | 0x56 |
# | | | |
# | S1200 | 1E 90 01 | 0x13 |
# | | | |
# | S2313 | 1E 91 01 | 0x20 |
# | S2323 | 1E 91 02 | 0x48 |
# | S2333 | 1E 91 05 | 0x34 |
# | S2343 | 1E 91 03 | 0x4C |
# | | | |
# | S4414 | 1E 92 01 | 0x28 |
# | S4433 | 1E 92 03 | 0x30 |
# | S4434 | 1E 92 02 | 0x6C |
# | | | |
# | S8515 | 1E 93 01 | 0x38 |
# | S8535 | 1E 93 03 | 0x68 |
# | | | |
# |mega32 | 1E 95 01 | 0x72 |
# |mega83 | 1E 93 05 | 0x65 |
# |mega103| 1E 97 01 | 0x41 |
# |mega161| 1E 94 01 | 0x60 |
# |mega163| 1E 94 02 | 0x64 |
# Appnote AVR109 also has a table of AVR910 device codes, which
# lists:
# dev avr910 signature
# ATmega8 0x77 0x1E 0x93 0x07
# ATmega8515 0x3B 0x1E 0x93 0x06
# ATmega8535 0x6A 0x1E 0x93 0x08
# ATmega16 0x75 0x1E 0x94 0x03
# ATmega162 0x63 0x1E 0x94 0x04
# ATmega163 0x66 0x1E 0x94 0x02
# ATmega169 0x79 0x1E 0x94 0x05
# ATmega32 0x7F 0x1E 0x95 0x02
# ATmega323 0x73 0x1E 0x95 0x01
# ATmega64 0x46 0x1E 0x96 0x02
# ATmega128 0x44 0x1E 0x97 0x02
#
# These codes refer to "BOOT" device codes which are apparently
# different than standard device codes, for whatever reasons
# (often one above the standard code).
# There are several extended versions of AVR910 implementations around
# in the Internet. These add the following codes (only devices that
# actually exist are listed):
# ATmega8515 0x3A
# ATmega128 0x43
# ATmega64 0x45
# ATtiny26 0x5E
# ATmega8535 0x69
# ATmega32 0x72
# ATmega16 0x74
# ATmega8 0x76
# ATmega169 0x78
I think we should make sure we at least can support targets that have an "established" AVR910 device code.
@mcuee do you know if there exist other AVR910 implementations other than the official one?
I think most of the AVR910 implemnetations are quite closely based on the official one mentioned above in terms of both core HW (AVR910 AN Figure 4-1) and FW. HW Eg: https://mechatronics.me.wisc.edu/labresources/schemsNmans/STK500_Schematics.pdf (Page6/7): AVR910 implemetation in STK500 using AT90S1200/ATtiny2313. This is for the FW upgrade/downgrade of the main AT90S8535/ATmega8535. FW Eg: https://sourceforge.net/projects/avr10-firmware/
In terms of HW, there are new ones with USB to Serial converter to replace the serial interface. Then there are some implementations with a bit more features like opto isolation. Most of them still use AT90S1200/ATtiny2313. Eg: http://www.deep-shadows.com/hax/wordpress/?page_id=793 (opto isolated)
There are also V-USB based implementation using ATmega8/8A/8L. This kind of implementation will usually not working under Windows 10/11 due to the use of low speed bulk transfer (USB CDC-ACM, not compliant to USB spec) even though they may work with Linux. I am not so sure if any of them use USB HID to work under Windows 10/11. https://simplemetaldetector.com/programmers/avr-910-programmer/ https://320volt.com/en/avr910-usb-avr-programlayici-ponyprog/ Ref on avrcdc: http://www.recursion.jp/prose/avrcdc/
Very rare high cost implementation is based on USB Serial chip plus ATmega8535. This is very much similar to STK500 already and I was quite surprised to see such implementation from a Chinese vendor (which also produce the STK500 High Voltage programmer based on either ATmega8535 or an STC 8051 MCU). That is why I ordered it even though they raised the price by about about US$3 due to chip shortage.
In terms of PC application, the original official one from Atmel is AVRprog.exe
in AVR Studio 3.x and 4.x. Atmel kept it for the FW upgrading of tools like STK500 and JTAG ICE 1. I was actullly using it today trying to revive my dead JTAG ICE 1 clone (FW seems to be corrupted) but unfortunately failed.
Then after that there is the official AVR911 (AVROSP) PC application from Atmel, and other implementations like AVROSP2. It seems that quite some xml files have been created for AVROSP, as shown here. https://github.com/Mes-ser/xplained-easy-config
I've created a simple table where I've gathered all known AVR910 device codes. It looks like no part has more than two known device codes, and all of them are unique, which definitely helps. The problem is that the AVR910 programmer has to be aware of all the device codes.
Target | Official devcode | Alternative devcode 1 | Alternative devcode 2 |
---|---|---|---|
AT90S1200 | 0x13 | ||
AT90S2313 | 0x20 | ||
AT90S2323 | 0x48 | ||
AT90S2333 | 0x34 | ||
AT90S2343 | 0x4C | ||
AT90S4414 | 0x28 | ||
AT90S4433 | 0x30 | ||
AT90S4434 | 0x6C | ||
AT90S8515 | 0x38 | ||
AT90S8535 | 0x68 | ||
ATmega8 | 0x77 | 0x76 | |
ATmega16 | 0x75 | 0x74 | |
ATmega32 | 0x72 | 0x7F | |
ATmega64 | 0x46 | 0x45 | |
ATmega83 | 0x65 | ||
ATmega103 | 0x41 | ||
ATmega128 | 0x44 | 0x43 | |
ATmega161 | 0x60 | ||
ATmega162 | 0x63 | ||
ATmega163 | 0x64 | 0x66 | |
ATmega169 | 0x79 | 0x78 | |
ATmega323 | 0x73 | ||
ATmega8515 | 0x3B | 0x3A | |
ATmega8535 | 0x6A | 0x69 | |
ATtiny12 | 0x55 | ||
ATtiny15 | 0x56 | ||
ATtiny26 | 0x5E |
The only AVR910 bootloader alternative I've found is USBVirtualSerial-AVRISP
, which can be downloaded here: https://code.google.com/archive/p/avropendous/downloads
The bootloader can only store 14 device codes, and suggest using Avrdude's -F flag:
From USBVirtualSerial-AVRISP.h
/* AVR Device Codes - Can have a maximum of 14 but can be any you want.
Note that these are completely irrelevent. If AVRdude supports a device,
then that device is programmable. Use -F switch to ignore device codes. */
#define AVRDEVCODE01 0x55 /* ATtiny12 */
#define AVRDEVCODE02 0x56 /* ATtiny15 */
#define AVRDEVCODE03 0x5E /* ATtiny261 */
#define AVRDEVCODE04 0x76 /* ATmega8 */
#define AVRDEVCODE05 0x74 /*ATmega16 */
#define AVRDEVCODE06 0x72 /* ATmega32 */
#define AVRDEVCODE07 0x45 /* ATmega64 */
#define AVRDEVCODE08 0x74 /* ATmega644 */
#define AVRDEVCODE09 0x43 /* ATmega128 */
#define AVRDEVCODE10 0x63 /* ATmega162 */
#define AVRDEVCODE11 0x78 /* ATmega169 */
#define AVRDEVCODE12 0x6C /* AT90S4434 */
#define AVRDEVCODE13 0x38 /* AT90S8515A */
#define AVRDEVCODE14 0x65 /* AT90S8555 */
The original AVRProg.exe seems to have the "BOOT" device mentioned. Probably because it supports both AVR109 and AVR910. Replacement of AVRProg is AVROSP (AVR911).
# These codes refer to "BOOT" device codes which are apparently
# different than standard device codes, for whatever reasons
# (often one above the standard code).
BTW, the following is from AVROSP2 5.47 version (last release from Mike Henning). https://xdevs.com/doc/xDevs.com/M16/AVROSP2/Osp2Boot.asm
It seems to support Osp2 protocol along with AVR911 (AVR109/AVR910). I guess that osp2 bootloader protocol is not popular and not supported by avrdude.
I would love to see avr910 support modern devices with avrdude (instead of using avrospII.exe in windows). IIRC, AVROSPII supports whatever devices are present in your avrstudio installation and updates devicelist.dat based on AVRstudios supported devices.
I can modify the avr910 firmware easily, just knowing what codes to implement for each device or just to satisfy avrdude is the difficult thing for me.
Just got a USB AVR910 programmer and it is actually not too slow.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c avr910 -P COM3 -p m32 -U flash:r:m32demo_usb_avr910_read.hex:i
Found programmer: Id = "AVR ISP"; type = S
Software Version = 3.8; Hardware Version = 1.2
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize = 64 bytes.
Programmer supports the following devices:
Device code: 0x13 = AT90S1200
Device code: 0x20 = AT90S2313
Device code: 0x28 = AT90S4414
Device code: 0x30 = AT90S4433
Device code: 0x34 = AT90S2333
Device code: 0x38 = AT90S8515
Device code: 0x48 = (unknown)
Device code: 0x4c = AT90S2343
Device code: 0x51 = (unknown)
Device code: 0x55 = ATtiny12
Device code: 0x56 = ATtiny15
Device code: 0x68 = AT90S8535
Device code: 0x6c = AT90S4434
Device code: 0xffffff86 = (unknown)
Device code: 0xffffff87 = (unknown)
Device code: 0x01 = (unknown)
Device code: 0x04 = (unknown)
Device code: 0x05 = (unknown)
Device code: 0x06 = (unknown)
Device code: 0x07 = (unknown)
Device code: 0x08 = (unknown)
Device code: 0x09 = (unknown)
Device code: 0x0e = (unknown)
Device code: 0x1a = (unknown)
Device code: 0x0f = (unknown)
Device code: 0x1b = (unknown)
Device code: 0x14 = (unknown)
Device code: 0x1c = (unknown)
Device code: 0x1d = (unknown)
Device code: 0x23 = (unknown)
Device code: 0x31 = (unknown)
Device code: 0x33 = (unknown)
Device code: 0x35 = (unknown)
Device code: 0x37 = (unknown)
Device code: 0x39 = (unknown)
Device code: 0x3d = (unknown)
Device code: 0x3e = (unknown)
Device code: 0x57 = (unknown)
Device code: 0x3a = ATmega8515
Device code: 0x3b = (unknown)
Device code: 0x41 = ATmega103
Device code: 0x43 = ATmega128
Device code: 0x44 = (unknown)
Device code: 0x45 = ATmega64
Device code: 0x46 = (unknown)
Device code: 0x5e = ATtiny26
Device code: 0x60 = ATmega161
Device code: 0x61 = (unknown)
Device code: 0x62 = (unknown)
Device code: 0x63 = ATmega162
Device code: 0x64 = ATmega163
Device code: 0x66 = (unknown)
Device code: 0x69 = ATmega8535
Device code: 0x6a = (unknown)
Device code: 0x72 = ATmega32
Device code: 0x73 = (unknown)
Device code: 0x74 = ATmega16
Device code: 0x75 = ATmega329
Device code: 0x76 = ATmega8
Device code: 0x77 = (unknown)
Device code: 0x78 = ATmega169
Device code: 0x79 = (unknown)
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude.exe: Device signature = 0x1e9502 (probably m32)
avrdude.exe: reading flash memory ...
Reading | ################################################## | 100% 19.79s
avrdude.exe: writing output file m32demo_usb_avr910_read.hex
avrdude.exe done. Thank you.
@mcuee do have the source code or at least a list of the targets the programmer supports, so we can figure out what all the unknown targets are?
As I stated in a previous post, a single part may have one or two device codes. It would be great if Avrdude could support both, and send the one the programmer wants. However, How can Avrdude know what code the programmer wants if there's more than one to choose from?
For instance, @mcuee's programmer supports 0x76 (atmega8), but also 0x77 (unknown, but probably atmega8?).
The latest source code I've seen for avr910 is V38B and it's in asm. Looking at the post above it appears that is the version in the programmer you just received.
I understand the reason avrospII programs modern devices using an avr910 programmer is because it ignores the device codes sent out from the avr910 programmer and uses the universal 4 bytes SPI packets.
So correct me if I am wrong, I think the only way to make this work is to modify avrdude to program the same way (like avrospII).
@MCUdude I am trying to get the source codes of my USB AVR910 programmer -- the vendor is telling me they will send me the codes soon. As for the chips it supports, then the vendor is basically saying that I can use two applications. 1) AVRprog from Atmel Studio, with very limit chip support (supported by the vendor) 2) avrosp or similar -- not supported by the vendor
There are many different avr910 firmware codes, most of them are following Microchip and use AT90S1200/ATtiny2313.
The one I find from Microchip is probably version 23 for AT90S1200. I belive they use the same code and hex file for the ATtiny2313 when they upgrade the HW for STK500 (AT90S1200--> ATtiny2313; AT90S8535 --> ATmega8535).
;***************************************************************************
;*
;* Title : AVR ISP (Auto adr inc, 19200bps)
;* Version : 2.3
;* Last updated : 13 mar 2000 (arodland)
;* Target : AT90S1200
;* File : avr910.asm
;* Author(s) : Ole Saether, Terje Frostad,
;* Ingar Fredriksen, Morten W. Lund
;* Haakon Skar, Paal Kastnes
;*
;* DESCRIPTION
;* The firmware on all programmers now support a unified protocol for
;* program and data memory programming. The host computer do not need
;* to know if the programmer operates in serial or parallel mode.
;*
;* The following commands are supported. All commands start with a
;* single letter. The programmer returns 13d (carriage return) or the
;* data read after the command is finished.
;*
;* +-------------+------------+------+
;* Commands | Host writes | Host reads | |
;* -------- +-----+-------+------+-----+ |
;* | ID | data | data | | Note |
;* +-----------------------------------+-----+-------+------+-----+------+
;* | Enter programming mode | 'P' | | | 13d | 1 |
;* | Report autoincrement address | 'a' | | | 'Y' | |
;* | Set address | 'A' | ah al | | 13d | 2 |
;* | Write program memory, low byte | 'c' | dd | | 13d | 3 |
;* | Write program memory, high byte | 'C' | dd | | 13d | 3 |
;* | Issue Page Write | 'm' | | | 13d | |
;* | Read program memory | 'R' | |dd(dd)| | 4 |
;* | Write data memory | 'D' | dd | | 13d | |
;* | Read data memory | 'd' | | dd | | |
;* | Chip erase | 'e' | | | 13d | |
;* | Write lock bits | 'l' | dd | | 13d | |
;* | Write fuse bits | 'f' | dd | | 13d | 11 |
;* | Read fuse and lock bits | 'F' | | dd | | 11 |
;* | Leave programming mode | 'L' | | | 13d | 5 |
;* | Select device type | 'T' | dd | | 13d | 6 |
;* | Read signature bytes | 's' | | 3*dd | | |
;* | Return supported device codes | 't' | | n*dd | 00d | 7 |
;* | Return software identifier | 'S' | | s[7] | | 8 |
;* | Return sofware version | 'V' | |dd dd | | 9 |
;* | Return hardware version | 'v' | |dd dd | | 9 |
;* | Return programmer type | 'p' | | dd | | 10 |
;* | Set LED | 'x' | dd | | 13d | 12 |
;* | Clear LED | 'y' | dd | | 13d | 12 |
;* | Universial command | ':' | 3*dd | dd | 13d | |
;* | New universal command | '.' | 4*dd | dd | 13d | |
;* | Special test command | 'Z' | 2*dd | dd | | |
;* +-----------------------------------+-----+-------+------+-----+------+
;*
;* NOTE 1
;* The Enter programming mode command MUST be sent one time prior to
;* the other commands, with the exception of the 't', 'S', 'V', 'v'
;* and 'T' commands. The 'T' command must be sent before this command
;* (see note 6).
;*
;* For programmers supporting both parallel and serial programming
;* mode this command enters parallel programming mode. For programmers
;* supporting only serial programming mode, this command enters serial
;* programming mode.
;*
;* NOTE 2
;* The ah and al are the high and low order bytes of the address. For
;* parallel programmers this command issues the Load Address Low/High
;* Byte command. For serial programmers the address byte is stored for
;* use by the Read/Write commands.
;*
;* NOTE 3
;* For parallel programmers this command issues the Program Flash
;* command. For serial programmers this command iussues the Write
;* Program Memory Command. For devices with byte-wide program memories
;* only the low byte command should be used.
;*
;* NOTE 4
;* The contents of the program memory at the address given by the 'A'
;* command are written to the serial port in binary form. For byte
;* wide memories one byte is written. For 16 bit memories two bytes
;* are written,MSB first.
;*
;* NOTE 5
;* This command must be executed after the programming is finished.
;*
;* NOTE 6
;* The select device type command must be sent before the enter
;* programming command
;*
;* NOTE 7
;* The supported device codes are returned in binary form terminated
;* by 0x00.
;*
;* NOTE 8
;* This return a 7 character ASCII string identifying the programmer.
;* For the development board it is "AVR DEV", for the parallel
;* programmer it is "AVR PPR" and for the in-curcuit programmer it is
;* "AVR ICP".
;*
;* NOTE 9
;* The software/hardware version are returned as two ASCII numbers.
;*
;* NOTE 10
;* This command should be used to identify the programmer type. The
;* return value is 'S' for serial (or SPI) programmers or 'P' for
;* parallel programmers.
;*
;* NOTE 11
;* The write fuse bits command are available only on parallel
;* programmers and only for AVR devices (device code < 0x80). The host
;* should use the return programmer type command to determine the
;* programmer type, do not use the "AVR PPR" idenifier because other
;* programmers may be available in the future.
;*
;* NOTE 12
;* Currently only the AVR development board has LEDs. The other boards
;* must implement this commands as NOPs.
;*
;* NOTE 13
;* Devices using Page Mode Programming write one page of flash memory
;* before issuing a Page Mode Write Pulse.
;*
;* HISTORY
;* V2.3 00.03.10 (pkastnes) Added support for multiple new devices
;* V2.1 98.10.26 (mlund) New date marking.
;* Removed support for AT90S1200C.
;* Added support for AT90S4433A.
;* V2.0 98.01.06 (mlund) ATmega103 support
;* V1.7 97.11.06 (mlund) Universial command (':') implemented.
;* Releases all pins when not in
;* programming mode.
;* V1.6e 97.11.04 (mlund) mega103 rev D support
;* V1.6c 97.10.30 (mlund) Auto incrementing / SPI sync
;* also works for mega103.
;* V1.6 97.09.09 (hskar) Created Page Mode Version (mega103)
;* V1.5 97.08.21 (mlund) Modified / Bugfix / Major cleanup
;* ... ... (no records)
;* V?.? 97.03.15 (OS) Created
;*
;*
;*
;* Device Support List
;* -------------------
;*
;* +-------+----------+------+-------+------+------+------+-------+
;* |Device |Signature | Code | Flash |EEProm| Lock | Fuse | PMode |
;* +-------+----------+------+-------+------+------+------+-------+
;* |tiny12 | 1E 90 05 | 0x55 | R/W | R/W | R/W | R/W | Byte |
;* |tiny15 | 1E 90 06 | 0x56 | R/W | R/W | R/W | R/W | Byte |
;* | | | | | | | | |
;* | S1200 | 1E 90 01 | 0x13 | R/W | R/W | W | NA | Byte |
;* | | | | | | | | |
;* | S2313 | 1E 91 01 | 0x20 | R/W | R/W | W | NA | Byte |
;* | S2323 | 1E 91 02 | 0x48 | R/W | R/W | R/W | R/W | Byte |
;* | S2333 | 1E 91 05 | 0x34 | R/W | R/W | R/W | R/W | Byte |
;* | S2343 | 1E 91 03 | 0x4C | R/W | R/W | R/W | R/W | Byte |
;* | | | | | | | | |
;* | S4414 | 1E 92 01 | 0x28 | R/W | R/W | W | NA | Byte |
;* | S4433 | 1E 92 03 | 0x30 | R/W | R/W | R/W | R/W | Byte |
;* | S4434 | 1E 92 02 | 0x6C | R/W | R/W | R/W | R/W | Byte |
;* | | | | | | | | |
;* | S8515 | 1E 93 01 | 0x38 | R/W | R/W | W | NA | Byte |
;* | S8535 | 1E 93 03 | 0x68 | R/W | R/W | R/W | R/W | Byte |
;* | | | | | | | | |
;* |mega32 | 1E 95 01 | 0x72 | R/W | R/W | R/W | R/W | Page |
;* |mega83 | 1E 93 05 | 0x65 | R/W | R/W | R/W | R/W | Page |
;* |mega103| 1E 97 01 | 0x41 | R/W | R/W | R/W | R/W | Page |
;* |mega161| 1E 94 01 | 0x60 | R/W | R/W | R/W | R/W | Page |
;* |mega163| 1E 94 02 | 0x64 | R/W | R/W | R/W | R/W | Page |
;* +-------+----------+------+-------+------+------+------+-------+
;*
;* LEGEND:
;* -------
;* Signature - Device Signature Byte
;* Code - Unique device code used by AVRProg to identify device
;* Flash - Flash size in bytes
;* EEProm - EEProm size in bytes
;* Lock - Lockbits
;* Fuse - Fusebits
;* PMode - Indicates if device uses byte or page programming mode
;*
;* R/W - Read and Write Access
;* R - Read Access Only
;* W - Write Access Only
;* NA - Not Accessible
;*
;***************************************************************************
Then there are new FW (latest is v38b, Last updated 26-Feb-2006 ) which is based on Microchip implementations by Klaus Leidinger. https://www.mikrocontroller.net/topic/14812 https://www.mikrocontroller.net/topic/12180 https://www.emsp.tu-berlin.de/fileadmin/fg232/Lehre/PjEle/Tools/avr910_2313_v38b.asm
Then the Sourceforge project "AVR ISP: AVR910 programmer firmware" which seems to be based on the above. https://sourceforge.net/projects/avr10-firmware/files/avr10-firmware/ (v44, 07-Sept-2007)
Then there are other ports -- but most of them seem to be based on Klaus Leidinger's codes.
I agree with @avrfreak, it is probably good to ignore the device codes if we want to support many more chips like avrosp/avrospii.
Just to archive the FW source codes from the above. AVR910_Atmel_v23.zip avr910_2313_v38b.zip avr910_2313_v44.zip
Is this what you want? http://www.prottoss.com/projects/AVR910.usb.prog/avr910_usb_programmer.htm you will have to translate it.
I have the source if you can't find it, I can post it here.
Is this what you want? http://www.prottoss.com/projects/AVR910.usb.prog/avr910_usb_programmer.htm you will have to translate it.
I have the source if you can't find it, I can post it here.
Thanks, I know this one you mentioned and I have downloaded the source as well. Take note it is using V-USB CDC and it will not work under Windows 10/11.
The USB AVR910 programmer I have is different. It is from a Chinese vendor using a proper USB serial chip and ATmega8535. They have STK500 HV programmer clone (using ATmega8535), AVRISP mkii and AVR Dragon clone. But the AVR Dragon clone do not no support of JTAG/DW.
The USB AVR910 programmer I have is different. It is from a Chinese vendor using a proper USB serial chip and ATmega8535.
What USB chip is it using, a CH340G? If so, then there is no USB software to deal with. It's easy to adapt the avr910 code to use the atmega8535 or any other Atmega.
I can do it (but only in asm not C). The attiny2313 has a very small (64 byte) buffer for the data to be programmed. An Atmega would allow you to increase the buffer size which would speed up the programming. I did this in 2019 for an atmega128. I have been using it reliably since then.
@avrfreak
Thanks. Yes there is no USB SW to deal with as it is a USB to Serial bridge (PL2303HXA which is obsolete and I need to use an old driver -- I have suggested the vensor to switch to CH340G or similar for better driver support for their product).
It will be great that you can share your mod for ATmega128 and ATmega8535. Thanks.
Here is the avr910 source code for atmega8, atmega8535, atmega328p and atmega128. The atmega328p and atmega128 are set up to run on a 14.7456 MHz crystal and can easily be modified. Both the delay.inc and usart.inc files will need to be modified to suit the crystal you are using as well as the fuses for the device you are programming. See notes in the source.
I tested the atmega328p code on an arduino UNO with a CH340G and a 14.7456 MHz crystal. I had to change the crystal on the arduino from 16MHz because the usart communication was bad at that speed.
The atmega8 & Atmega8535 sources are set up for use with a 7.3728 Mhz crystal.
My USB AVR910 is like the following, probably a new revision since there is another alternative 8051 type MCU (not populated) -- probably due to the higher price of ATmega8535L now. https://www.aliexpress.com/item/1267121534.html [BTW, I am not recommending to buy this though at the US$20, you can buy good AVRISP mkii clone with lower price, from AliExpress. I got it slightly cheaper from Taobao but again I can buy an AVRISP mkii cheaper from Taobao].
The source code is basically the same as the v38b with adjustment to the ATmega8535L and 3.7328MHz crystal.
;* HISTORY
;* V3.8c 25.11.06 (Serasidis) Changed the programmer's AVR to ATtiny2313 at 11.0592MHz speed and 115200 bps baud rate.
;* V3.8b 26.02.06 (Klaus) Matched new Devices to avrdude.conf v5.1
;* V3.8a 30.12.05 (Klaus) Corrected Devic entry for ATTiny13
The atmega8 & Atmega8535 sources are set up for use with a 7.3728 Mhz crystal.
@avrfreak Thanks a lot for the help.
Just wondering if you can create a similar version for ATmega16 with the same 7.3728MHz crystal. The reason is that the JTAG ICE 1 clone is using ATmega16 with 7.3728MHz crysgtal. In that case, people may be able to swap the FW as avr910 technically is able to support many chips comparing to JTAG.
Ref: links for building the JTAG ICE 1 clone, including schematics and bootloader.
You can use the atmega8535 code, it's the same pinout as Atmega16. You will have to change the SPI pins and the LED pins to match your board. Change SPI_PORT, SPI_PIN and SPI_DDR to match your board. I don't see what the LED's do in this programmer. One LED blinks usually once during programming, this is not needed IMO.
Sorry for the dumb questions, but I'll have to catch up somehow, since I've not been following the discussion for a few days:
I understand the reason avrospII programs modern devices using an avr910 programmer is because it ignores the device codes sent out from the avr910 programmer and uses the universal 4 bytes SPI packets.
If the AVR910 firmware (even the older versions?) supports 4-byte SPI packets, why even bother with the device signature in the first place? From a compatibility point of view, wouldn't it be better to just use SPI packets? Then we could support most (all?) AVRs with an ISP programming interface.
I realize I'll have to build an AVR910 programmer to join the party here. Does Avrdude support 4-byte SPI packets mode using the AVR910 programmer? If yes, we could perhaps use the device code if present in the avrdude.conf file, and 4-byte SPI mode if not?
The atmega8 & Atmega8535 sources are set up for use with a 7.3728 Mhz crystal. 910-m8.zip 910-m128.zip 910-m328p.zip 910-m8535.zip
Thanks @avrfreak! Is there a schematic available for these as well?
Sorry for the dumb questions, but I'll have to catch up somehow, since I've not been following the discussion for a few days:
I understand the reason avrospII programs modern devices using an avr910 programmer is because it ignores the device codes sent out from the avr910 programmer and uses the universal 4 bytes SPI packets.
If the AVR910 firmware (even the older versions?) supports 4-byte SPI packets, why even bother with the device signature in the first place? From a compatibility point of view, wouldn't it be better to just use SPI packets? Then we could support most (all?) AVRs with an ISP programming interface.
I realize I'll have to build an AVR910 programmer to join the party here. Does Avrdude support 4-byte SPI packets mode using the AVR910 programmer? If yes, we could perhaps use the device code if present in the avrdude.conf file, and 4-byte SPI mode if not?
AVROSPII (IIRC) uses the universal commands. This is (I THINK) why it supports any device that atmel or avrstudio does. It looks at all the xml files and creates a devicelist.dat file based on that. (you have to delete the devicelist.dat file, then start the program so it will create a new file based on the xml files). Avrdude is way more convenient in that you can just double click a bat file and program the device, instead of going in a windows program. The only way I could see on how to make avrdude work with the avr910 programmer the way avrospII does is to modify avrdude. The avrospII is open source (it's in the name). If you can't find the source let me know i can upload it. I only know assembly so I can't make any mods to avrdude.
I posted a schematic but the pinout and the crystal is probably different. You will have to modify the source code I posted so that it will match the pinout on your board. It's probably easiest to use an arduino nano or UNO with the m328p code i posted. Of course, you will have to change the crystal to 14.7456 MHz so the communication can run at 115200 reliably. Don't worry about the LED's, they do nothing anyways. (except at startup)
If the AVR910 firmware (even the older versions?) supports 4-byte SPI packets, why even bother with the device signature in the first place?
Its the PC side that does not work with the universal commands, like avrprog.exe and avrdude.exe. (AVROSPII does). When the programmer "avr910" is specified in the avrdude command line, it expects to see all of the device bytes and will only accept the ones the programmer spits out. I guess we could just clean up the unused outdated older devices and add new ones, but something would have to be done on the PC side whether it can be done in the avrdude.conf file or not (I am not sure).
Thanks for the hints @avrfreak! I happen to have an ATmega8535 and a 7.3728 MHz crystal, so the process was fairly trivial. I can confirm that I can communicate with an ATmega128 using the AVR910 programmer, so that's a good thing.
It would be great if we somehow could implement support for SPI commands for parts that doesn't have a device code. For reference, is the avrospii source code available?
It appears that Avrdude already has support for SPI commands:
However, I'm not sure how we can utilize this so the AVR910 programmer can act as a bridge between Avrdude and the target, where Avrdude is figuring out all the SPI commands, not the programmer.
The ideal solution would IMO be:
;* +-------------+------------+------+
;* Commands | Host writes | Host reads | |
;* -------- +-----+-------+------+-----+ |
;* | ID | data | data | | Note |
;* +-----------------------------------+-----+-------+------+-----+------+
;* | Enter programming mode | 'P' | | | 13d | 1 |
;* | Report autoincrement address | 'a' | | | 'Y' | |
;* | Set address | 'A' | ah al | | 13d | 2 |
;* | Write program memory, low byte | 'c' | dd | | 13d | 3 |
;* | Write program memory, high byte | 'C' | dd | | 13d | 3 |
;* | Issue Page Write | 'm' | | | 13d | |
;* | Read program memory | 'R' | |dd(dd)| | 4 |
;* | Write data memory | 'D' | dd | | 13d | |
;* | Read data memory | 'd' | | dd | | |
;* | Chip erase | 'e' | | | 13d | |
;* | Write lock bits | 'l' | dd | | 13d | |
;* | Write fuse bits | 'f' | dd | | 13d | 11 |
;* | Read fuse and lock bits | 'F' | | dd | | 11 |
;* | Leave programming mode | 'L' | | | 13d | 5 |
;* | Select device type | 'T' | dd | | 13d | 6 |
;* | Read signature bytes | 's' | | 3*dd | | |
;* | Return supported device codes | 't' | | n*dd | 00d | 7 |
;* | Return software identifier | 'S' | | s[7] | | 8 |
;* | Return sofware version | 'V' | |dd dd | | 9 |
;* | Return hardware version | 'v' | |dd dd | | 9 |
;* | Return programmer type | 'p' | | dd | | 10 |
;* | Set LED | 'x' | dd | | 13d | 12 |
;* | Clear LED | 'y' | dd | | 13d | 12 |
;* | Universial command | ':' | 3*dd | dd | 13d | |
;* | New universal command | '.' | 4*dd | dd | 13d | |
;* | Special test command | 'Z' | 2*dd | dd | | |
;* +-----------------------------------+-----+-------+------+-----+------+
I'm not sure if this matters or not, but the AVR910 programmer has the ':'
commands, which doesn't appear to be implemented in Avrdude. Maybe ':'
could speed up "SPI command" programming? This might be @stefanrueger's territory 😁
Well for starters I want to use the hardware spi instead of bit banging. Originally the code was meant for an AT90S1200 that did not have SPI. I did try to speed it up years ago and IIRC it was troublesome or unreliable with new factory fused chips. IMO it is fast enough as long as the SPI is changed as I mentioned.
Making it work as AVROSPII might be easier since the source code has all the answers, however that is not my expertise.
I may have commented some of the code out in the source I posted, so that command could be used. It's been so long I can't remember! The programmer source I posted is slightly modified to program the AT89S51 and AT89S52 and works very well. So this is not an "official" version.
Here is a link to the AVROSPII documentation. https://ww1.microchip.com/downloads/en/Appnotes/doc2568.pdf
I found a link to the source code here: https://storage.googleapis.com/google-code-archive-source/v2/code.google.com/avrosp911/source-archive.zip
I should have some time early this week to clean up the programmer code and implement the changes I mentioned.
Does anyone have preference as to what board layout we should use? Just so anyone can test it without many modifications. I am open to suggestions. I was thinking of using a modified arduino UNO (or NANO) with a 14.7456 MHz crystal and the target reset modded with a jumper as in the schematic I posted earlier. It seems like everyone has an UNO or NANO these days.
Does anyone have preference as to what board layout we should use? Just so anyone can test it without many modifications. I am open to suggestions. I was thinking of using a modified arduino UNO (or NANO) with a 14.7456 MHz crystal and the target reset modded with a jumper as in the schematic I posted earlier. It seems like everyone has an UNO or NANO these days.
@avrfreak
This is a good idea. I agree that many people using avrdude will have either an UNO or a NANO these days (or both and may be more than one units). Arduino as ISP
is popular (STK500v1 protocol). And you can see jtag2updi is also running on top of Uno/Nano.
Ref: https://github.com/ElTangas/jtag2updi
Does anyone have preference as to what board layout we should use? Just so anyone can test it without many modifications. I am open to suggestions. I was thinking of using a modified arduino UNO (or NANO) with a 14.7456 MHz crystal and the target reset modded with a jumper as in the schematic I posted earlier. It seems like everyone has an UNO or NANO these days.
The only hassle is the crystal. If you're using an UNO or a NANO, one would have to desolder the 16 MHz one and replace it with 14.7456 MHz. Wouldn't it be possible to modify the source code for it to work with 16 MHz clocks? I know there will be some baud rate error when using 115200 baud @ 16 MHz, but it's not really significant, and Arduinos has been doing this for over a decade now.
If using a 16 MHz crystal would be possible, creating an AVR910 programmer would be as easy as flashing the Arduino as ISP
sketch! I have _very little experience with assembly, so I can't help out on this one. But I'm sure source code that "just works" on a stock board you can buy cheaply would make the AVR910 programmer way more accessible to the average tinkerer!
@MCUdude
Good point about the crystal.
I believe that Arduino as ISP
on the Uno only works at 19200 baud.
@avrfreak What kind of baud rate can be achieved if we have to keep the 16MHz crystal? Can we achieve 57600/38400/19200 baud?
The programmer will be very slow at 19200 or any other baud rate other than 115200. I used a slightly different formula to calculate the baud rate. I tested it and it seems to be working with avrprog.exe.
This code will run on an arduino UNO with a 16 MHz crystal (unmodified).
The connections are: Target Reset: 9 or PB1 MOSI: 11 or PB3 MISO: 12 or PB4 SCK: 13 or PB5
the LED's can be connected as follows: Green led to A2 or PC2 Yellow or Red LED to A3 or PC3
As I mentioned previously, don't even use the led's. They are not on long enough for a human to see them. If I stretch out the duration of the LED on time then it will slow down the programming time not worth it IMO.
This one still uses bit-bang for SPI. I am going to change that and a few other things before I release the source code. This hex file when programmed, will erase your arduino bootloader. 910-UNO_16Mhz.zip
To preserve the bootloader use this program. When entering the com port you must enter "COM3" (change the number to the port your Arduino is connected to) 910-UNO.zip
I'll await your feedback.
My USB AVR910 is not fast but I think also not too slow at 19200bps. It does not seem to work at 38400/57600/115200bps (ATmega8535 at 3.7328MHz). I think it is still acceptable.
The results are the same with or without -b 19200
.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c avr910 -P COM9 -p m128 -b 19200
-U flash:r:m128a_empty_read_avr910.hex:i -v
avrdude.exe: Version 7.0-20220819 (38aa131)
...
...
avrdude.exe: avr910_devcode selected: 0x43
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude.exe: Device signature = 0x1e9702 (probably m128)
avrdude.exe: reading flash memory ...
Reading | ################################################## | 100% 76.36s
avrdude.exe: flash is empty, resulting file has no contents
avrdude.exe: writing output file m128a_empty_read_avr910.hex
avrdude.exe done. Thank you.
An USBASP is of course faster.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p m128a
-U flash:r:m128a_empty_read_usbasp.hex:i
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude.exe: Device signature = 0x1e9702 (probably m128a)
avrdude.exe: reading flash memory ...
Reading | ################################################## | 100% 21.91s
avrdude.exe: flash is empty, resulting file has no contents
avrdude.exe: writing output file m128a_empty_read_usbasp.hex
avrdude.exe done. Thank you.
@avrfreak
Thanks. I will try your Uno code later (probably tomorrow evening).
It seems to me the connection is pretty much the same as Arduino as ISP
, other than that you use a different RESET pin (they use Pin 10 and you use Pin 9).
https://docs.arduino.cc/built-in-examples/arduino-isp/ArduinoISP
@avrfreak Somehow I can not get your Uno AVR910 to work (https://github.com/avrdudes/avrdude/files/9394205/910-UNO_16Mhz.zip). Both avrprog and avrdude can not communicate with the programmer. I have tried three Uno (two with Atmega16U2 and one with CH340G).
Found programmer: Id = "?"; type = ?
Software Version = ?.ï; Hardware Version = ?.
Programmer supports the following devices:
Device code: 0x3f = (unknown)
did you program the fuses correctly?
-U lfuse:w:0xff:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
did you program the fuses correctly?
-U lfuse:w:0xff:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
Fuse does not seem to be the issue. Rather I find the following two things. 1) Two Arduini Uno clones with ATmega16U2 (original Arduino USB to Serial FW) do not work at all. 2) Two Arduino Uno clones with CH340G seem to be better -- the programmer gets recognized and the chip signature can be read -- but then programming eventually failed. I have tried to use pretty short ribbon cable already.
It seems to me 115200bps is challenging with the 16MHz crystal.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c avr910 -P COM11 -b 115200 -p m32
-U .\Blink.ino.with_bootloader_atmega16_8000000L.hex
Found programmer: Id = "AVR ISP"; type = S
Software Version = 6.0; Hardware Version = 1.2
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize = 64 bytes.
Programmer supports the following devices:
Device code: 0x13 = AT90S1200
Device code: 0x20 = AT90S2313
Device code: 0x28 = AT90S4414
Device code: 0x30 = AT90S4433
Device code: 0x34 = AT90S2333
Device code: 0x38 = AT90S8515
Device code: 0x48 = (unknown)
Device code: 0x4c = AT90S2343
Device code: 0x51 = (unknown)
Device code: 0x55 = ATtiny12
Device code: 0x56 = ATtiny15
Device code: 0x68 = AT90S8535
Device code: 0x6c = AT90S4434
Device code: 0x87 = (unknown)
Device code: 0x01 = (unknown)
Device code: 0x04 = (unknown)
Device code: 0x05 = (unknown)
Device code: 0x06 = (unknown)
Device code: 0x07 = (unknown)
Device code: 0x08 = (unknown)
Device code: 0x09 = (unknown)
Device code: 0x0e = (unknown)
Device code: 0x1a = (unknown)
Device code: 0x0f = (unknown)
Device code: 0x1b = (unknown)
Device code: 0x14 = (unknown)
Device code: 0x1c = (unknown)
Device code: 0x1d = (unknown)
Device code: 0x23 = (unknown)
Device code: 0x31 = (unknown)
Device code: 0x33 = (unknown)
Device code: 0x35 = (unknown)
Device code: 0x37 = (unknown)
Device code: 0x39 = (unknown)
Device code: 0x3d = (unknown)
Device code: 0x3e = (unknown)
Device code: 0x57 = (unknown)
Device code: 0x3a = ATmega8515
Device code: 0x3b = (unknown)
Device code: 0x41 = ATmega103
Device code: 0x43 = ATmega128
Device code: 0x44 = (unknown)
Device code: 0x45 = ATmega64
Device code: 0x46 = (unknown)
Device code: 0x5e = ATtiny26
Device code: 0x60 = ATmega161
Device code: 0x61 = (unknown)
Device code: 0x62 = (unknown)
Device code: 0x63 = ATmega162
Device code: 0x64 = ATmega163
Device code: 0x66 = (unknown)
Device code: 0x69 = ATmega8535
Device code: 0x6a = (unknown)
Device code: 0x72 = ATmega32
Device code: 0x73 = (unknown)
Device code: 0x74 = ATmega16
Device code: 0x75 = ATmega329
Device code: 0x76 = ATmega8
Device code: 0x77 = (unknown)
Device code: 0x78 = ATmega169
Device code: 0x79 = (unknown)
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude.exe: Device signature = 0x1e9502 (probably m32)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file .\Blink.ino.with_bootloader_atmega16_8000000L.hex for flash
with 1440 bytes in 3 sections within [0, 0x3fff]
using 12 pages and 96 pad bytes
avrdude.exe: writing 1440 bytes flash ...
Writing |
| 0% 0.00savrdude.exe: avr910_recv(): programmer is not responding
avrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
Writing | ####
| 8% 10.03savrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
Writing | ########
| 16% 10.05savrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
Writing | #############
| 25% 10.06savrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
Writing | #################
| 33% 10.08savrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
Writing | #####################
| 41% 10.09savrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
Writing | #########################
| 50% 10.11savrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
Writing | #############################
| 58% 10.12savrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
Writing | ################################################## | 100% 10.15s
avrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: error: programmer did not respond to command: write block
avrdude.exe: 1440 bytes of flash written
avrdude.exe: verifying flash memory against .\Blink.ino.with_bootloader_atmega16_8000000L.hex
Reading |
| 0% 0.00savrdude.exe: error: programmer did not respond to command: set addr
Reading | ####
| 8% 0.00savrdude.exe: error: programmer did not respond to command: set addr
Reading | ########
| 16% 0.01savrdude.exe: error: programmer did not respond to command: set addr
Reading | #############
| 25% 0.01savrdude.exe: error: programmer did not respond to command: set addr
Reading | #################
| 33% 0.02savrdude.exe: error: programmer did not respond to command: set addr
Reading | #####################
| 41% 0.02savrdude.exe: error: programmer did not respond to command: set addr
Reading | #########################
| 50% 0.03savrdude.exe: error: programmer did not respond to command: set addr
Reading | #############################
| 58% 0.03savrdude.exe: error: programmer did not respond to command: set addr
Reading | ################################################## | 100% 0.04s
avrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: error: programmer did not respond to command: set addr
avrdude.exe: verification error, first mismatch at byte 0x0000
0x3f != 0x0c
avrdude.exe: verification error; content mismatch
avrdude.exe: error: programmer did not respond to command: leave prog mode
avrdude.exe done. Thank you.
yes of course avrdude doesn't work well with the programmer. This is what the discussion is about. Try using avrprog.exe or avrospII.exe. That is how I tested it and it is working perfectly every single time. The usart baud rate calculation was done differently just like the arduinos, so it will work.
Unfortunately in my case avrprog also does not work either with the Uno based AVR910. It is kind of HW programmer statbility problem, at least under my Windows 11 laptop. But it could be the ribbon cable problem as well for the two CH340G based Uno clone. I will try again tomorrow using different ribbon cables.
Both avrdude and avrprog work well with my USB AVR910 programmer.
I don't see the problem, it works perfectly here. I suggest you check your RS232 serial port, cables, connections, etc. or maybe someone else can try the hex file on an UNO with 16MHz crystal.
There is a problem only when using avrdude or avrprog because those programs send blocks of data to the programmer. The size of the block is dependent on what buffer size is set up in the programmer code which is 64 bytes. So with the right crystal, the programmer can handle it perfectly. If there is a problem, the programmer sends a "?" back to the host and that's where the problem lies.
There is no problem using the above 910-UNO_16Mhz.zip if you are using avrospII because it doesn't use the block write mode as avrprog and avrdude. It programs one byte at a time. (I tested it with a full 8K file & it is very slow! so what's the use?)
I even tested my bit-bang serial routines that handle 115200 baud with a 16 MHz clock perfectly with near 0% errors, but somehow there is just too much data coming in at once when the block writes are sent. The hardware USART handles this a lot better. It would be better to create a circular buffer since the atmega328p has 2K ram, then change the block size to 256 or even 512 bytes long. This (I think) is the only way to speed up this programmer. You can test with avrprog.exe then program the same hex file with avrospII.exe. You will notice a significant difference in speed. Avrprog,exe is a great deal faster. (but it does not handle the newer devices like avrospII does).
I did implement the hardware SPI in the code below but it wouldn't work on virgin chips unless I slowed it down (almost as slow as the original code). Now I can remember why I (or anyone else) didn't pursue this 10 or so years ago.
So here I am posting a hex file that will run on an UNO or NANO, but you must change the crystal to 14.7456 MHz. Going lower than 115200 on the baud rate defeats the purpose of what we are trying to achieve here. The optiboot bootloader is included that will run at 115200 with the 14.7456 MHz crystal (if you program the fuses correctly).
This works very well with avrprog.exe or avrdude.exe, and IMO fast enough! So I think the MAIN goal here is to adapt the programmer to support newer chips. and making it faster would be nice :)
This works very well with avrprog.exe or avrdude.exe, and IMO fast enough! So I think the MAIN goal here is to adapt the programmer to support newer chips. and making it faster would be nice :)
@avrfreak
Yes I agree that to support newer chips is the main goal. Making it faster is rather a bonus.
I do not have the 14.7456MHz crystal now so that I will not be able to test this any time soon. The clones I have use a tiny SMD crystal for the ATmega328P which does not seem to be readily available. They actually use discrete crystal (12MHz for the CH340G and 16MHz for the ATmega16U2).
One suggestion is to change reset pin to Pin 10 (PB2). The reason is that Arduino as ISP
is using that and there are so called ISP Shield
on the market.
It is a pity that 16MHz crystal does not work well but I think the modification to 14.7456MHz crystal in this case is still a good compromise. @MCUdude's Arduino Minicore does support 14.7456MHz crystal so the mod Uno/Nano can still be useful even if one decides not to use them as the AVR901 programmer later.
One suggestion is to change reset pin to Pin 10 (PB2). The reason is that
Arduino as ISP
is using that and there are so calledISP Shield
on the market.I did not use that pin because it's the SS pin. According to the datasheet, if this pin goes low it can change the SPI to slave mode. ( I think there is more to it, like the pin has to be set up as an input) In the code, the pins are released so I am not sure how this will work with the hardware SPI implementation. Here it is UNTESTED. Let me know if there are any problems. 910-328p_14MHz_Changed_Rst.zip Just as I thought, using the SS pin for reset stops the SPI from working. I changed the file above so it works with pin 10 (PB2) as reset, however the bit-bang spi method has been restored.
@avrfreak Thanks. Unfortunately I can not test this since I do not have the crystal.
Arduino as ISP (seems to work only at 19200bps) https://docs.arduino.cc/built-in-examples/arduino-isp/ArduinoISP https://github.com/arduino/arduino-examples/blob/main/examples/11.ArduinoISP/ArduinoISP/ArduinoISP.ino
@avrfreak Thanks. Unfortunately I can not test this since I do not have the crystal.
Arduino as ISP (seems to work only at 19200bps) https://docs.arduino.cc/built-in-examples/arduino-isp/ArduinoISP https://github.com/arduino/arduino-examples/blob/main/examples/11.ArduinoISP/ArduinoISP/ArduinoISP.ino
Yes I know, and it may be as fast or faster because I think it uses the STK500 protocol? I am not sure I have never looked into it. I never tried it.
Yes I know, and it may be as fast or faster because I think it uses the STK500 protocol? I am not sure I have never looked into it. I never tried it.
I will post the test results comparing my USB to Serial AVR910 and Arduino as ISP
for reading ATmega32/ATmega128. Both of them will only work at 19200 bps. I tend to think Arduino as ISP
may be a bit faster at the same baud rate.
The hope is that AVR910 at 115200 bps can beat the Arduino as ISP
at 19200 bps.
@mcuee what avr910 programmer do you have that you will be able to test code for me? Please let me know the crystal and the mcu on the programmer.
I have increased the speed of the programmer a great deal, however avrdude doesn't work with this code the only program that will function is avrprog.exe or avrospII. although avrospII will never be any faster than it is right now. thanks
@avrfreak Unfortunately my USB AVR910 programmer is using SMD ATmega8535 and 3.7328MHz crystal. It is not easy to load alternative Firmware (no ISP header).
I was hoping that you can get the Uno working with 16MHz crystal -- it is okay to have lower baud rate for this testing. People who want 115200 bps will need to change the crystal. As you mentioned, many people playing with avrdude will probably have the Uno or Nano with ATmega328P.
I made the program faster but it certainly won't work at 16 MHz because the data blocks are 256 bytes going to the programmer from avrprog. Surely there will be problems at 115200 baud rate with 16MHz.
Lowering the baud rate will defeat the purpose. I did manage to get avrdude to program the atmega328p using the avr910 programmer.
Just got a serial port AVR910 prog (based on AT902313 and use some passive components for the serial interface) from AliExpress (along with a serial port based SI-Prog).
Currently avr910 only supports limited parts. Alternative PC applications like AVROSP2 supports many more parts. Microchip/Atmel original avrosp can support more parts as well with the proper xml files.