-
Notifications
You must be signed in to change notification settings - Fork 145
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AVR910 programmer enhancment to support more parts #1060
Comments
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.
The xml files from this github repo has even more parts (193 parts, including xmega parts).
|
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. BTW, I bought the other three low cost items from the same shop.
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. |
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:
From avrdude.conf:
|
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. 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. 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. 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 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. |
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.
The only AVR910 bootloader alternative I've found is 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).
|
BTW, the following is from AVROSP2 5.47 version (last release from Mike Henning). 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). 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.
|
@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
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).
Then there are new FW (latest is v38b, Last updated 26-Feb-2006 ) which is based on Microchip implementations by Klaus Leidinger. Then the Sourceforge project "AVR ISP: AVR910 programmer firmware" which seems to be based on the above. 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. |
Is this what you want? 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. |
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. |
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. I tested the atmega328p code on an arduino UNO with a CH340G and a 14.7456 MHz crystal. 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. The source code is basically the same as the v38b with adjustment to the ATmega8535L and 3.7328MHz crystal.
|
@avrfreak 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:
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?
Thanks @avrfreak! Is there a schematic available for these as well? |
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). 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. |
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. |
Thanks for the hints @avrfreak! I happen to have an ATmega8535 and a 7.3728 MHz crystal, so the process was fairly trivial. 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: Lines 296 to 318 in 38aa131
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:
I'm not sure if this matters or not, but the AVR910 programmer has the |
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. 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. I found a link to the source code here: 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. |
Thanks for the clarification for the hex files. Good that the 250k/500k baud hex files are already the latest. By ribbon cable I mean the connection between the programmer and the target. The interface to the PC is always USB. |
Comparison of Uno based programmers using the "ribbon cable" setup and same 32KB hex file. Interestingly ScratchMonkey is faster than AVR910 in terms of flash writing but not flash verification.
|
That cable will have nothing to do with the baud rates or changes to the baud rate. If you are having communication issues with the PC it's probably the board you are using. |
Indeed it may have something to do with my paticular setup (Windows 11 laptop, USB Type C port and then a 4-port USB Hub). Anyway, that is just my experience. It has nothing to do with the USB chipset either. I tested 4 Uno clones, 2 are using ATmega16U2 (same as official design) oand the other two are using CH340G. And all 4 of them have the same results: ribbon cable setup works with 250k/500k baud FW but not 115200 baud FW. |
Would you please create a pull request to modify |
Here is the modified avrdude_avr910.conf as well as the latest git main version of the avrdude mingw64 version, using my USB AVR910 programmer (PL2303+ATmega9535, it seems to only run in 19200 bps).
|
you have to specify the baud rate -b 115200 or it defaults to 19200 |
My USB AVR910 has a lower frequency crysgtal and it can not support 115200bps. |
With optimization (comment out all the LED related codes),
|
Just wondering if you are still interested to create a PR to modify |
I don't know a lot about avrdude and the conf files. I did however create another file for the UNO board that will work at a faster programming speed. The code works with an unmodified UNO @ 16MHz with the reset pin configured for the programming sheild. |
It is slightly unclear to me how to do this:
So this can be done for one firmware extension at the expense of other incompatible firmware extensions. |
I may be wrong but I tend to think if we ignore the AVR910 IDs (changing avrdude codes), we can support the classic AVRs which support ISP, without touching the firmware. From what I see the different firmware is just to adapt to different AVR used and different clock speed. |
The avr910 firmware in the programmer defines a small number of older parts. As I mentioned before, I have little knowledge of the avrdude.conf file. IIRC, I used similar avr910 codes for similar devices. For the attiny2313, I used the AVR910 Attiny26 device code. The page sizes must be the same if you are using avrprog.exe but they can be changed in avrdude.conf when newer devices are added. You can see what I have done in the avrdude.conf file I posted above. For avrospII.exe you just install the latest microchip studio. (I think you have to delete the dat file then restart avrospII.exe and the devicelist.dat will regenerate. The problem with avrosp.exe is that it is very slow. I don't remember why, (I think avrosp sends the data one byte at a time from the PC to the programmer. AVRprog supports Atmega128. You can select Atmega128 for use with atmega1284. What I just did recently was added a jumper setting just like the old USBASP firmware where it allows you to select slow SCK. I don't think this modification is for everyone, especially when you can just buy a USBASP for under $3 which will support newer devices with avrdude. |
Here is the AVR910 firmware for the UNO board @ 16Mhz. |
Programming a 64K file in Fast Mode:
Programming a 64K file in Slow Mode:
|
I suspect this can be done in a private @avrfreak appears to reuse an existing There seem to be firmware variants: @MCUdude has suggested the use of two different device codes, probably based on the observation that different firmware/bootloaders have made a different assignment and that so far no part gets assigned more than two different device codes. I suspect this is not quite as simple. Given a particular part, AVRDUDE needs to know which of the two device codes a programmer/firmware/protocol has assigned to it... The cleanest solution is to have a device code variable for each programmer/firmware/bootloader that has made their own extension of the AVR910 device code assignment. That is difficult to track down though (and how would a user know which firmware their AVR910 programmer has?)
There are quite a few post. If that is your current full avrdude.conf file it would not be clear what you have changed. As @mcuee said, if you submit a PR the it's much clearer what you have done, and it can instantly be tested. |
avrdude.zip |
Thanks. I installed that avrdude.conf file locally. Turns out its mapping of 96 parts to
So, nothing more to do for AVRDUDE? BTW, here the inverse mapping in a bash loop: for code in $(avrdude -p*/St | grep 910_dev | sort | cut -f4 | sort -u); do
echo $code: $(avrdude -p*/St | grep 910_devcode.$code | cut -f2 | sed -es/ATmega/m/ -es/ATtiny/t/|tr A-Z a-z)
done
0x13: at90s1200
0x20: at90s2313 t87 t167 ata5505 ata6616c ata6617c ata664251 t25 t45 t85 t24 t24a t44 t44a t84 t84a t441 t841 t43u
0x28: at90s4414
0x30: at90s4433
0x34: at90s2333
0x38: at90s8515
0x3a: m8515
0x41: m103
0x43: m128 m128a
0x45: m64 m64a
0x48: at90s2323
0x4c: at90s2343
0x56: t12 t15
0x5c: t28
0x5e: t26 t2313 t2313a t4313
0x60: m161
0x63: m162
0x64: m163
0x68: at90s8535
0x69: m8535
0x6c: at90s4434
0x72: m32 m32a
0x74: m16 m16a m324p m164p m164pa m164a m324pb m324pa m324a m644 m644a m644p m644pa m1284 m1284p m325 m325a m325p m325pa m645 m645a m645p m3250 m3250a m3250p m3250pa m6450 m6450a m6450p
0x75: m329 m329a m329p m329pa m3290 m3290a m3290p m3290pa m649 m649a m649p m6490 m6490a m6490p
0x76: m8 m8a
0x78: m169 m169a m169p m169pa
|
yes I did nothing new on the config file, the config file is from last year. |
This is the run log for my modified You can see it works with ATmega328PB.
Relevant entries for ATmega328/328P/328PB
|
This does not seem to work for me. So I was still using the older hex file (910-328p_16MHz_Rst_PB2.hex, from last year) in the previous run log. Failed run log with the latest hex file
|
I suggest you stop using avrdude 7.1 in my opinion it is nothing but trouble especially when trying to use a real RS232 serial port (not a TTL adapter), IT DOESN'T WORK. As for the error messages, "mosi is deprecated" now what is that supposed to mean? I guess the config file is not compatible with the avrdude version you are using. The only reason for uploading a new hex file is to allow the programmer to increase the SCK rate to 2MHz if PD6 & PD7 are joined. I use avrdude V6.3 with the config file I posted. Since I don't have a great deal of time to spend on this because of my job, anything after avrdude V6.3 has been too troublesome and time consuming for me to bother with. |
I will for sure not use the ancient avrdude 6.3 version. You are missing really a lot of features if you stick to the 6.3 version. But anyway, that is your choice... If you have issues with real serial port, please create the issue. But I do not have PCs with real serial port now so I can not test that.
Yes, that is just for quick testing -- I reuse the old configuration file last year, which will cause warnings.
Thanks for the information. |
This is a good point. I guess this issue is probably not worth the efforts in the end. But still thanks for your contribution. Maybe someone may find it useful in the future. |
In this case, I will move this to discussion. If someone helps to create a PR then we can start from there again. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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.
The text was updated successfully, but these errors were encountered: