USBtinyISP with Arduino Mega (ATmega1280)
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- mmattice
- Posts: 3
- Joined: Tue Dec 07, 2010 2:51 pm
Re: USBtinyISP with Arduino Mega (ATmega1280)
With the release of the ATtiny4313, would it be reasonable to expect this flash size bug to get fixed in a 4313 version of the usbtinyisp?
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
Re: USBtinyISP with Arduino Mega (ATmega1280)
if we can ever get any, we will definately try it out (but they are not yet available en masse)
- mmattice
- Posts: 3
- Joined: Tue Dec 07, 2010 2:51 pm
Re: USBtinyISP with Arduino Mega (ATmega1280)
AVNET says they have nearly 700 of them. I guess you guys have a different definition of en masse than I would.
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
-
- Posts: 58
- Joined: Sun Dec 06, 2009 11:12 pm
Re: USBtinyISP with Arduino Mega (ATmega1280)
Could anybody recommend an AVR programmer (AVRdude compatibility, low cost, open hardware would all be positive selling points!) which can be considered reliably supported for ATmega1280/2560 use, if the Adafruit USBTinyISP (which I'm very happy with for most of my use with most AVRs!) cannot be considered reliably supported for this use?
-
- Posts: 1
- Joined: Tue Mar 20, 2012 1:59 am
Re: USBtinyISP with Arduino Mega (ATmega1280)
Quick question
I have bought a bunch of 128s which I don't intend to use all of the 128k flash on....
Is it possible to mod the source code to only attempt access to the first 64k?
So I basically get an ATMEGA64 but at least it works...
Or is this what already happens if you only try to write <64k?
I have bought a bunch of 128s which I don't intend to use all of the 128k flash on....
Is it possible to mod the source code to only attempt access to the first 64k?
So I basically get an ATMEGA64 but at least it works...
Or is this what already happens if you only try to write <64k?
- adafruit_support_bill
- Posts: 88098
- Joined: Sat Feb 07, 2009 10:11 am
Re: USBtinyISP with Arduino Mega (ATmega1280)
If you don't use the upper 64K, it won't hurt anything.
-
- Posts: 78
- Joined: Sun May 03, 2009 8:18 pm
Re: USBtinyISP with Arduino Mega (ATmega1280)
Ah, I just did the same thing. Wish I found this thread sooner. Ruined my old Atmel1280 mega arduino trying to update the bootloader as a test for a PCB I'm making w/ the 1280 chip. I too have had to order the atmel AVRISP mkII, in the mail. A credit to adafruit would be much appreciated for the loss of a $50 conroller though.
-
- Posts: 29
- Joined: Sat Dec 15, 2007 7:52 pm
Re: USBtinyISP with Arduino Mega (ATmega1280)
stinkbutt wrote:I've reviewed the code and I'm forced to concur. The USBTinyISP appears to be incapable of addressing memory addresses in excess of 64 KB, and while I can't be sure, it seems reasonable to suppose than it might brick the AVR chip if it attempts to write a nondeterministic value to the fuses, which could easily be located at address(es) 0, 1, 2, 3, etc...mmattice wrote:I've run into this as well and tracked the problem down to the 16 bit integer that stores the current read address (address, defined on line 70 of main.c).
Basically, it overflows at 64kbytes, and starts reading the beginning of the chip again. If address was just one bit larger, the >> 9 later down in spi_rw (where address overflows) would turn the address into a proper word address for the read commands.
Now, this wouldn't fix 256kbyte chips as the load extended address byte command ($4d) doesn't seem to be supported at all by the USBtinyISP.
There may be a way to squeeze at least the fix for 128k chips into the tiny2313, but my compiler starts the firmware out at 8 bytes over sized before I change the type of address to uint32_t.
Mike
Oh, actually I disagree about the line number. It's line 71, not 70.
Can anyone tell me if mmattice is wrong here?
Ok, don't know if it's against ettiquette to respond to really old threads, but I had this question and this thread comes up on Google.
1. When programming the larger AVRs, the usbtiny has no need to "address memory in excess of 64K". First of all, AVR flash is word based, so the 1280, 1284, etc. chips with 128Kbytes only need to address 64K words, which means that usbtiny will handle them just like it handles smaller chips.
2. On larger AVRs, the flash is still addressed in 64K word blocks. There is an extended address command that sets which 64K word block to program, and this is an ordinary SPI command like all the rest that the usbtiny has no trouble with. That particular command isn't "supported" by the usbtiny explicity because it is a generic command, like "enter program mode" or "read sig bytes", etc., which are all handled by USBTINY_SPI or USBTINY_SPI1, i'm not sure which. This extended address is why John up there in this thread was able to program 1280 and 2560 avrs.
Having said all this, I have not yet tried programming my 1284 avrs, but once i have tried, if it fails, I will come back and update this post.
-
- Posts: 29
- Joined: Sat Dec 15, 2007 7:52 pm
Re: USBtinyISP with Arduino Mega (ATmega1280)
tldr; the problem is in avrdude; it should not used paged_load for addresses > 64K when using the usbtiny.
Ok, avrdude and usbtiny can program atmega1284 beyond 64kbytes. When reading it back, avrdude will report the first mismatch at $10000, or 64kbytes.
But, the file is written to flash properly. I have confirmed this with code that displays the PC on an LCD, and you can confirm it by using avrdude in terminal mode to read flash pages beyond 64k, and they will match your hex file.
The problem is this: when avrdude writes flash, it uses the paged mode built into the avr, so usbtiny does not deal with the whole address. A separate SPI command selects the page, and then a block is written. But when reading Flash, the avr does not have a page mode, but usbtiny does, except the usbtiny address is limited to 64K, so it starts back at zero if the address >= 64K. And just to be clear, this is not an error in the usbtiny; avrdude sends the address as an argument in a usb_control_msg, but that argument is an unsigned 16 bit integer, so the address is truncated before it gets to the usbtiny.
If you edit avrdude's avr.c file, and only allow paged_load in avr_read if size < 64K, avrdude will write and read the file without reporting any errors. (I am using avrdude 5.10, which is rather old, and they might have fixed this by now).
I timed a 65618 byte file with single byte read vs paged_load read: single took 4:28, while paged took 3:57 on my ancient Asus netbook, which is 13% longer. I should mention that the times include writing as well, so the percent degradation in read time is probably more like twice that value, or 26%.
Ok, avrdude and usbtiny can program atmega1284 beyond 64kbytes. When reading it back, avrdude will report the first mismatch at $10000, or 64kbytes.
But, the file is written to flash properly. I have confirmed this with code that displays the PC on an LCD, and you can confirm it by using avrdude in terminal mode to read flash pages beyond 64k, and they will match your hex file.
The problem is this: when avrdude writes flash, it uses the paged mode built into the avr, so usbtiny does not deal with the whole address. A separate SPI command selects the page, and then a block is written. But when reading Flash, the avr does not have a page mode, but usbtiny does, except the usbtiny address is limited to 64K, so it starts back at zero if the address >= 64K. And just to be clear, this is not an error in the usbtiny; avrdude sends the address as an argument in a usb_control_msg, but that argument is an unsigned 16 bit integer, so the address is truncated before it gets to the usbtiny.
If you edit avrdude's avr.c file, and only allow paged_load in avr_read if size < 64K, avrdude will write and read the file without reporting any errors. (I am using avrdude 5.10, which is rather old, and they might have fixed this by now).
I timed a 65618 byte file with single byte read vs paged_load read: single took 4:28, while paged took 3:57 on my ancient Asus netbook, which is 13% longer. I should mention that the times include writing as well, so the percent degradation in read time is probably more like twice that value, or 26%.
Please be positive and constructive with your questions and comments.