AVR Programmer - Issue pulling down reset line on a Nano

I bought one of the Pololu AVR Programmers V2.1 from a UK distributor. Great little programmer.

I was using it with Arduino Nano’s (Chinese clones) to upgrade or remove the bootloader. I have 2 different lots of these. The first lot worked right off the bat, and the second lot, which is already installed in circuits and hard to remove, won’t work. (I initially suspected in circuit shorts etc, but that wasn’t it…see below). I always get: “avrdude: initialization failed, rc=-1”

I have spent 2 days poking around the situation with a scope and logic analyzer. I checked wiring 15 times, powered the Arduino from Pololu Programmer or independently, etc etc and all of the combinations. I found, that using the logic analyzer, I can perfectly follow an avrdude session (just reading fuses to keep it short) hex-byte by hex-byte on the lot of Nanos which do work.

However. on the ones which don’t work, I can see data on the MOSI line (AC, 53, 00, 00) but there is “no clock” on SCK. So the Nano doesn’t realise it is being talked to and therefore doesn’t reply.

Why is there no clock? If I look with a scope rather than a logic analyser I can see that the Pololu AVR Programer is trying to drive the clock, but it only manages ~0.1V of square wave.

But if I remove the 6pin header plug and measure directly on the end of the cable, it’s fine. Like there is a short on the Nano or in the circuit. Except there isn’t. It turns out that it’s the BUILTIN_LED (digPin13) which is configured as an output somewhere in the running code, and fighting the clock. So why is it doing that when it is being programmed? It’s not supposed to be running code and it should be putting its digital pins into tri-state? I proved that it’s running code, by uploading a sketch which sets the Pin13 SCK as an input. The behaviour changes massively, and we now have a clock, but it still doesn’t answer.

The plot thickens…

Looking more closely at the other signals it tuns out that the lot of Nano’s which don’t work, don’t recognise the RESET signal from the programmer. Therefore they don’t stop running, fight the clock with their BUILTIN_LED output, and can’t possibly enter programming mode (for more than one reason).

The scope shows that the RESET is a nice 0.1V → 4.9V range when I just plug straight into the header cable without connecting it to the Ardunino. But if I connect to the Arduino, the range drops to ~1.6V → 4.9V.

According to section 28.2 in Atmel’s 328p datasheet the valid maximum for a logic low on the reset line is 0.1Vcc so 0.5V. We are way above that, at ~ 0.3Vcc. No wonder it is not resetting reliably. The voltages are actually very similar on both the working and non-working lots of Nanos, but we are in “undefined” territory here, so any small difference could easily make it tip one way or the other.

The same section in the Datasheet recommends a 30-60kOhm pullup for the reset line. All my Nanos (both lots) are using a 1kOhm! This is both according to the schematic and measured in the circuit as that. So this is “not the Pololu Programmer’s fault”, because Arduino have designed the Nano with a RESET pullup which is 30x smaller than the minimum recommended value. Perhaps the reason they did that was to compensate for the capacitor hack on the DTR line of the USB chip and keep a reasonable time constant? Could have just used a smaller cap? So there is also a significant cap charging response on that reset line as well. Anyway… It’s not great.

I experimented with the 6 pin flat cable not plugged into the Nano and a 22kOhms up to the Vcc pin (with Vcc Output=enabled on the Pololu). We get very nice signals. At less than 10k we are entering dodgy territory and at 1k it’s a disaster.

Oh, and I worked out that if I press the manual reset button while connecting with avrdude via the Pololu programmer, then… it works fine. And the scope/logic analyser show proper reset levels => proper clock => the AVR answers => the “fuse read operation” works just fine. – Note: I realise that this is a) not practical and b) not good for the Pololu Programmer to hard clamp it’s RESET output like that.

I think the fact that I have Chinese clones is probably irrelevant here, since the official schematics have that 1k pullup (actually it’s one quarter of a 4x1k resistor array).

So what do you suggest?

Is the Pololu Programmer not reliably suitable for Nanos?

Is there a mistake in my thinking? – You should easily be able to reproduce the out-of-spec voltage range on the Pololu RESET output by poking a 1kOhm into the RESET and VCC pins on the end of the flat cable with 5V Vcc output enabled. I get ~1.5V → 4.9V. What do you get? Note: I re-emphasise that am not saying the Pololu design is wrong. It is just that it may not be compatible with the 30x out of spec RESET pullup on the Nano. It looks like the Uno uses a 10kOhm in that place with the same 100nF cap on the DTR line. That should (just about) work fine with the Pololu. Why they chose a 1k on the Nano is beyond me – probably just because they had a spare 1k on one of the arrays?

Have I missed a trick? - I did think of using a couple of transistors to amplify the Pololu Programmers pull down capacity on the RESET line. – would probably work, but would be messy. – Update I breadboarded this and it works 100%. Lovely 0V => 5V range on the RESET line now. The Nano resets fine and ICSP sessions work every time and with all Nanos I ave access to. Going to make a more permanent version to splice into the 6pin flat cable.

It’s not super pretty. But it works 100% better. Can anyone suggest some other solution?

BTW what are the “STK500 hardware/software version” settings in pavr2gui? I found no docs on those.

Many Thanks

I guess for a prettier and more permanent solution, if the next version of the Pololu AVR Programmer wants to support Arduino Nanos (which are unlikely to change), it might include something similar to this SN74LVC1G34 “Single Buffer Gate” on the RESET output:

This is available in a tiny 0.8mm x 0.8mm “DPW” package and provides a proper push-pull output stage, as opposed to my rather Heath-Robinson, open-collector cludge. The open-collector gives a rather slow cap-charge rising edge (time constant 100us) whereas that buffer, with its 30mA+ drive, should fully charge that 100nF cap on the DTR line in < 10us.

Hello.

Please note that our name is Pololu. (I have corrected the misspellings throughout your posts.)

All of the I/O pins of the Pololu USB AVR Programmer v2.1 are protected with 470 Ω resistors, as mentioned on the product page. If the target AVR board has a 1 kΩ pull-up resistor on its reset line, the programmer would only be able to pull its voltage down to 0.32 VCC. That number comes from calculating 470/(1000+470).

The programmer’s resistors are there to protect the programmer and the board it is connected to, and they usually do not cause issues since AVR boards generally have a higher pull-up on their reset lines. By the way, the specification you found in the datasheet for the reset pull-up resistor just refers to the internal resistor in the AVR, not an external one. However, according to the debugWIRE section of the ATmega328PB datasheet, if you want to use the debugWIRE interface, then “Pull-up resistors on the dW/(RESET) line must not be smaller than 10kΩ”.

Therefore, my main recommendation would be to replace the resistors on your Arduino Nanos with higher values. If that is not practical, you could also reduce the resistor on the programmer.

Regarding the STK500 hardware/software version numbers: The programmer emulates the STK500 device from Atmel, and some Atmel tools will read those numbers from the programmer and encourage the user to upgrade the STK500 firmware if those numbers are not what it is expecting. You should not change those numbers.

–David

Sorry about the typos.

OK, I hadn’t seen that. I just noticed that there was no schematic as the design is closed, and decided to rely on examining the situation from the outside. But yes, 0.3Vcc, as confirmed by measurement, makes sense. And yes, makes sense they refer to internal value. on spec sheet.

However, this state of affairs - that the Pololu Programmer has 470Ohm and that tens of millions of Arduino Nanos out there have 1K pullups, really makes these 2 products incompatible with each other. Debug Wire is not used with Arduinos, it is a proprietary Atmel protocol used only with Atmel Studio. It is never part of the Arduino toolchain.

Modifying the Arduino external 1k pull up is just as unrealistic as modifying the Pololu programmer 470Ohm Protection resistors - especially without a schematic. Nor is my heath robinson solution realistic for more than stopping me throwing the Pololu in the bin.

Your Pololu programmer page doesn’t reference the Arduino Nano directly, it terms of either being compatible or not. It does reference other Arduino products though.

I would not have and should not have bought your product, because it is fundamentally incompatible with Arduino Nanos. I spent 2.5 days getting to the bottom of why. It would be good if you could acknowledge that and put a warning on your product page, against using it with Ardunio Nanos. It’s a widepread product, certainly in Europe, I believe the most popular Arduino.

Respectfully.

We have updated the way we refer to Arduino boards on the product page for the programmer and added a description of the problem to the “Supported AVR microcontrollers” section of the user’s guide.

By the way, it should be pretty easy to short out the relevant resistor by making a solder blob over that resistor, which is a lot easier than replacing it with a different value, so you do not need to be particularly good with a soldering iron. I circled the resistor for the RST pin in the image below in case you want to give it a shot. (You can confirm that it is the correct resistor by making sure the right end of it has 0 Ohms of a resistance to the programmer’s RST pin.)

–David

Fair play to you. That’s good.

470Ohm: Yes, I put a meter on the PCB after your last post, found the resistor, removed it and put a bridge there. - But your simpler suggestion of a blob would also work for someone who is not comfortable doing that.

So I removed my 2 Transistor “amplifier” out of the cable. Works great and is less ugly. TBH if i had found a schematic when the problem first occurred, I would have spotted the 470 Ohm and immediately realised that was the problem - then removed one of them.