Pololu USB AVR Programmer appears to be defective

Support Other Pololu products
1

Hello,

I had been playing with my programmer (pololu.com/catalog/product/1300) for a few hours with my hardware, the ATmega 1248, and it worked flawlessly out of the box, for multiple flash write cycles. Specifically, I’m using avrdude; my command line options are usually something to the effect of:

avrdude -p m1284p -P /dev/ttyACM0 -c avrispv2 -F -e -U flash:w:foo.hex

And after enjoying myself for a few days playing with my hardware the programmer suddenly seems to have become unreliable with both of the uC’s I have on my PCB.

paste.pocoo.org/show/475134/
paste.pocoo.org/show/475117/

Sometimes the write “works” (the program runs as intended), sometimes not. Sometimes, I even get:

paste.pocoo.org/show/475135/

The target is powered by a power supply, not batteries.

I’m not sure what exactly cause this, like I said when I first started playing, it had worked a majority of the time, and it was only suddenly that this issue happened.

My thoughts are that either the programmer has catastrophically failed, or that the 6-pin ISP cable is too long and/or bad (or that avrdude is a self-modifying binary and through some sort of sorcery modified itself to suddenly exhibit that behavior whilst at the same time rooting my machine in order to gain write permission to itself; equally likely ;P). Because the input voltage to my circuitry has been constant the entire time, and I’ve tested two different cpus on two different isp circuits (which are both PCB’s, and not something I hacked together on a breadboard), I would like to also suggest to eliminate those as a possibility as well.

Thank you,
Zack Buhman

2

Hello, Zack.

I’m sorry you are having trouble with the programmer.

I think that the first output from AVRDUDE that you pasted ( paste.pocoo.org/show/475134/ ) is what you would see if avrdude waits too long after erasing the chip but before sending the first write command. The programmer will automatically leave programming mode during the long wait, and later when avrdude does send the write commands the programmer will refuse to respond and avrdude will report a timeout.

You most likely have firmware version 1.01. In firmware version 1.05, we increased the programmer’s timeout from 350ms to 1400ms, so this version might work better for you. Please try upgrading to version 1.05:
pololu.com/docs/0J36/9

Do you know why avrdude might be waiting such a long time (>350 ms) before the first write command? Does your hex file begin with a huge block of 0xFF (all bits set to 1)? Are you using a particularly old computer, or is the CPU under heavy load?

–David

3

Also, I noticed that you are using the -F option to override the signature check. For your m1284p, the correct signature is 0x1e9705 but avrdude is reading 0x1e9706. For your attiny45, the correct signature is 0x1e9206 but avrdude is reading 0x1e9209.

Do you know why this is?

–David

4

Mr. Grayson,

Yes, because I have the 1284 (non-p) and the 48, neither of which are “supported” by avrdude directly. However, as I’ve been told (and from experience), targeting the 1284p and 45 (respectively) works just fine. The -F is intentional and deliberate.

I was actually half way through the instructions to play with the firmware upgrade idea before I read this. I was indeed running 1.01. The upgrade to 1.05 seemed simple enough–hardest part out of the whole process was using a staple to short out the bootloader pads, but that should be hard to do; makes sense.

And like magic, it works again! Any ideas on why 1.01 worked initially and then started failing miserably? I have no idea why avrdude would be waiting too long. My load average is 0.01, 0.05, 0.02. And it’s not just that hex file, it (used to be) more or less anything that avr-gcc/objcopy spits out.

paste.pocoo.org/show/475461/ (normal/expected/now-working avrdude output)

As long as 1.05 continues to work; I’ll be happy.

Thank you,
Zack Buhman

5

I do tell avr-gcc to target the tiny48, by the way, (because that part of the toolchain does support the 48), for example, but as far as uploading the hex goes, apparently the 45 and 48 are similar enough for programming to be successful.

6

I am very glad that you were able to solve your problem by upgrading the firmware. I don’t know why it stopped working earlier. Maybe your hex file got bigger (and slower to process) as you added features to the firmware.

–David

7

Actually that appears to not be it.

Would it be possible that my board’s circuitry could potentially damage the firmware of the programmer?

After awhile of playing with 1.005, it eventually started behaving similarly to 1.001 (where it wasn’t responding to avrdude, but still functioned–albeit very slowly). I repeated the firmware “upgrade” process (1.005 to 1.005), and that seems to have fixed it again, and it behaves normally.

What seems to be going on here?

8

EDIT: oh my, 1.3mb is too big for this forum, I’ll put it on my server… 98.23.163.248/hardware-sch-pcb.pdf

For anyone interested, I’ve (supposedly) attached the schematics of my board (and/or one negligibly different from that).

This is being designed by (former) undergraduate students, so I’m willing to accept that there’s some sort of problem with my board. Specifically, trouble starts occurring when I try to start experimenting with the board without using the API they’ve provided (which insulates me too much and is much too limited). My example code is very trivial/simple: paste.pound-python.org/show/12494/ I’m simply attempting to turn my LED attached to PD6 (as you can see from the diagram) on and off. There’s supposedly a 20mhz oscillator that’s supposed to be controlling the cpu clock, but for whatever reason, (not knowing exactly what voodoo the firmware/api do behind my back), it seems to be running at 1mhz using that code.

