@vesal: Found another strange thing (original code): can you confirm this?

When I press the reset when the LED is [glow]on[/glow] the strange behavior appears.When I press the reset when the LED is [glow]off[/glow] it acts normal...tested 10+ times (not scientifically but still)

When I press the reset when the LED is on the strange behavior appears.When I press the reset when the LED is off it acts normal.

I think I get the behavior in both cases. You can changes the 500000Lto something longer to get more time in each case. F.ex to 2500000L.Then you must also change the n1000 %= 5000000L; to get 5 sec round trip.

But I do not see reason why it behaves differently in different state.

void loop() { n1000 = ldiv(m++,1000000L); // This hangs Arduino while pressing reset} By "hang" you mean that it goes into some sort of bootloader loop where you get the initial flashes, repeating approximately every second, but the sketch itself never seems to start?

I can get this to happen with an m168 containing optiboot, using 0022 from a Mac. Not every time, though.

This is really strange. It's not really hung, or it wouldn't be running the bootloader enough to flash the LEDs. Or to recover on a new upload. The ldiv function really doesn't do anything suspicious that I can see...

void loop() { n1000++; n1000 %= 1000; // This hangs Arduino while pressing reset}This is a simpler sketch, based on the code actually produced. A signed divide does sign correction and calls the unsigned divide, and the use of ldiv_t results in some substantial structure-passing code...

ah hah! This had all the signs of a watchdog problem, except that those are supposed to be all fixed on Uno. And looking at the code, it does look like they should indeed be fixed.

Except...

The C compiler uses register 1 (R1) as a "known zero" in most places. Functions that use it for something else are supposed to save and restore it, so any particular C function, like main(), knows it can assume that R1 contains a zero. R1 is initialized in the startup code that happens before main() happens (which is before setup() or loop() as well.)

The optiboot bootloader suppresses the normal startup code. R1 does not get set to zero.

The first thing done in the bootloader is to reset the watchdog timer "MCUSR = 0;", which compiles to "out 0x34, R1" - it assumes that R1 contains a zero!

RESET does not set register contents to zero.

If a reset occurs while R1 contains certain values, (bit 1 set), the bootloader will not restart the sketch.

I can't say how happy I am that you found it! I (probably) never would have figured out that r1 is zeroed out on power-up but not by a hardware reset. (I feel that it must be documented somewhere, but I haven't seen any Atmel AVR chip references other than doc8271.)

// After the zero init loop, this is the first code to run. // // This code makes the following assumptions: // No interrupts will execute // SP points to RAMEND // r1 contains zero // // If not, uncomment the following instructions: // cli();

#ifdef __AVR_ATmega8__ SP=RAMEND; // This is done by hardware reset#endif

// asm volatile ("clr __zero_reg__");

I uncommented the cli() line and the asm line. Since cli() is defined in the avr interrupt.h header, I added the following right after the #include <avr/pgmspace.h> line: