Arduino Mega 1280 delay() turbocharged

Thanks for the help guys!

dafid: In fact you're right. I looked at wiring.c a couple of days ago and for some reason I remembered it using delayMicroseconds(), but I just checked again and the implementation of delay() is identical in my wiring.c as what you posted above. It does indeed use micros() - my mistake!

stimmer: I'm running 64 bit Arch Linux and Arduino 0021. The IDE installation on Arch is a bit of a mess since it bundles its own patched avrdude and librxtx with it instead of using the system wide ones. Also, the installation requires removing 64 bit gcc and gcc-libs and installing 64 and 32 bit compatible versions of these packages (gcc-multilib), which is pretty hackish IMHO. In addition, the package is not available from official "repository" but it is user contributed, so it is very likely to be an installation problem. I have removed everything and reinstalled again but the results are the same.

compiler and other program versions are:

??[igor]??[X201]
??[/usr/share/arduino/hardware/arduino/cores/arduino]$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.5.2/lto-wrapper
Target: avr
Configured with: ../configure --disable-libssp --disable-nls --enable-languages=c,c++ --infodir=/usr/share/info --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr --with-gnu-as --with-gnu-ld --with-as=/usr/bin/avr-as --with-ld=/usr/bin/avr-ld
Thread model: single
gcc version 4.5.2 (GCC)
??[igor]??[X201]
??[/usr/share/arduino/hardware/arduino]$ avrdude -v

avrdude: Version 5.10, compiled on Nov 29 2010 at 11:24:36

Can you please let me know your avr-gcc compiler version?

Thanks!
-Igor

I am on Ubuntu 10.10, avr-gcc 4.3.5

$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr
Thread model: single
gcc version 4.3.5 (GCC)

I don't believe it would be caused by changing avrdude or librxtx. I wonder if it is a problem with GCC 4.5.2?

Thanks for that.
I'll try to downgrade my avr-gcc but its not a trivial matter on Arch linux (rolling release model).
-Igor

Hello all,

I would like to report that I have the same problem using the delay() function on arch 32 bit and avr-gcc 4.5.2

I have the problem on 3 different boards, the arduino nano, arduino duelmilanove 168 and the 328.

On the 168 the LED blinks very fast and on the 328 and the nano the led is just on all the time.

I've duplicated the problem on three different computers running arch. On one of them I downgraded the avr-gcc to 4.3.5 and the problem was still there.

The delay() works ok when I compile my code and upload it using Ubuntu 10.04 and avr-gcc 4.3.5.

Regards,
Aleks

I'm baffled by this one. I tried to compile GCC 4.5.2 on Ubuntu but just got too many errors. I also tried to install Arch Linux but Virtualbox was not cooperating, so gave up on that too.

Are either of you able to disassemble the object file and see what the compiler is doing to the delay function?

I wonder if the compiler is misconfigured or picking up a delay function from some other header somewhere... Does Arch set any environment variables that might interfere with GCC, like CFLAGS, CXXFLAGS, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH and LIBRARY_PATH ?

Hi stimmer,

None of those environment variables seem to be set:

??[igor]??[X201]
??[~]$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/java/bin:/opt/java/db/bin:/opt/java/jre/bin:/usr/bin/core_perl:/usr/local/bin:/usr/local/bin
??[igor]??[X201]
??[~]$ echo $CFLAGS

??[igor]??[X201]
??[~]$ echo $C_INCLUDE_PATH

??[igor]??[X201]
??[~]$ echo $C_PLUS_INCLUDE_PATH

??[igor]??[X201]
??[~]$ echo $LIBRARY_PATH

??[igor]??[X201]
??[~]$

I'll dive into the issue in more detail as soon as I get some free time. I just updated Arch linux and saw it pulled a new gcc in, so I will recompile the sketches and see if anything changes. If I can't figure anything out, I'll get in touch with the Arch linux arduino package maintainer and let him know about this issue, since it seems to be Arch specific.

Cheers,
-Igor

