dritcey / optiboot

Automatically exported from code.google.com/p/optiboot
0 stars 0 forks source link

Need to set R1 to zero in main() #26

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Load a main program that sets R1 to 2 and goes into infinite loop.
2. Attempt to reset the chip using RESET signal/button.
3.

What is the expected output? What do you see instead?
It is expected that the the chip will reset and run the program again, 
effectively appearing to do nothing.  Instead, it gets stuck in a bootloader 
loop where the LEDs flash, the watchdog times out, etc, over and over.

What version of the product are you using? On what operating system?
This occurs in the latest source tree, as well as the version distributed with 
arduino.

Please provide any additional information below.
This can happen in any program that happens to have R1 with bit 1 set, if the 
reset occurs at that time.  It was originally noticed in a simple sketch using 
modulo (divide clib functions use R1 as a loop counter.)

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1293529218/39#39

Arduino Uno sketch attached.

Original issue reported on code.google.com by wes...@gmail.com on 3 Jan 2011 at 8:13

GoogleCodeExporter commented 8 years ago
sketch...

Original comment by wes...@gmail.com on 3 Jan 2011 at 8:14

Attachments:

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Downloaded source with "hg clone https://optiboot.googlecode.com/hg/ optiboot"

Made the following changes in the main() function of optiboot.c

Uncommented the following lines:

  cli();

and

  asm volatile ("clr __zero_reg__");

In order to have "cli()" defined, added the following after the #include 
<avr/pgmspace.h>

#include <avr/interrupt.h>

The resulting file was too large when I compiled with avr-gcc version 4.3.4, so 
I modified the LDFLAGS line in the Makefile to:

override LDFLAGS       = -Wl,$(LDSECTION) -Wl,--relax -nostartfiles 
-Wl,--gc-sections

Now the size is 0x7FFC bytes (508 decimal)

Tested on UNO and also on FTDI-interface '328 boards on Centos Linux 5.5 and 
Windows XP workstations.  None of the "UNO Breaker" sketches in the forum 
thread linked by westfw give problems.

---davekw7x

Original comment by dave.eva...@gmail.com on 7 Jan 2011 at 7:20

GoogleCodeExporter commented 8 years ago
Is the cli() needed?  I was pretty sure that all forms of reset correctly 
disable interrupts...

Original comment by wes...@gmail.com on 16 Jan 2011 at 12:26

GoogleCodeExporter commented 8 years ago
It looks like R1 can be non-zero after power-on reset as well
http://www.adafruit.com/forums/viewtopic.php?f=25&t=19126&start=0

Original comment by wes...@gmail.com on 17 Jan 2011 at 11:20

GoogleCodeExporter commented 8 years ago
Potential patch attached.  In light of the problems with power-up in more 
recent arduinos, the comment may not be entirely accurate.

Original comment by wes...@gmail.com on 17 Jan 2011 at 11:22

Attachments:

GoogleCodeExporter commented 8 years ago
Has this fix been implemented in the latest .zip download?  I noticed this same 
issue on my custom 'duino clone and had to go back to ADABOOT.

Original comment by jeremy.v...@testcontrols.com on 10 Feb 2011 at 10:32

GoogleCodeExporter commented 8 years ago
This fix (enabling asm volatile ("clr __zero_reg__"); and cli(); ) and the make 
file updates works only for atmega328p MCUs. But not for the atmega328 
(ATMEGA328-PU Chip).

Bootloader flashed in to MCU correctly, but the Sketches would not be uploaded 
from Arduino.

I recieve a protocol error. 

Not sure if this chip is different from the atmega328p chips. I did change the 
chip signature in avrdude.conf file. But that that did not work.

Note: The same works fine with the standard arduino boot loader or ADABOOT 
versions.

Original comment by oa.r...@gmail.com on 27 Apr 2011 at 8:11

GoogleCodeExporter commented 8 years ago
It doesn't make sense that the patch would fail on 328 but work on 328p.  Are 
you using the exact same source and tool chain, and have you tried with and 
without the patch?  (and which source base are you using?  Hg, zip, or Arduino 
dist?)

Original comment by wes...@gmail.com on 29 Apr 2011 at 11:26

GoogleCodeExporter commented 8 years ago
I think the issue (as reported in comment #8) is now resolved for me. Works for 
both 328 and 328p chips. 

I think the problem may be with AVR compiler/tool chain. Uninstalled the latest 
WinAVR and reinstalled with the older version of WinAVR(03122009). And it 
worked fine. 

I did see a considerable delta in HEX file size with both the compilers.

Occationally, I do get protocol error while uploading sketch from Arduino IDE, 
but that gets resolved if i plug/unplug the USB and retrying.

Original comment by oa.r...@gmail.com on 3 May 2011 at 9:23

GoogleCodeExporter commented 8 years ago

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

GoogleCodeExporter commented 8 years ago
Issue 40 has been merged into this issue.

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

GoogleCodeExporter commented 8 years ago
Fixed as part of the great optiboot/Arduino sync-up
http://code.google.com/p/optiboot/source/detail?r=8559b64fd093d3976cae58778a1540
256cde5c8e

Original comment by wes...@gmail.com on 30 Oct 2011 at 8:19