After a day’s worth of time resolving ‘Connecting Error’ with AVR 4 and the Pololu USB AVR Programmer (reinstalled XP SP3),
I have busy programming my 3pi for a Maze competition this weekend.
Tonight the first programming attempt failed and subsequent attempts displayed a ‘ISP Mode Error’.
Batteries were fresh from an overnight charge, and I had checked the program load from the previous day.
Also the 3pi looks dead: blue light but no powerup LCD msg, no beeps.
The Pololu USB AVR Programming Config Utility comes up as before and able to reload the AVR USB Programmer firmware (v1.01) as before.
Reloaded the USB driver, same error. SLO-scope works ok.
Its possible something glitched and one of the programming settings have changed but nothing obvious stands out.
I searched the Pololu forums, troubleshooting guide and the net; nothing found has helped.
If the processor is suspect fried, I can swap the ATmega168 (to ATmega328) at work ( SMT assembly plant)
but hopefully this can be resolved by easier methods.
I have had this 3pi for a couple years now and its the first trouble I have had;
now worried I won’t have a bot for the Robot Rally this weekend.
I’m sorry to hear you’re having trouble with your 3pi. Just to be clear, have you previously programmed this 3pi successfully with your exact setup? How soon after your “connection errors” were resolved did the ISP mode errors pop up? Did anything noteworthy happen just before you received the ISP mode error (e.g. loss of 3pi power, AVR Studio crash, etc)? Can you use the programmer configuration utility to look at why the last programming attempt failed?
One explanation for your problem is that the clock fuses somehow got changed. If they were changed to a lower frequency, you might be able to communicate with the 3pi at a lower ISP frequency. Can you lower your programmer’s ISP frequency to the slowest setting and try reading the device signature? (Don’t forget to set the ISP frequency back; I thin the slowest setting will cause a timeout error if you try programming the flash.)
If that doesn’t work, the next step is probably to replace the AVR, unfortunately. We can do that for you if you send it back to us, but it sounds like it will be faster and easier for you to do it yourself. If you do end up going that route, please let me know and I can give you the appropriate fuse settings for the new AVR.
I was successfully programming the 3pi with the exact setup, download new code and running the 3pi for the last few days.
At the exact time the fault happened, I had just replaced the batteries, turned it on, checked the last program installed on the 3pi (it was ok), started a new download. The download did not complete, expecting the 3pi to beep after programming.
Looking back at the PC, I could not close the programming window and the system acted differently. Reconnecting the AVR programmer through AVR Studio. I can’t say it was the programmer, AVR studio or the PC but it can be classified as an event and afterwards the 3pi would no longer program.
Before I realized I was in trouble with the 3pi programming, I had cleared the previous programming attempt.
I tried to read the signature: using the AVR Studio programming utility, all attempts with lowering the ISP clock frequency fails.
If the clock fuses changed, are these irreversible one-time fuses ? Can they be reset with the AVR Programmer? Or need a different method or hardware?
Learning as I go… the Atmel platform is new to me, background is with the Microchip PICs.
Changing the processor looks like the next action, the fuses setting and related programming process links would be helpful.
Thanks,
Frank
The AVR fuse settings are intended to be reversible, but doing so in practice can be quite difficult if you’ve changed the fuses in a bad way. For example, if you change the clock fuses so that the AVR is trying to run off of a clock signal you are not actually supplying, you will not be able to reprogram the AVR again (or change the fuses) until you set it up with the appropriate clock for your new fuse settings. I believe you can get around this with a special, high-voltage programmer, but that is not a practical method of in-system programming.
I think your next step should be to replace the AVR. Assuming you are putting an ATmega328P on there, you can configure it properly by running the following avrdude command with your programmer connected to the 3pi:
Note that you will need to replace the x in COMx with the actual number of your programmer’s programming COM port (e.g. “COM5”). Also, note that you must not use your programmer’s fastest ISP frequency as this is too fast for initial programming (ATmega328ps run at 1 MHz, and the programming frequency must not exceed 1/4 of this, or 250 kHz). I suggest you use the programmer’s configuration utility to set the frequency to 200 kHz for this initial programming. Once the fuses are set properly and the 3pi’s AVR is running at 20 MHz, you can increase your programmer’s ISP frequency to the maximum (2 MHz).
Assuming the programming goes well, I suggest you then load the demo program on there and test out all the features (motors, LCD, sensors, etc) to verify that all of the MCU pins are properly soldered and all the connections are good.
Please let me know if you have any questions or run into any trouble.
