I've noticed (and this may not be new, as I'm peeling the onion on multiple issues) that when I power up the board, if the board has been unpowered for some time (more than 5 seconds), the uploaded application does not run, and pressing RESET has no effect. A scope on pin 13 shows it doing the 3x blink once per second. It also shows that the RESET line at the ATMEGA328P appears to remain high while the blinking is occurring.
If, however, I cycle power on the board (remove power and replace it within a few seconds) the board powers up into the application immediately and the blinking on pin 13 does not occur.
If I then press the RESET button once, pin 13 goes high three times, and then the application starts.
If I press RESET a second time, the board goes into the 3x blink once per second mode and pressing REST again has no effect. Power must be briefly cycled.
When the board is in this "repeated blink" mode, it is possible to upload a sketch to it, and after upload, the sketch runs.
(Note, I do not have an LED hooked up to pin 13, though when I suspect this problem is occurring, I plug an LED with a resistor to ground into pin 13 and I can see it blink.
Recently, I had to use an ISP programmer (an Arduino Uno running ArduinoISP and properly wired) to overwrite a sketch which was preventing uploads. I overwrote the offending sketch with the Bare Minimum example.) Afterwards, I was able to upload normally (via the IDE, not the ISP) successfully.
The only thing I can think of it takes 5-8 seconds for C12 to fully discharge, and wonder if the time required to recharge it delays the rise of the RESET line and the board then behaves differently.
I am wondering if others are seeing this, or if there is a bootloader for this particular board that I can flash with my Arduino ISP, and how I might go about doing that?
Constant "reset" under certain power-up conditions
Re: Constant "reset" under certain power-up conditions
Sean,
Thanks for your troubleshooting. I hadn't noticed the behavior on pin 13, because there's no LED on the line, so thanks much for that observation. It surprised me that we had never seen this troublesome behavior during our testing - but it may be because the software upload seems to cure the condition - software reset also does not trigger the condition.
I have seen and gotten part-way to the bottom of this issue. It's some kind of interaction between FTDI chip and Atmega with a slow powerup. This is some kind of timing issue with Optiboot - which has been way "sub-optimal" in my book, with seemingly unending problems with Windows users. It may be just the FTDI chip (or drivers) and Optiboot, which don't want to play well together on startup at least.
What's curious is that in the locked (or constantly resetting) condition - the reset won't reboot the program into running the program - and a power cycle is required. There is a curious low-going pulse on the reset line during power-up that appears to be associated with the condition. A scope trace of the reset line is shown below.
Here are some cures:
As Sean said, recycle the power fairly quickly. This is of course sub-optimal but it works.
Prologue:
The real cure was an updated version of Optiboot in Arduino 1.0. If you have the ISP hardware, update your Arduino installation to Arduino 1.0 and burn the new Optiboot bootloader by choosing the "UNO" in boards menu.
You can also choose the Deumilanove bootloader as the board if you wish.
You'll need to then use the Duemilanove setting in the Arduino Tools->Boards menu.
I will of course reflash anyone's board who wants to send it back. Email us for a shipping label.
Here are the steps to burn a new bootloader:
You will need an ISP programmer such as an AVRISP MKII or Lady Ada's Tiny ISP to fix the problem yourself. Here are the steps to perform the fix.
1) Download Arduino 1.0 and install it. Install the FTDI drivers if not already installed - Windows users should update to latest FTDI drivers.
2) Hook up the MKII (or whatever serial programmer you are using) - Windows users may need to install a driver for the MKII
3) Power up the FHB with either a wall adapter or a USB cable
4) You should see the light on the MKII turn green if you are using that ISP
4) Set Tools -> Programmer to the programmer you are using
5) Set Tools -> Boards to UNO (default choice) -> You are also free to put the older Duemilanove bootloader on the board if you wish
6) Choose Tools -> Burn Bootloader
7) The lights on the MKII should turn orange for a bit - and the Arduino IDE should report "Done Burning Bootloader"
8) Try uploading a sketch to the FHB, pressing the reset button, removing and reinserting power (after a 15 sec pause) to make sure the board is fixed.
Paul
Thanks for your troubleshooting. I hadn't noticed the behavior on pin 13, because there's no LED on the line, so thanks much for that observation. It surprised me that we had never seen this troublesome behavior during our testing - but it may be because the software upload seems to cure the condition - software reset also does not trigger the condition.
I have seen and gotten part-way to the bottom of this issue. It's some kind of interaction between FTDI chip and Atmega with a slow powerup. This is some kind of timing issue with Optiboot - which has been way "sub-optimal" in my book, with seemingly unending problems with Windows users. It may be just the FTDI chip (or drivers) and Optiboot, which don't want to play well together on startup at least.
What's curious is that in the locked (or constantly resetting) condition - the reset won't reboot the program into running the program - and a power cycle is required. There is a curious low-going pulse on the reset line during power-up that appears to be associated with the condition. A scope trace of the reset line is shown below.
Here are some cures:
As Sean said, recycle the power fairly quickly. This is of course sub-optimal but it works.
Prologue:
The real cure was an updated version of Optiboot in Arduino 1.0. If you have the ISP hardware, update your Arduino installation to Arduino 1.0 and burn the new Optiboot bootloader by choosing the "UNO" in boards menu.
You can also choose the Deumilanove bootloader as the board if you wish.
You'll need to then use the Duemilanove setting in the Arduino Tools->Boards menu.
I will of course reflash anyone's board who wants to send it back. Email us for a shipping label.
Here are the steps to burn a new bootloader:
You will need an ISP programmer such as an AVRISP MKII or Lady Ada's Tiny ISP to fix the problem yourself. Here are the steps to perform the fix.
1) Download Arduino 1.0 and install it. Install the FTDI drivers if not already installed - Windows users should update to latest FTDI drivers.
2) Hook up the MKII (or whatever serial programmer you are using) - Windows users may need to install a driver for the MKII
3) Power up the FHB with either a wall adapter or a USB cable
4) You should see the light on the MKII turn green if you are using that ISP
4) Set Tools -> Programmer to the programmer you are using
5) Set Tools -> Boards to UNO (default choice) -> You are also free to put the older Duemilanove bootloader on the board if you wish
6) Choose Tools -> Burn Bootloader
7) The lights on the MKII should turn orange for a bit - and the Arduino IDE should report "Done Burning Bootloader"
8) Try uploading a sketch to the FHB, pressing the reset button, removing and reinserting power (after a 15 sec pause) to make sure the board is fixed.
Paul