If the board currently has the “firmware” (for which I do not have the exact sources to) loaded, avrdude doesn’t complain when that code is uploaded. However, it is only after the board resets itself that the most bizarre nonsensical and inexplicable things start happening. On the second consecutive avrdude upload attempt I get the much-too-familiar “avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature.” I fiddle with unplugging the programmer from both the board and the computer, and in conditions which I can not exactly pin-down re-uploading the firmware or a program linked against their api sometimes works.

Specifically, after the first upload of “normal” avr code, anything after that (without unplugging programmer from my computer), the programmer does this unusual blinking pattern where the green and red led’s are solid, and the orange one blinks repeatedly while the programmer is plugged into the target. If the programmer is unplugged from the target, the orange led stops blinking, and starts again when plugged back in. The red LED will stay solid until the programmer has been unplugged from my computer.

Under whatever conditions, after avrdude fails again after restarting both the programmer and the target, the solid-red-led pattern resumes. I’m not sure how exactly I escape this: I can consistently reproduce the failure (well, until I prove that I can’t), but the conditions under which I can un-fail this seem completely random.

I guess the question (other than “how do I fix this?”) would is there something that I’m supposed to know that I’m supposed to do with every program that hides this seemingly nasty hardware bug. Also, the right PWM motor brakes for no apparent reason with that example code (so there’s obviously multiple caveats to this board).

9

There is a setting in the programmer’s EEPROM called ISP Frequency which controls how fast it will program. The default value is 200 kHz, which is encoded as a 3. If your programmer gets slow, you can try supplying the “-B 3” option to avrdude (instead of reloading the firmware) to set the ISP Frequency back to 200 kHz. Let me know if that helps.

Thank you for sending us those detailed design files for your board!

I think the most likely problem is that the SPI lines of your AVRs are connected together, and also connected to two slave SPI devices. Those lines are used during programming. Are you sure that none of the other devices on the board will try to drive SCK or MOSI while the programmer is programming an AVR? If not, this could explain why the programmer reads a device signature of 0. This is a complicated issue; you’ll need to look at the datasheets of the devices, figure out what happens to the voltage on the slave select lines when the AVR is in programming mode, and also ensure that the firmware you load onto each AVR sets the SPI lines as inputs while the other AVR is being programmed.

We have a similar situation on our Orangutan SVP-324, which has an auxiliary microcontroller connected to the main AVR. Whenever the auxiliary microcontroller detects that the AVR’s reset line has gone low, it stops driving the SPI lines. This means that an external AVR ISP programmer can safely be used with the Orangutan SVP.

I noticed a couple of other things amiss:

  1. If I’m reading it right, your “Power flow” diagram says that the ATmega324p powers the ATtiny48 but in fact they are both powered from the CPU-VCC node.[/li]
  2. You wrote “ATmega32” in a couple places on your schematic when you really meant ATmega324P. The ATmega32 is a different chip; you should make sure you are looking at the correct datasheet and not confusing the two chips.
  3. In your example code, you are writing to DDRC when you should be writing to DDRD instead. Did that code work?

The clock speed of the AVR is determined by its fuse settings, not the firmware. You can read and write the fuses using our programmer, but be very careful because setting an incorrect clock fuse could permanently disable the AVR.

This is not an unusual blinking pattern. The LEDs of the programmer are documented here:
pololu.com/docs/0J36/1.a
To find out why the red error LED is on solid, you could compile and run PgmCmd from the Pololu USB SDK.

–David

10

Just to expand on this a bit more, as David said, the clock that your AVR uses is determined by its fuse settings. The default fuse settings for your AVRs configure it to use the internal RC oscillator, which runs at 8 MHz, divided by 8, which gives you the 1 MHz you’re observing. If there is indeed a 20 MHz external oscillator on there and it is connected properly, you can change the fuses to let that drive the CPU clock, but as David says, this can be very dangerous if you don’t know what you’re doing.

- Ben

11

I never claimed to know what I was doing. The code didn’t really work, the LED just turned on very dimly.

I did in fact mean DDRD; thank you. So I started playing with that a bit, and ended up with paste.pocoo.org/show/477637/ which properly alternates the green and red LED’s at an acceptable voltage.

The hex generated from that code ends up being 282 bytes, which uploads without problems.

But when I try re-uploading the 14k firmware, it is noticeably slow. I then added -B 3 to my arguments, as you suggested, and that made it upload as I would normally expect. How/why would the programmer frequency change without me (as far as I can tell) having told it to do so?

As far as the SPI SCK MOSI stuff; I would imagine since I’m obviously not doing anything with those at the moment, that that might be where some of the trouble is.

Thank you both,
Zack Buhman