AVR USB programmer with ATmega 2560

jvila69 · June 21, 2011, 12:06pm

Hello,

I am having problems trying to program an ATmega 2560 with the Pololu USB AVR programmer. I am using firmware version 1.1 . When I try to program the controller from AVR Studio, everything seems OK. The software does not report any error. The configuration utility seems ok as well. But the fact is that the program does not work.

When I send the same program with a AVRISP MKII everything works fine. I tried with a simple blink code and it´s the same behaviour.

On the other hand, i programmed correctly Atmega 168 and Atmega 328 uC within the same environment. So, i suppose my settings are OK. The signature is correctly read from AVR Studio in all cases.

The minimum voltage and voltage oscillation (from the configuration utility) seems ok, as well.

Any help would be appreciated.

Regards.

DavidEGrayson · June 21, 2011, 8:19pm

Hello, jvila69.

I looked into it and unfortunately the Pololu USB AVR Programmer does not yet support programming devices with more than 128 KiB of flash. We will update the documentation of the programmer and look into adding support for larger devices in a future firmware version.

Since you already have a AVRISP mkII, why are you interested in using our programmer?

–David

jvila69 · June 21, 2011, 10:11pm

Hello,
First of all thank you for your quick answer. I am interested in using your programmer because:

I am not the only one in my company who uses an AVR programmer
It´s cheaper than the AVRISP mkii
It provides a TTL port that serves me for programming other devices. I.e. I am downloading the firmware to 4d systems displays using your programmer (using pin A as DTR signal) and it works perfectly.

I like your product. Just think that limitations like this should be more documented.

Regards.

Ben · June 21, 2011, 11:26pm

Hello.

Thank you for your feedback. Our goal is always to make such limitations very clear so that our customers can make informed decisions before purchasing our products. Unfortunately, in this case, the limitation was unintentional, and we were not aware of it until you posted about your problem. We have now updated the product page and programmer user’s guide to mention this limitation. I apologize for the inconvenience!

- Ben

DavidEGrayson · July 7, 2011, 11:45pm

Today we released a firmware upgrade (version 1.05) for the Pololu USB AVR Programmer that allows it to program AVRs with 256 KB of flash, such as your ATmega2560. See the “Upgrading Firmware” section in the user’s guide for more information and instructions on how to upgrade your programmer:

pololu.com/docs/0J36/9

I have tested the new programmer firmware with an ATmega2560 and it worked. It should also work on an ATmega2561. As far as I know, those are the only AVRs that support AVRISP and have 256 KB of flash.

When working with these AVRs, I strongly recommend increasing the ISP Frequency of the programmer to speed up programming. The default ISP Frequency is 200 kHz, but if your AVR’s clock speed is over 8 MHz then you can safely use the highest/fastest frequency, 2000 kHz. See the “Configuring Your Programmer” section of the user’s guide for more information.

The new firmware has been tested with AVR Studio 4 and AVRDUDE. Here is an example AVRDUDE command to program the flash in Windows:

avrdude -c avrispv2 -p m2560 -P COM3 -U flash:w:test.hex

Please note that the polarity of the DTR and RTS outputs has changed since firmware version 1.01, so you may have to change your code that uses the DTR line. See the user’s guide for more info on what has been changed in the firmware.

–David

edsut · August 12, 2011, 4:09pm

Hi,
I am trying to program the atmega2560 using avrdude without success.
I issue the command…
avrdude -p m2560 -PCOM1 -c avrispv2 -e -U flash:w:test.hex
I get the error:

avrdude.exe: stk500v2_command(): command failed
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

I just walked through the firmware update procedure, so now I am running 1.05 on my
programmer now; but still get the same error.

I used the programmer earlier today to successfully load an atmega8u2, so I believe the programmer is in good shape. Power and connections are all good. The programmer has 3 active LEDs…
Closest to the header is a blinking yellow.
Next to is is solid red.
On the same edge, but close to the USB connector is solid green.

Any thoughts?

DavidEGrayson · August 12, 2011, 4:54pm

Hello, edsut.

When the red LED on the programmer is on, it means there was some error during the last attempt to program. Please run the Pololu USB AVR Programmer Configuration Utility and tell us what the error is. The utility should be available in your start menu if you recently installed the programmer’s drivers.

–David

edsut · August 12, 2011, 9:28pm

David,
Thanks for responding. I think the issue is resolved. Our hardware has the SPI lines (which are used by the programmer) tied to a few other peripherals on our board.
When we disconnected from those lines, the programmer then worked.
But, now I have a slightly different problem you may be able to help with…

Our board is very similar to an Arduino MEGA 2560 board. Prior to me programming the 2560, I had programmed the mega8u2 (not realizing at the time that I put in the UNO firmware instead of the MEGA firmware). Anyway, I was able to connect to the PC and it was seeing an UNO, and then I realized that I needed to update mega8u2 to have the MEGA-board-compatible firmware.

When I try to program my mega8u2 I am now unsuccessul, can’t even re-install the UNO .hex image (PC keeps telling me unknown device). The only difference I can think of here is that I updated to the new Pololu firmware. Does the new pololu firmware (that I updated to for the MEGA2560) prohibit me from programming a MEGA8u2?

Thanks,
Ed

DavidEGrayson · August 13, 2011, 8:45pm

We have not tested our programmer with an ATmega8u2 but as far as I know there is no reason that it would not work. Was there any error reported by the programmer during programming, or are you just saying that the ATmega8u2 doesn’t behave as expected after programming? You should check the fuse bits to make sure you didn’t accidentally change something important. Firmware version 1.01 of the programmer is available in the programmer’s user’s guide on our website, so you could also try reverting to that if nothing else works.

–David

edsut · August 16, 2011, 2:05pm

David,
Just wanted to let you know the problem was resolved. Thanks for responding.
The issue was a flakey power-on-reset circuit making the 8U2 unstable.
We’re on to other issues now, in particular, rebuilding the ATMEGA2560 bootloader.
I’m not sure if that falls out of the scope of this forum, but if its appropriate I’d sure
be up for some pointers. First, I assume the code is hardware/arduino/bootloaders/stk500v2 (from the arduino git). I can build it and install it, but when I type ‘!!!’ the intial set of…

!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!

comes out, but then its in a loop printing 0xff looking for a terminating 0x00.
The RunMonitor() function calls sendchar in a loop to print out the initial block of
exclamation points (above); but then it uses…

PrintFromPROGMEMln(gTextMsg_Explorer, 0);

to print a message. The data that should be located at the location pointed to by gTextMsg_Explorer is just all 0xff. The strings that are supposed to be printed from memory are not programmed, and not being an AVR guru, I’m not sure how to resolve this. If you have any familiarity with this, I’d be interested.
Thanks,
Ed

DavidEGrayson · August 16, 2011, 5:44pm

I’m glad you were able to get your previous problems resolved.

I took a look at the code in arduino/bootloaders/stk500v2/stk500boot.c and I think I know what’s going wrong (besides the indentation):

void	PrintFromPROGMEM(void *dataPtr, unsigned char offset)
{
uint8_t	ii;
char	theChar;

	ii			=	offset;
	theChar		=	1;

	while (theChar != 0)
	{
		theChar	=	pgm_read_byte_far((uint32_t)dataPtr + ii);
		if (theChar != 0)
		{
			sendchar(theChar);
		}
		ii++;
	}
}

In avr-gcc, the void * type is designed to point to locations in RAM, not program memory. As a result it is only 2 bytes, so its maximum value is 65535, which is not large enough to allow it to hold most addresses in the flash of the ATmega2560. The bootloader is located at the end of the flash memory so this would be a problem. My solution would be to use uint32_t instead of void *.

I might be wrong about this; if this were the problem, then how did the Arduino people ever compile a working bootloader for the ATmega2560? I don’t know, but maybe you can figure it out.

If you want more help with things that aren’t Pololu products, please post in the Robotics and Electronics General Discussion area of the forum instead of the Pololu product support area.

–David

edsut · August 16, 2011, 11:16pm

David,
Just wanted to let you know that things are figured out.
I was building the 2560 bootloader using 1E000 as the start instead of 3E000.
Had to do that because for some reason the image is larger than 0x2000.
I resolved the size by just chopping out some of the monitor commands (don’t know
how this works for the actual author of this code, but my fix is adequate for me).
Anyway, I am able to use the Pololu for both ATMEGA2560 and MEGA8U2 programming.
Thanks for your help.
Ed