Program never loads, LED blinks until invalid serial activity kick-starts sketch

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Upload a program normally using Optiboot at 19kbps
2. Run it (it runs)
3. Unplug it
4. Plug it in
5. It may run, or it may hang with the blinking LED (blinkblink... 
blinkblink... blinkblink... blinkblink... infinitely) and require 
unplug/replug, unplug/replug, unplug/replug, and when it finally DOES work, 
it'll start the sketch immediately without blinking the LED.

What is the expected output? What do you see instead?
It should work reliably every time, without needing to ground the serial pin 1 
(which seems to be a reliable fix while it's looping) or any other voodoo 
magic. It should not be resetting the device on invalid serial data, but simply 
loading the program if it detects invalid data. We can always auto-reset if 
need be.

What version of the product are you using? On what operating system?
Can't tell, no version information is stored in the Optiboot folders under 
"hardware". Really, guys? Well, I just installed it on all my 328p's almost a 
month ago (5/8), so it can't be that old. Using Arduino 0022 with Win7 x64 for 
what it's worth.

Please provide any additional information below.
Sitting here with the USB plugged in right now after uploading a program and 
hitting "reset" (program isn't behaving as written), and after I've written up 
this WHOLE post, it's still flashing the LED at me... blinkblink... 
blinkblink... blinkblink. This happens repeatedly on my Duemilanove (which is 
on my lap), as well as on my USB BoArduino v2.0. ANY time I don't have serial 
tied to ground or being monitored in the Arduino serial console, it 
unpredictably starts doing this loop thing. I've been dealing with this issue 
ever since I loaded OptiBoot onto my 328p's, and never before. I'd go back to 
stock if I could endure that painfully slow upload speed after using Optiboot ;)

Original issue reported on code.google.com by falc...@gmail.com on 1 Jun 2011 at 7:06

• Merged into: #26

[GoogleCodeExporter]

And all I had to do in order to stop the blinking and start the sketch was 
bring a wire near the "Ground" pin on the Arduino board... this is ABSOLUTELY a 
RF interference issue, which really should not even close to be an issue on 
something as critical as a bootloader. I don't know how this issue got 
overlooked for as big an issue as it's been for me, but it really should 
identify bad input data, discard it, and fail over to running the program (not 
rebooting back to the loader). It's such a PITA to get it out of that loop 
sometimes... on the BoArduino it's easier since I tie ground to the bredboard 
unit's ground bus, but with my Duemilanove I'd much rather just make sure it 
starts the dang program! =/

Original comment by falc...@gmail.com on 1 Jun 2011 at 7:10

[GoogleCodeExporter]

Probably a duplicate of http://code.google.com/p/optiboot/issues/detail?id=26
If so, it's already fixed in the Arduino source base: 
http://code.google.com/p/arduino/issues/detail?id=446&can=1&q=optiboot  (but I 
don't think there has been a release since then.)

Original comment by wes...@gmail.com on 15 Jun 2011 at 12:00

[GoogleCodeExporter]

I don't think it's the same... I never used any programs that set R1 and go 
into an infinite loop; unless of course R1 can be modified as part of the 
routine compiled code. I just had a typical setup() and loop() operation, no 
need for any seriously low-level ASM code. It seemed to be behaving like a 
serial (DTR) reset every time it looped, instead of realizing it was a watchdog 
reset and immediately jumping to the program. I also noticed a *lot* of strange 
program behavior caused by non-zeroed memory areas, and in my modification I 
made these tweaks around line 233:

//#ifdef __AVR_ATmega8__
  SP=RAMEND;  // This is done by hardware reset (// edit: apparently not!)
//#endif

  asm volatile ("clr __zero_reg__");

... Now, I'm not 100% sure as to what "SP=RAMEND" is supposed to indicate - I'm 
guessing "SP" = "stack pointer", and "RAMEND" is self-explanatory, but I don't 
know how the two go together. But I do believe __zero_reg__ translates to R0 
(R1?) that's used by the compiler as a shortcut to load something to the number 
"zero", and by the random values I tend to find in uninitialized variables, I'm 
guessing the CPU needs that instruction anyway. It's just 1 byte, I don't see 
why it was commented out...

Anyway, after those two lines were added back, the thing works great. The FTDI 
driver tends to send a long string of resets to the board when I first plug it 
into USB, but at least it doesn't go into "seizure mode" with endless resets 
anymore.

I'm pretty sure it was some kind of environmental condition issue, like 
electrical noise causing a serial pick-up and waiting for the watchdog to time 
it out each time. If I power-cycled the board while it was doing that 
reboot-loop, it would eventually start running the program properly, no need to 
re-upload or anything. If I even opened a serial console and sent a single 
byte, it would start running too... so I dunno. Hard to believe it could be a 
problem with each of my boards, but considering the lack of "me-too" on this 
issue, I dunno what to think... :/

Original comment by falc...@gmail.com on 15 Jun 2011 at 12:14

[GoogleCodeExporter]

Well if your looking for a "me-too" you can count me in :( I'm having the same 
problem with a new Arduino UNO which i got about 2 weeks ago. At first i 
thought something was wrong with my attached shields/other hardware or sketch 
but that was not the case. I ended up uploading the 'blink' sketch on the bare 
Arduino and it still sits there resetting over and over and never starting the 
sketch. Playing with the RX line indeed helps and also opening a serial console 
and sending some data (more then one byte/char in my case) will start running 
my program. I also noticed issue 40 but i also don't think its the same since i 
can reproduce the problem with only the 'blink' sketch.
Problem occurs also without usb cable attached (using a power supply and the 
bare arduino only).

I updated the optiboot a week ago because of issue 23 (problem loading sketches 
>30k, mine was larger). But now i'm stuck with this problem.

I hope your fix works for me too. 

regards

Original comment by tom.van....@gmail.com on 15 Jun 2011 at 6:26

[GoogleCodeExporter]

With issue 40 in my last comment i did ofcourse did mean issue 26... 

Original comment by tom.van....@gmail.com on 15 Jun 2011 at 6:30

[GoogleCodeExporter]

Well, I guess it'd help to post my bootloader... it's used in all my ATmega328p 
chips (Duemilanove, BoArduino, S3V3 - don't own an Uno yet but I hope to 
soon!), and should work with any Arduino board using the standard flags... it's 
posted here: http://hostfile.org/optiboot.rar

Standard disclaimer of course: use at your own risk, not responsible for your 
computer exploding, etc etc. Of course if you already upgraded your bootloader 
with Optiboot I'm sure you're familiar with the ArduinoISP process (or if 
you're lucky enough to own a proper programmer, even better!). The general flow 
is:
- set the lock bits to unlock the programming area; this also sets the program 
load-point to the bootloader, so the next upload you do will overwrite the 
bootloader instead of the program area. This is "0x3F".
- program the memory with the bootloader. it's sent just like a program, but 
this time it overwrites the boot area.
- set the lock bits to protect the bootloader, so the next time something is 
uploaded, it sends it to program memory instead of clobbering the bootloader. 
This is "0x0F".
The avrdude command line to string each of these together in sequence is:
"avrdude -p atmega328p -b 19200 -c stk500v1 -P \\.\COM2 -U lock:w:0x3f:m -U 
flash:w:optiboot_atmega328.hex:i -U lock:w:0x0f:m"
(replace COM2, 19200, and stk500v1 as necessary)

Let me know how it works... maybe this will lead to a fix :)

Original comment by falc...@gmail.com on 15 Jun 2011 at 6:45

[GoogleCodeExporter]

Problem Solved! Thanks for posting your updated Optiboot! I uploaded it and the 
problem disappeared :)
I checked the source in your posted file and its a different one then I used 
since last week:
http://code.google.com/p/optiboot/source/detail?r=5fb1de3b71af6c531ebca71abec622
192c3c9b83
Yours has some other options turned of and/or on and also includes the clearing 
of r1 (issue 26) so it is possible that those changes did the trick for me and 
not the SP=RAMEND; line you uncommented. However I do appreciate it very much:)

I also forgot to mention in my first post: I ran the atmel chip from the 
arduino on a breadboard with just a powersupply/crystal and the led to pin 13. 
In this case the reset problem did not occur at all, it started my program 
every time on powerup or reset. Putting the chip back in the arduino and the 
problem reoccurred.... 

Thanks again for the help!

Original comment by tom.van....@gmail.com on 15 Jun 2011 at 8:33

[GoogleCodeExporter]

I'm going to assume that this is a duplicate of the R1 problem already fixed in 
the Arduino copy of the codebase (and now in the v4_4 download.)  It would be 
great if the original submitters could try v4.4 to see if the problem is 
actually fixed.

Original comment by wes...@gmail.com on 29 Oct 2011 at 5:39

• Changed state: Duplicate