AVR910 programmer enhancment to support more parts

avrdudes / avrdude

AVRDUDE is a utility to program AVR microcontrollers

GNU General Public License v2.0

667 stars 131 forks source link

AVR910 programmer enhancment to support more parts #1060

Closed mcuee closed 1 year ago

mcuee commented 1 year ago

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.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c avr910 -P COM5 -b 115200 -qqp m328p
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: 0x04 = (unknown)
    Device code: 0x05 = (unknown)
    Device code: 0x06 = (unknown)
    Device code: 0x07 = (unknown)
    Device code: 0x1a = (unknown)
    Device code: 0x1b = (unknown)
    Device code: 0x1c = (unknown)
    Device code: 0x1d = (unknown)
    Device code: 0x23 = (unknown)
    Device code: 0x31 = (unknown)
    Device code: 0x33 = (unknown)
    Device code: 0x37 = (unknown)
    Device code: 0x39 = (unknown)
    Device code: 0x3d = (unknown)
    Device code: 0x3e = (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: error: selected device is not supported by programmer: m328p
avrdude.exe: initialization failed, rc=-1
             Double check connections and try again, or use -F to override
             this check.

mcuee commented 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

mcuee commented 1 year ago

@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.

dl8dtl commented 1 year ago

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.

mcuee commented 1 year ago

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. avrdude_programmers

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

MCUdude commented 1 year ago

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:

Track down "every" AVR910 compatible bootloader that's out there and most likely still being used
Figure out as many device codes as possible for known parts, and ignore parts that don't have an established device code. If a target has two known device codes (ATmega8535 for instance), avrdude should be updated to support both.
Clean up avrdude.conf and remove all invalid or commented out 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

mcuee commented 1 year ago

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

MCUdude commented 1 year ago

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 */

mcuee commented 1 year ago

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).

mcuee commented 1 year ago

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.

newmguy commented 1 year ago

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.

mcuee commented 1 year ago

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.

MCUdude commented 1 year ago

@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?).

avrfreak commented 1 year ago

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).

mcuee commented 1 year ago

@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.

mcuee commented 1 year ago

Just to archive the FW source codes from the above. AVR910_Atmel_v23.zip avr910_2313_v38b.zip avr910_2313_v44.zip

avrfreak commented 1 year ago

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.

mcuee commented 1 year ago

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.

avrfreak commented 1 year ago

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.

mcuee commented 1 year ago

@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.

avrfreak commented 1 year ago

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.

910-m8.zip 910-m128.zip 910-m328p.zip 910-m8535.zip

mcuee commented 1 year ago

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

mcuee commented 1 year ago

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.

avrfreak commented 1 year ago

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.

MCUdude commented 1 year ago

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?

avrfreak commented 1 year ago

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)

schematic

avrfreak commented 1 year ago

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).

MCUdude commented 1 year ago

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?

MCUdude commented 1 year ago

It appears that Avrdude already has support for SPI commands:

https://github.com/avrdudes/avrdude/blob/38aa1313f94fb2ece97ea9a87d5384e8b7cb2b89/src/avr910.c#L296-L318

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:

If a device code is present in avrdude.conf, and the AVR910 programmers supports this device code, program the target "the AVR910 way".
If a device code is not preset, program the target using SPI commands.

 ;*                                     +-------------+------------+------+
;*  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 😁

avrfreak commented 1 year ago

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.

mcuee commented 1 year ago

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

MCUdude commented 1 year ago

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!

mcuee commented 1 year ago

@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?

avrfreak commented 1 year ago

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.

mcuee commented 1 year ago

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.

mcuee commented 1 year ago

@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

mcuee commented 1 year ago

@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)

avrfreak commented 1 year ago

did you program the fuses correctly? -U lfuse:w:0xff:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m

mcuee commented 1 year ago

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.

avrfreak commented 1 year ago

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.

mcuee commented 1 year ago

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.

avrfreak commented 1 year ago

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.

avrfreak commented 1 year ago

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 :)

910-328p_14MHz.zip

mcuee commented 1 year ago

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.

avrfreak commented 1 year ago

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.

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.

mcuee commented 1 year ago

@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 commented 1 year ago

@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.

mcuee commented 1 year ago

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.

avrfreak commented 1 year ago

@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

mcuee commented 1 year ago

@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.

avrfreak commented 1 year ago

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.