Could you try doing a disassembly of the delay function?

Load up the Blink sketch, then hold down shift as you click Verify, then look in the box at the bottom for the temporary directory it uses.

In a terminal, type cd /tmp/buildnnnnnnnnnnn.tmp (where buildnnnnnnnnnnnn.tmp is the temporary directory as above)

Then type avr-objdump -S Blink.cpp.elf

Then find the symbol and cut and paste it from there up to the next symbol and post it here, it should look like this:

000004c4 <delay>:

void delay(unsigned long ms)
{
 4c4:	ef 92       	push	r14
 4c6:	ff 92       	push	r15
 4c8:	0f 93       	push	r16
 4ca:	1f 93       	push	r17
 4cc:	cf 93       	push	r28
 4ce:	df 93       	push	r29
 4d0:	7b 01       	movw	r14, r22
 4d2:	8c 01       	movw	r16, r24
	uint16_t start = (uint16_t)micros();
 4d4:	0e 94 3c 02 	call	0x478	; 0x478 <micros>
 4d8:	eb 01       	movw	r28, r22
 4da:	0e c0       	rjmp	.+28     	; 0x4f8 <delay+0x34>

	while (ms > 0) {
		if (((uint16_t)micros() - start) >= 1000) {
 4dc:	0e 94 3c 02 	call	0x478	; 0x478 <micros>
 4e0:	6c 1b       	sub	r22, r28
 4e2:	7d 0b       	sbc	r23, r29
 4e4:	68 5e       	subi	r22, 0xE8	; 232
 4e6:	73 40       	sbci	r23, 0x03	; 3
 4e8:	c8 f3       	brcs	.-14     	; 0x4dc <delay+0x18>
			ms--;
 4ea:	08 94       	sec
 4ec:	e1 08       	sbc	r14, r1
 4ee:	f1 08       	sbc	r15, r1
 4f0:	01 09       	sbc	r16, r1
 4f2:	11 09       	sbc	r17, r1
			start += 1000;
 4f4:	c8 51       	subi	r28, 0x18	; 24
 4f6:	dc 4f       	sbci	r29, 0xFC	; 252

void delay(unsigned long ms)
{
	uint16_t start = (uint16_t)micros();

	while (ms > 0) {
 4f8:	e1 14       	cp	r14, r1
 4fa:	f1 04       	cpc	r15, r1
 4fc:	01 05       	cpc	r16, r1
 4fe:	11 05       	cpc	r17, r1
 500:	69 f7       	brne	.-38     	; 0x4dc <delay+0x18>
		if (((uint16_t)micros() - start) >= 1000) {
			ms--;
			start += 1000;
		}
	}
}
 502:	df 91       	pop	r29
 504:	cf 91       	pop	r28
 506:	1f 91       	pop	r17
 508:	0f 91       	pop	r16
 50a:	ff 90       	pop	r15
 50c:	ef 90       	pop	r14
 50e:	08 95       	ret

00000510 <init>:

igor86:
None of those environment variables seem to be set:

None of those variables should be set normally; the makefile sets them, and they basically are only set while make is running (i.e. during the build process).

Hi, I'm having the same problem Igor86 describes... Arduino Uno, Arch Linux 64-bit, avr-gcc version 4.5.2.

Here's my disassembly of the standard example Blink sketch as Stimmer requested

00000210 <delay>:

void delay(unsigned long ms)
{
 210:	ef 92       	push	r14
 212:	ff 92       	push	r15
 214:	0f 93       	push	r16
 216:	1f 93       	push	r17
 218:	cf 93       	push	r28
 21a:	df 93       	push	r29
 21c:	7b 01       	movw	r14, r22
 21e:	8c 01       	movw	r16, r24
	uint16_t start = (uint16_t)micros();
 220:	0e 94 e2 00 	call	0x1c4	; 0x1c4 <micros>
 224:	eb 01       	movw	r28, r22

	while (ms > 0) {
 226:	0f c0       	rjmp	.+30     	; 0x246 <delay+0x36>
		if (((uint16_t)micros() - start) >= 1000) {
 228:	0e 94 e2 00 	call	0x1c4	; 0x1c4 <micros>
 22c:	6c 1b       	sub	r22, r28
 22e:	7d 0b       	sbc	r23, r29
 230:	83 e0       	ldi	r24, 0x03	; 3
 232:	68 3e       	cpi	r22, 0xE8	; 232
 234:	78 07       	cpc	r23, r24
 236:	38 f0       	brcs	.+14     	; 0x246 <delay+0x36>
			ms--;
 238:	08 94       	sec
 23a:	e1 08       	sbc	r14, r1
 23c:	f1 08       	sbc	r15, r1
 23e:	01 09       	sbc	r16, r1
 240:	11 09       	sbc	r17, r1
			start += 1000;
 242:	c8 51       	subi	r28, 0x18	; 24
 244:	dc 4f       	sbci	r29, 0xFC	; 252

void delay(unsigned long ms)
{
	uint16_t start = (uint16_t)micros();

	while (ms > 0) {
 246:	e1 14       	cp	r14, r1
 248:	f1 04       	cpc	r15, r1
 24a:	01 05       	cpc	r16, r1
 24c:	11 05       	cpc	r17, r1
 24e:	61 f7       	brne	.-40     	; 0x228 <delay+0x18>
		if (((uint16_t)micros() - start) >= 1000) {
			ms--;
			start += 1000;
		}
	}
}
 250:	df 91       	pop	r29
 252:	cf 91       	pop	r28
 254:	1f 91       	pop	r17
 256:	0f 91       	pop	r16
 258:	ff 90       	pop	r15
 25a:	ef 90       	pop	r14
 25c:	08 95       	ret

0000025e <init>:

I notice at offset 226 above the rjmp looks like it's inside the while (ms > 0) { }

and at offsets 230-234 things are handled slightly differently, but my reading of the assembly language isn't good enough to tell me what that means :slight_smile:

Hope this is helpful as I'd really like to be programming my new Arduino Uno from my Arch system too!

Thanks to Stimmer for looking into this problem.

Hi,

Here is my dissassmebled code as requested:

000002fc <delay>:

void delay(unsigned long ms)
{
 2fc:   ef 92           push    r14
 2fe:   ff 92           push    r15
 300:   0f 93           push    r16
 302:   1f 93           push    r17
 304:   cf 93           push    r28
 306:   df 93           push    r29
 308:   7b 01           movw    r14, r22
 30a:   8c 01           movw    r16, r24
        uint16_t start = (uint16_t)micros();
 30c:   0e 94 58 01     call    0x2b0   ; 0x2b0 <micros>
 310:   eb 01           movw    r28, r22

        while (ms > 0) {
 312:   0f c0           rjmp    .+30            ; 0x332 <delay+0x36>
                if (((uint16_t)micros() - start) >= 1000) {
 314:   0e 94 58 01     call    0x2b0   ; 0x2b0 <micros>
 318:   6c 1b           sub     r22, r28
 31a:   7d 0b           sbc     r23, r29
 31c:   83 e0           ldi     r24, 0x03       ; 3
 31e:   68 3e           cpi     r22, 0xE8       ; 232
 320:   78 07           cpc     r23, r24
 322:   38 f0           brcs    .+14            ; 0x332 <delay+0x36>
                        ms--;
 324:   08 94           sec
 326:   e1 08           sbc     r14, r1
 328:   f1 08           sbc     r15, r1
 32a:   01 09           sbc     r16, r1
 32c:   11 09           sbc     r17, r1
                        start += 1000;
 32e:   c8 51           subi    r28, 0x18       ; 24
 330:   dc 4f           sbci    r29, 0xFC       ; 252

void delay(unsigned long ms)
{
        uint16_t start = (uint16_t)micros();

        while (ms > 0) {
 332:   e1 14           cp      r14, r1
 334:   f1 04           cpc     r15, r1
 336:   01 05           cpc     r16, r1
 338:   11 05           cpc     r17, r1
 33a:   61 f7           brne    .-40            ; 0x314 <delay+0x18>
                if (((uint16_t)micros() - start) >= 1000) {
                        ms--;
                        start += 1000;
                }
        }
}
 33c:   df 91           pop     r29
 33e:   cf 91           pop     r28
 340:   1f 91           pop     r17
 342:   0f 91           pop     r16
 344:   ff 90           pop     r15
 346:   ef 90           pop     r14
 348:   08 95           ret

0000034a <init>:

Thanks heaps for looking into this stimmer! Helping others like you have is certainly good karma! :wink:

Cheers,
-Igor

Well, that disassembly looks correct, it's slightly different to mine but not significantly.

Could you disassemble it again and post the entire disassembly? I am wondering if something is clobbering r1 (which should usually be zero) or if an ISR is clobbering something else, the only way to find out is to look through the whole lot :cold_sweat:

OK... I finally managed to install Arch linux on Virtualbox and I think I'm getting to the bottom of this. It appears that the Arch compiler sometimes generates code that writes to addresses before the start of memory. RAM starts at address 0x200 on the mega, but the Blink code has the delay() timer variables located at 0x100-0x10b. This only seems to happen when the code contains no initialised global variables (.data segment in asm-speak) - the linker is told that the data segment starts at 0x200, but if there's nothing to go in it it generates an incorrect start address for the uninitialised global variables (.bss segment). Since the timer variables are uninitialised globals (or globals initialised to zero) they end up at an illegal address.

Here's my blink code that worked, with an initialised global. Could you test this and tell me if it is at the correct speed?

char dummyvariablecuzmaintainerborkedthecompiler = 123; // force something into the .data segment with non-zero initializer
/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.
 
  This example code is in the public domain.
 */

void setup() {  
  dummyvariablecuzmaintainerborkedthecompiler++;  // stops the linker from removing the global variable
  
  // initialize the digital pin as an output.
  // Pin 13 has an LED connected on most Arduino boards:
  pinMode(13, OUTPUT);     
}

void loop() {
  digitalWrite(13, HIGH);   // set the LED on
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // set the LED off
  delay(1000);              // wait for a second
}

Any code that uses the Serial class won't be affected by this, as Serial contains an initialised global.

Wow, well the Blink sketch with global var inserted functions correctly for me! Compiles and uploads fine and the led blinks on and off at the correct rate on the Uno.

Will be interesting to know how this tests out for Igor's Mega 1280 as well as Uno board and Aleks' various boards on 32 bit Arch...

As an arduino newbie I'm not sure where to go next with this but it seems it is an Arch specific problem?

char dummyvariablecuzmaintainerborkedthecompiler = 123;

LOL

Seriously the Arch maintainers are doing a great job, from what I can tell there's still issues with the Arduino IDE distribution containing 32bit rxtx but there is rxtx replacement in AUR (Arch User Repos)

But this problem sounds like it will be with gcc-avr, gcc-binutils or something?

I strongly agree with Igor's statement that:

Open source hardware should have a good IDE implementation for open source software, no?

and the kind of help Stimmer, Dafid et al are providing on this forum will no doubt be invaluable for getting Arduino stable on Arch's rolling releases insofar as that's possible ]:slight_smile:

I'm following with interest and I guess this will filter over to the Arch forums or bug reports as it develops...?

Yes, it sounds like an Arch specific problem at the moment. Maintaining a cross compiler is probably one of the harder jobs, they are a pain to compile and bug reports are hard to replicate.

A potential solution has been posted in another thread by dsh1. This involves downgrading to GCC 4.3.5 and applying Debian patches:

Can people try this and see if it works?

stimmer:
Yes, it sounds like an Arch specific problem at the moment. Maintaining a cross compiler is probably one of the harder jobs, they are a pain to compile and bug reports are hard to replicate.

A potential solution has been posted in another thread by dsh1. This involves downgrading to GCC 4.3.5 and applying Debian patches:

Incrementation bug? WTF? [BROKEN COMPILER - SOLVED] - #21 by system - Programming Questions - Arduino Forum

Can people try this and see if it works?

I just thought I would mention that I'm having this problem with Gentoo as well. I'm using:

$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: /var/tmp/portage/cross-avr/gcc-4.3.3-r2/work/gcc-4.3.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/avr/gcc-bin/4.3.3 --includedir=/usr/lib/gcc/avr/4.3.3/include --datadir=/usr/share/gcc-data/avr/4.3.3 --mandir=/usr/share/gcc-data/avr/4.3.3/man --infodir=/usr/share/gcc-data/avr/4.3.3/info --with-gxx-include-dir=/usr/lib/gcc/avr/4.3.3/include/g++-v4 --host=i686-pc-linux-gnu --target=avr --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-libmudflap --disable-libssp --enable-cld --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --disable-threads --disable-bootstrap --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.3-r2 p1.2, pie-10.1.5'
Thread model: single
gcc version 4.3.3 (Gentoo 4.3.3-r2 p1.2, pie-10.1.5)

I've been discussing this in #arduino, and we're working around this issue so far like this: (with a 0022 ide)

$ diff -u5 hardware/arduino/cores/arduino/wiring.{c_orig,c}
--- hardware/arduino/cores/arduino/wiring.c_orig	2011-02-05 18:17:40.058000066 -0600
+++ hardware/arduino/cores/arduino/wiring.c	2011-02-05 18:19:32.907000066 -0600
@@ -21,10 +21,11 @@
 
   $Id$
 */
 
 #include "wiring_private.h"
+#include <avr/delay.h>
 
 // the prescaler is set so that timer0 ticks every 64 clock cycles, and the
 // the overflow handler is called every 256 ticks.
 #define MICROSECONDS_PER_TIMER0_OVERFLOW (clockCyclesToMicroseconds(64 * 256))
 
@@ -102,18 +103,21 @@
 	return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond());
 }
 
 void delay(unsigned long ms)
 {
+/*	
 	uint16_t start = (uint16_t)micros();
 
 	while (ms > 0) {
 		if (((uint16_t)micros() - start) >= 1000) {
 			ms--;
 			start += 1000;
 		}
 	}
+*/
+	_delay_ms(ms);
 }
 
 /* Delay for the given number of microseconds.  Assumes a 8 or 16 MHz clock. */
 void delayMicroseconds(unsigned int us)
 {

I have also found that using the 0018 IDE, the delay() works properly.

I'll have a look at the Debian patches you listed, and report back when I know more.

On further investigation, it seems that using binutils-2.20.1-r1 instead of binutils-2.21 solves this for me on Gentoo.

I have this issue with the Uno and Fedora14 i686. The software is avr-gcc-4.5.1 and avr-binutils 2.21.

Same here with Fedora 14. (using a Duemilanove)

avr-gcc -v result.

Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.5.1/lto-wrapper
Target: avr
Configured with: ../gcc-4.5.1/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-system-zlib --enable-version-specific-runtime-libs --with-pkgversion='Fedora 4.5.1-2.fc14.1' --with-bugurl=https://bugzilla.redhat.com/
Thread model: single
gcc version 4.5.1 (Fedora 4.5.1-2.fc14.1)

Hadn't used it for a while on my Fedora box. Works fine so far on Mint though, so not completely duinoless.
I also get an error when uploading

"avrdude: stk500_recv(): programmer is not responding"

But none with the blink without delay sketch.

Using avrdude 5.10

Ditto for Fedora 14, with Arduino Duemilanove.
See topic
http://arduino.cc/forum/index.php/topic,68512.0.html

However the 'blink' example that comes with the arduino v22 software, initializes a LEDPin global variable and that, as has been said fixes the problem.

I am a newbe to using the arduino, and the fact that it fails like this with a very basic example has been a worry for me. Any idea when the real problem will be fixed?