I have the same problem. I received yesterday my new Pololu 3pi and I tried to save some programs. The program test let me knew how much voltage had the batteries when I tried to save the program . The voltage was around 3.4 volts. First time I programmed the 3pi works fine but later the programming process was interrupted.
Now, when I switch on the 3pi the displays shows only black boxes and blue leds are on.
I readed the label in the box that said “Losing power during programming could permanently disable your 3pi”.
Will be possible to recover the Pololu 3pi replacing the ATMEL Mega 168 processor ?
If your battery voltage was 3.4V, it means your batteries were almost dead; you definitely should not be trying to program your 3pi with batteries this low.
Can you try setting your programmer to a lower ISP frequency and see if this lets you read the device signature?
I apologized for the delayed reply. It sounds like your 3pi has a corrupted microcontroller. The only thing I can suggest is that you send the 3pi back to us so that we can take a look at it. Please mail it to our address as listed here and include your name (Andre Luis), a reference to this thread and a return address to which you want the robot shipped.
I am teaching a Robotics AI subject at the University of Huelva in Spain. I need a way to solve this problem if I want to use the 3pi robots for teaching. I searched for a way to reset the Atmel Mega but I did’nt find a solution at this momment. My students have to program the robots several times for class and sometimes is not easy to know how lower is battery power. I think this problem will happend again.
Will be enough to change the Atmel Mega 168 processor or I need to make other changes?
If attempting to program the unpowered microcontroller is what caused your problem, and it sounds like it is, replacing it will fix it (this is the only solution we know of once the chip becomes unprogrammable). Do you have the tools/experience to replace the ATmega168 yourself? If not, you can send it back to us to take a look at; just make sure we can identify who its from and where to return it. Before trying to replace it, I recommend seeing if you can talk to the 3pi at a lower ISP frequency. If so, you can fix the problem by resetting the fuses with a programmer running at this lower frequency.
It shouldn’t be too difficult to keep this from happening to your students. All of our sample programs display the battery voltage at start-up, and you should encourage your students to add this feature to their programs as well. You can obtain the battery voltage in millivolts by using the read_battery_millivolts_3pi() function from the Pololu AVR library, and you can display the value it returns on the LCD using the print_long() function. If the battery voltage falls below 4.5V for NiMH cells, we strongly recommend you replace them with freshly charged batteries before you program! You could even program the 3pis to emit an annoying string of beeps once the battery voltage is too low.
By the way, you might want to take a look at the following post by Jim Remington:
At the bottom of the opening post, you can see a plot of battery voltage versus time for an idle 3pi. Note how precipitously the voltage drops off once it falls below 4.5V.
I am waiting for the Atmel Mega 168 processors with the same package you used in Pololu 3pi. I would like to replace by myself in order to have a way to repair the robot in case that problem will happends again. Any case, if I decide to send you the 3pi I will write you before.
If you do replace it yourself, you will need to program the fuses so that it’s using the correct clock source. If you have a functional 3pi handy, you can read the fuse values off of it to see what they should be initialized to on your repaired robot. If not, please let me know and I’ll post what the fuse bytes should be. I also recommend you initially program the repaired 3pi with the 3pi demo program hex file:
Thank you very much again. That information is very usefull for me.
When I will receive the Atmel processor I will write to you in order to know the correct fuse values. Can you recommend me some company where I can buy exactly the same Atmel Mega 168 processor that is used in Pololu 3pi?
We don’t currently list any in stock, but if you backorder one (or a few, in case you want some backups), we should be able to ship it out within a day or two.
If the problem is it the microcontroller, in my 3PI, you can send me only firmware of microcontroller?
Or, if I buy the new atmega168, you´ll be send it right to work?
Don´t have any solutions without that I send my 3PI?
The microcontroller on the 3pi doesn’t have any firmware; it’s simply an ATmega168 that you can program with your own code. It sounds like the chip itself is damaged or in a state that makes it unprogrammable. You could replace the mega168 yourself, but I would only recommend this if you have the proper experience and tools for desoldering and resoldering a surface-mount IC. You can see the mega168 on the 3pi PCB… is that something you would feel comfortable desoldering? Do you know anyone who has the skills and tools to do it for you? If not, the only alternative I can suggest is sending it back to us.
There are a few steps I recommend you take to test your rework job:
The first thing you should do after you replace the chip is to test for unintended short circuits. Visually inspect all your solder joints (preferrably under a microscope) to make sure the connections look good and there are no solder bridges to neighboring pins/traces.
Connect power and look for abnormally high current (note that the IR leds on the reflectance sensors will be on, which makes the total normal current draw around 100 mA).
If everything looks good, connect your programmer and try to read the device signature.
If this is successful, program the fuses using the following avrdude command-line instruction:
You will need to change COM9 to the port your programmer is on (you can find this using the device manager if you’re running Windows). If you are using the Orangutan USB programmer, the programmer protocol of avrispv2 is correct. If you are using a different programmer, you might need to change this to something else (e.g. avrispmkii).
The fuse settings configure the brown-out detection level to 4.3V, unprogram the CKDIV8 bit so that the system clock is no longer divided by 8, and select for a full-swing 0.4-20MHz oscillator with 1K CK start-up time from power-down and 14CK + 4.1 ms additional delay from reset.
Program the 3pi with the demo program that it ships with. You can find the hex file for this program in the the Pololu AVR library at the path:
I followed your recommendations. I replaced the Atmel MEGA168 and then I inspected the chip with 20x lens. After resoldered some joints, all looked correct.
Then I connected the power and the IR leds switched on, the LCD shown the same as before changed the chip, I mean, a line of black boxes. Finally I tried to read device signature with AVR Studio 4.16 Build 628 using Windows XP with STK500 and AVRISP programmers, showing allways the same error:
ISP Mode Error
A problem ocurred when executing the command. Make sure you are using the correct programming method. Current mode is ISP. See the command output for more info. …
I tried to execute avrdude command in Windows getting the following error:
D:\WinAVR-20090313\utils\bin>avrdude -p m168 -P COM9 -c avrispv2 -e -U lfuse:w:0
xF6:m -U hfuse:w:0xDC:m -U efuse:w:0x01:m
avrdude: stk500v2_command(): command failed
avrdude: stk500v2_command(): unknown status 0xc9
avrdude: stk500v2_program_enable(): cannot get connection status
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude done. Thank you.
I soldered the ATMEGA168 manually. I have no access to a IR solder, so I am not sure if I over heated the chip.
This is a little bit frustrating situation because some students are waiting for the robot to continue with a project.
Any case, thank you very much for you time, for your fast and accurate answers and your attention.
If you have any suggestion about what I have to test now I will be very pleased to know.
I’m sorry to hear that things still aren’t working. Are you using our Orangutan USB programmer? Have you verified that the programmer is functioning properly, perhaps by trying to program a different AVR-based device such as another 3pi? Can you use AVR Studio to determine the ISP frequency of the programmer (look under the Main tab of the AVRISP programming dialog)?
It seems to me like there are four possible things that could be wrong, so we should try to narrow down which it is:
The mega168 is not soldered properly, leading to poor connections or shorts. Were you careful to align it so that pin 1 is soldered to the correct pad? Can you post a high-resolution picture of the mega168 on the PCB?
The mega168 was damaged when you soldered it.
There is a problem with the programmer.
The programmer is set to an ISP frequency that doesn’t let it talk to the new microcontroller. Before you configure the fuses on the mega168, it is running at 1 MHz rather than 20 MHz, which means that some programming frequencies that work for a configured 3pi will not work for one that still needs to have its fuses set.
I am using your Orangutan USB programmer. We buy a pack Pololu 3pi+Programmer. Before 3pi death I reach to programm two or three times. So I supose the programmer is working properly. I haven’t got at this momment another 3pi, sorry I tried to change the ISP frequency of the programmer with AVR Studio. I changed the frequency without problems, but was not possible to program 3pi at any frequency.
About your options, that are my suggestions:
Pic’s mark is in the same way as the picture you published in the web, left up conner (looking the boar front the opposite side of the LCD, with the center ball in the bottom). I checked first lines connections and looks fine. I will try to send you some pictures next week.
That is possible.
Will be possible, but I saved some programs with this programmer before 3pi death.
Can I do something to solve it if I can’t save the fuses?
Did you make sure to press the “Write” button to apply the ISP frequency change before you tried to use the programmer on the 3pi? The goal would be to see if you can read the device signature at one of the lowest ISP frequencies. If you cannot, the problem is most likely due to a damaged or mis-soldered ATmega168, in which case I see your only options as (1) rework it further, (2) try replacing the chip again, or (3) send it back to us to take a look at. I would still be interested in seeing a high-resolution picture of the replaced mega168.