Pololu Robotics & Electronics
Menu
My account Comments or questions? About Pololu Contact Ordering information Distributors

Pololu Forum

Programmer/SPI interference


#1

I’ve been using a Pololu USB AVR programmer successfully for months. But I’ve run into trouble after programming a 328p to run as SPI master. Now when I try to re-program it, AVR returns an ISP mode error and suggests to check connections and ISP programming frequency, both of which I’ve tried. The same setup works fine with other 328p chips. I’ve tried grounding the reset pin. I’m guessing there is some sort of interference as the ICSP and SPI are using the same pins, but I thought this would be NA when in programming mode. All other connections to the chip and SPI lines have be removed. Any work arounds or ideas?

Eric


#2

More detail:

The error message I’m getting when using AVR STK500 to program a 328p (on a nano v3.0), with nothing connected but power and programmer, is because it won’t go into programming mode. Also, the SPIEN fuse is not checked on the AVR Fuses page as it is when the programmer is hooked up to a different nano v3.0 that is working with the programmer. I don’t know if this is a cause or symptom of the fact that I can’t get it to go into ISP mode and don’t know how to change it (when I even open the Fuses page for programming AVR STK500 with 328p, it gives me an error because it fails to go into programming mode.)


#3

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

I want to try to reproduce the problem you are having, but in the mean time could you try running the programmer’s configuration utility (pgm03a_config.exe), which comes with the drivers that you downloaded? If you run this program after a failed programming attempt, it should give you a specific error message about why you weren’t able to enter programming mode.

–David


#4

David,

This is what the configuration utility returned after trying programming:

Error from last programming:
The SPI command for entering programming mode was sent, but the expected response from the target was not received. Make sure that the ISP frequency setting is less than 1/4th

I’ve tried setting ISP as low as 4 Khz, without success.

Eric


#5

Hello.

Just to be clear, have you removed all external connections to the reset pin now? To program the device properly, the programmer needs to be able to toggle the reset pin, at least according to the AVR specs.

When you say you programmed the board to be an SPI master, you mean in software, right? Did you change any of the fuse settings? Did you connect anything to board’s SPI pins between the time when you successfully programmed it and the time when programming failed?

- Ben


#6

Ben,

"Just to be clear, have you removed all external connections to the reset pin now? To program the device properly, the programmer needs to be able to toggle the reset pin, at least according to the AVR specs " :

As of now, there is nothing attached to the nano but power and programmer.

“Did you connect anything to board’s SPI pins between the time when you successfully programmed it and the time when programming failed?” :

I did have a separate nano(which I can still program) hooked up as slave after loading the Master SPI code. The connection between the two chips was via standard SCK, MOSI, MISO, SS pins. They did appear to be sharing data, but I was not getting the numbers I was expecting. I was trouble-shooting this when I ran into the programming problem.

“When you say you programmed the board to be an SPI master, you mean in software, right?” : yes

“Did you change any of the fuse settings?” : If I did, I don’t know how. However, as mentioned to David the SPIEN fuse is not checked on the AVR Studio Fuses page as it is on my other chips, so perhaps I did, but not because I did anything intentionally to make this change.


#7

I wouldn’t worry about that at all. You must be able to enter programming mode to read the fuses from the device. Since you are unable to enter programming mode, the fuse values shown by AVR Studio don’t have anything to do with the actual device fuses.

One reason for my previous questions is I’m wondering if you could have done anything to damage the SPI I/O lines, such as shorting two outputs together that are driving in opposite directions. Is there any sign that your previous program is still running on the device? Did anything noteworthy happen the first time programming failed (or right before it)? For example, did the device lose power, did AVR Studio crash, etc?

- Ben


#8

Ben,

Now that I’ve looked a little closer, while the power light is still on, the nano does not appear to be running properly. I guess I should have checked for other discrepancies with the chip sooner after I could not program it. I well may have crossed the SCK, MISO, MOSI lines as I had been taking them in and out in between loading new code and running, I’ll have to be more aware that this can cause damage in the future. Thanks for taking the time to help me try and run this problem down.

Eric