Doesn't autoreset after loading new sketch

I have a board that doesn't always autoreset after loading a new sketch from 0022 IDE over USB. Board design is based on Duemilanove, except I've expanded it and added a high resolution ADC, I2C temperature sensor, and SSR driver circuitry. It uses DIP ATmega328P-PU, FTDI FT232RL, and optiboot bootloader (current version from Ardunio github site).

My board is slightly different from Duemilanove in that I did not use the 3V3 signal from the FT232RL as input to the comparator for Vcc source sense. Instead, I used a voltage divider to generate 3.2V from USB-VCC (5.0V --> 5.6K --> 3.2V --> 10K --> GND). I don't think this is related to the problem, though.

The main problem is that after flashing a new sketch from USB, sometimes (not always) I need to manually press the reset button for things to restart. Until I hit the reset it just sits there not running anything.

The board does correctly autoreset to allow flashing a new sketch, when opening an IDE serial monitor window or when otherwise resetting the connected PC's virtual serial port. It also correctly starts up on its own from external power.

The only other oddity is that when the USB cable (already plugged into computer) first gets plugged into the board, the board "stutters" a few times. By that I mean that it starts the first half-second or so of the application and then resets. It does this three or four times but then always launches the application correctly after the stutters are done.

I would appreciate some tips on where to begin looking for the solution to both the no-reset on load problem and the stuttering problem? I suspect they are related.

Jim

Board design is based on Duemilanove,

That doesn't actually say much because you can't tell what bits you have changed.

Anyway it sounds like a reset problem. Put a diode across the reset's pull up resistor, cathode to +5V and anode to the reset pin.
You can also try doubling the 0.1uF capacitor coupling the DSR and the reset line, with either an another capacitor or put another 0.1uF in parallel with it.
That should sort it out.

SeeedStudios boards normally have a switch to deactivate the auto-reset. Do you have one of these?

Grumpy_Mike:
That doesn't actually say much because you can't tell what bits you have changed.

Changed from Duemilanove design:

• input to the power source select comparator changed from the 3V3 pin on the FTDI chip to a voltage divider on USB-VCC
• MCP3424 ADC added (I2C device)
• MCP9800 added (I2C device)
• 64Kb EEPROM added (I2C device)
• open collector (2N3904) outputs tied to pins D8 and D9 to drive external SSRs
• optiboot bootloader

Grumpy_Mike:
Anyway it sounds like a reset problem. Put a diode across the reset's pull up resistor, cathode to +5V and anode to the reset pin.
You can also try doubling the 0.1uF capacitor coupling the DSR and the reset line, with either an another capacitor or put another 0.1uF in parallel with it.
That should sort it out.

Thanks. I'll give that a try.

Jim

bubulindo:
SeeedStudios boards normally have a switch to deactivate the auto-reset. Do you have one of these?

No, it doesn't have a switch like this (at least not on purpose)

Jim

Hmmm. The problem seems to be associated with a particular ATmega328P chip. I replaced it with a new ATmega328P chip, burned a bootloader in the new chip using the ICSP header, and then loaded an application across USB using the IDE. The problem went away. When I put the original chip back in the socket, the problem is back.

Using avrdude, I've checked the fuses (efuse = 0x05, lfuse=0xff, hfuse=0xde) and lock byte (=0x0f) on the "bad" chip, and they all look OK. I've re-burned the optiboot bootloader a few times, too, on the bad chip.

Guess the smart thing is to toss the chip and move on. But it would be nice to know where I went wrong in setting this chip up initially with avrdude.

Jim

I didn't think that there was any "autoreset" at the end of sketch upload. Rather, there is a command sent to "end upload", which is supposed to start the sketch. The exact method of "start the sketch" is somewhat dependent on which bootloader you have on the chip. For most but not all bootloaders, it was done by enabling the watchdog timer and letting the watchdog reset the chip, but there have been assorted bugs that caused odd behavior. For example: Google Code Archive - Long-term storage for Google Code Project Hosting.

westfw:
I didn't think that there was any "autoreset" at the end of sketch upload. Rather, there is a command sent to "end upload", which is supposed to start the sketch. The exact method of "start the sketch" is somewhat dependent on which bootloader you have on the chip. For most but not all bootloaders, it was done by enabling the watchdog timer and letting the watchdog reset the chip, but there have been assorted bugs that caused odd behavior. For example: Google Code Archive - Long-term storage for Google Code Project Hosting.

That's helpful to know. I'll take a look at that issue. Thanks.

I am using the same bootloader on the working and non-working chips: optiboot_atmega328.hex, Oct. 10, 2011, from the arduino github repository. I believe it is the latest released version?

The only difference between the working and non-working chips are that the non-working chip was the victim of several of my early experiments with setting a chip up directly from the command line using avrdude. It has had a few bootloaders installed and then overwritten. The working chip, however, had optiboot burned only once, and that was from the 0022 IDE using ArduinoISP.

Eventually, I also burned optiboot into the non-working chip from the IDE using ArduinoISP. But it still does not start up on its own after the end of an upload, despite the fact that I believe all the fuses and lock bits are set the same, and it has the same optiboot bootloader installed.

Jim

You could try running the "fusebytes" sketch on working and non-working Arduinos.
That should dump the fuses/etc in human-readable form.

Output from fusebytes is nearly identical from both the good chip and bad chip. Only oddities are that the bootloader information was unreadable from both chips (although the good chip runs fine). And, this is weird, the next sketch loaded on the bad chip after fusebytes.pde self-starts just fine. But then it reverts to its bad behavior, i.e. new sketches do not self-start, on subsequent newly loaded sketches.

Jim

Fusebytes output from bad chip:

Compiled for ATmega328P
No Serial Number

Fuse bits (L/H/E): FF DE FD
Lock bits:         CF
Signature:         1E 95 F (ATmega328P)
Oscal:             A9

Fuse Low = 11111111 (FF)
           ||||++++______Low Power Crystal 8 - 16MHz
           ||++__________Start Up Time=11
           |+____________Clock Output Disabled
           +_____________(no divide)

Fuse High = 11011110 (DE)
            |||||||+______Reset to Bootstrap
            |||||++_______256 words (512 bytes)
            ||||+_________EEPROM Erased on chip erase
            |||+__________Watchdog programmable
            ||+___________ISP programming enabled
            |+____________DebugWire off
            +_____________RST enabled

Fuse Extended = 11111101 (FD)
                |||||+++______Brownout at 2.7V

Lock Bits = 11001111 (CF)
            ||||||++______Read/Write to everywhere
            ||||++________R/W Application
            ||++__________No Write to Boot, no read from App

Bootloader at 0x7E00 is not readable

Fusebytes output from good chip:

Compiled for ATmega328P
No Serial Number

Fuse bits (L/H/E): FF DE FD
Lock bits:         CF
Signature:         1E 95 F (ATmega328P)
Oscal:             9E

Fuse Low = 11111111 (FF)
           ||||++++______Low Power Crystal 8 - 16MHz
           ||++__________Start Up Time=11
           |+____________Clock Output Disabled
           +_____________(no divide)

Fuse High = 11011110 (DE)
            |||||||+______Reset to Bootstrap
            |||||++_______256 words (512 bytes)
            ||||+_________EEPROM Erased on chip erase
            |||+__________Watchdog programmable
            ||+___________ISP programming enabled
            |+____________DebugWire off
            +_____________RST enabled

Fuse Extended = 11111101 (FD)
                |||||+++______Brownout at 2.7V

Lock Bits = 11001111 (CF)
            ||||||++______Read/Write to everywhere
            ||||++________R/W Application
            ||++__________No Write to Boot, no read from App

Bootloader at 0x7E00 is not readable

Jim

An update, and maybe some new light shed on the problem.

Yesterday I ran into this problem again (processor is latched after loading a new sketch so nothing runs) on another instance of the same board design using another DIP ATmega328P-PU. Since the I thought the likelihood of two bad ATmega's in a sample size of ~25 was really unlikely, I had to re-examine my original conclusion that a bad chip was the cause of the original problem.

So I put the original "bad" chip described previously in this thread (I had marked and kept the chip) into one of my boards. Sure enough, the problem was still there. The problem traveled with the chip. Things locked up after each and every time a new sketch was loaded over USB. Pressing reset or cycling the power would restore it to correct operation with the newly loaded sketch.

So I went back to some earlier good advice in this thread, which was also given in the linked thread, and soldered a 1N4148 diode between +5V and RESET. Without making any changes to the bootloader on the "bad" chip or anything else, the latch-up problem was solved by the addition of a diode.

This particular board design has 4K7 pullups on the SDA and SCL pins, so it matches the conditions that were first reported to cause problems on the UNO R2 design. Those initial R2 problems seemed to be related to power up resets and pulldowns on the 8U2 DTR signal. But as others discovered, the basic flaw has always been there, prior to even the Uno. I guess I was unlucky enough to rediscover it.

The new light on the problem is that this is only a problem with a small number of ATmega328P-PU chips, but not with all of them. I've built and tested a couple dozen of these boards and have now experienced the problem on only two. It does not seem to be related to the characteristics of the capacitors and resistors on the boards because different chips behave differently on the exact same board when the ATmega chips are swapped.

Jim

Because once I was able to fix this problem by installing the Duemilanove bootloader instead of optiboot, I ran through a sequence of tests to see if the fuses somehow were becoming corrupted. This time, the problem again went away using the Duemilanove bootloader (without the diode). But unlike my previous experience, when optiboot was restored to the chip, the problem came back. I had to put the diode back for the board to work with optiboot.

What I conclude from this is that if I use optiboot, I need a signal diode to clamp the voltage on the RESET pin. But the diode is not required with the Duemilanove bootloader.

Output from fusebytes under various scenarios follow, just for the record.

Optiboot, no diode, latchup problem exists.

Compiled for ATmega328P
No Serial Number

Fuse bits (L/H/E): FF DE FD
Lock bits:         CF
Signature:         1E 95 F (ATmega328P)
Oscal:             A9

Fuse Low = 11111111 (FF)
           ||||++++______Low Power Crystal 8 - 16MHz
           ||++__________Start Up Time=11
           |+____________Clock Output Disabled
           +_____________(no divide)

Fuse High = 11011110 (DE)
            |||||||+______Reset to Bootstrap
            |||||++_______256 words (512 bytes)
            ||||+_________EEPROM Erased on chip erase
            |||+__________Watchdog programmable
            ||+___________ISP programming enabled
            |+____________DebugWire off
            +_____________RST enabled

Fuse Extended = 11111101 (FD)
                |||||+++______Brownout at 2.7V

Lock Bits = 11001111 (CF)
            ||||||++______Read/Write to everywhere
            ||||++________R/W Application
            ||++__________No Write to Boot, no read from App

Bootloader at 0x7E00 is not readable

Reinstall diode, problem is gone, no changes in fuses:

Compiled for ATmega328P
No Serial Number

Fuse bits (L/H/E): FF DE FD
Lock bits:         CF
Signature:         1E 95 F (ATmega328P)
Oscal:             A9

Fuse Low = 11111111 (FF)
           ||||++++______Low Power Crystal 8 - 16MHz
           ||++__________Start Up Time=11
           |+____________Clock Output Disabled
           +_____________(no divide)

Fuse High = 11011110 (DE)
            |||||||+______Reset to Bootstrap
            |||||++_______256 words (512 bytes)
            ||||+_________EEPROM Erased on chip erase
            |||+__________Watchdog programmable
            ||+___________ISP programming enabled
            |+____________DebugWire off
            +_____________RST enabled

Fuse Extended = 11111101 (FD)
                |||||+++______Brownout at 2.7V

Lock Bits = 11001111 (CF)
            ||||||++______Read/Write to everywhere
            ||||++________R/W Application
            ||++__________No Write to Boot, no read from App

Bootloader at 0x7E00 is not readable

Remove diode, overwrite bootloader with Duemilanove bootloader, problem gone:

Compiled for ATmega328P
No Serial Number

Fuse bits (L/H/E): FF DA FD
Lock bits:         CF
Signature:         1E 95 F (ATmega328P)
Oscal:             A9

Fuse Low = 11111111 (FF)
           ||||++++______Low Power Crystal 8 - 16MHz
           ||++__________Start Up Time=11
           |+____________Clock Output Disabled
           +_____________(no divide)

Fuse High = 11011010 (DA)
            |||||||+______Reset to Bootstrap
            |||||++_______1024 words (2048 bytes)
            ||||+_________EEPROM Erased on chip erase
            |||+__________Watchdog programmable
            ||+___________ISP programming enabled
            |+____________DebugWire off
            +_____________RST enabled

Fuse Extended = 11111101 (FD)
                |||||+++______Brownout at 2.7V

Lock Bits = 11001111 (CF)
            ||||||++______Read/Write to everywhere
            ||||++________R/W Application
            ||++__________No Write to Boot, no read from App

Bootloader at 0x7800 is not readable

No diode, overwrite bootloader with optiboot, problem has returned:

Compiled for ATmega328P
No Serial Number

Fuse bits (L/H/E): FF DE FD
Lock bits:         CF
Signature:         1E 95 F (ATmega328P)
Oscal:             A9

Fuse Low = 11111111 (FF)
           ||||++++______Low Power Crystal 8 - 16MHz
           ||++__________Start Up Time=11
           |+____________Clock Output Disabled
           +_____________(no divide)

Fuse High = 11011110 (DE)
            |||||||+______Reset to Bootstrap
            |||||++_______256 words (512 bytes)
            ||||+_________EEPROM Erased on chip erase
            |||+__________Watchdog programmable
            ||+___________ISP programming enabled
            |+____________DebugWire off
            +_____________RST enabled

Fuse Extended = 11111101 (FD)
                |||||+++______Brownout at 2.7V

Lock Bits = 11001111 (CF)
            ||||||++______Read/Write to everywhere
            ||||++________R/W Application
            ||++__________No Write to Boot, no read from App

Bootloader at 0x7E00 is not readable

Are any of your voltage levels marginal in this application? It is possible that you have a chip that might be more sensitive to voltage levels and this is causing some sort of hangup.

No. Vcc is almost exactly 5.00V from USB port. There are no significant loads while programming.

Jim

What I conclude from this is that if I use optiboot, I need a signal diode to clamp the voltage on the RESET pin. But the diode is not required with the Duemilanove bootloader.

As I posted in another thread, I don't own a Uno, so when the problem was first reported I tested using a 'real' arduino Duenilanove (using it's standard bootloader) and I was able to reconstruct the latch-up problem. The original poster of the problem posted a scope picture clearly showing a short +10vdc overshoot pulse on the raising edge of the auto-reset pulse. My opinion that this pulse is partially placing the chip into the HV parallel programming mode is not provable (by me anyway) but can be made repeatable and the clamping diode does cause the symptom to disappear. The documented minimum voltage to enter HV programming mode is +11.5vdc on the reset pin, but I suspect that some chips (and when there are pull-up loads on certain I/O pins) are partically entering the HV mode just due to device to device variation.

Bottom line, it's clear to me at least that any 328p circuit using a series cap coupled auto-reset feature should have the reset diode installed for best reliablity.

retrolefty:
Bottom line, it's clear to me at least that any 328p circuit using a series cap coupled auto-reset feature should have the reset diode installed for best reliablity.

Yes, I agree. I will be using the diodes on all my boards going forward.

I should have been more careful with the wording in my previous post in this thread. It would have been more accurate to say that on this particular board and with this particular chip, the latch up problem wasn't exhibited using the Duemilanove bootloader.

@retrolefty: per your suggestion on that original "diode thread" I downloaded Bray's terminal (very nice application). I saw the same behavior on my boards (optiboot bootloader) that you reported, i.e., that a reset is triggered by any change in the DTR line when no diode is installed. After installation of the diode a reset only occurred when DTR went from low to high. No reset is triggered by changing DTR from high to low once the diode is in place.

The documented minimum voltage to enter HV programming mode is +11.5vdc on the reset pin

Thats most likely the minimum voltage to reliably enter HV programming mode.
It may be possible that some chips or certain other conditions may cause it to enter HV programming mode with a lower voltage.
Bottom line is that the voltage on any pin should not exceed 5.5v for reliable behavior.

smeezekitty:

The documented minimum voltage to enter HV programming mode is +11.5vdc on the reset pin

Thats most likely the minimum voltage to reliably enter HV programming mode.
It may be possible that some chips or certain other conditions may cause it to enter HV programming mode with a lower voltage.
Bottom line is that the voltage on any pin should not exceed 5.5v for reliable behavior.

More properly the +11.5vdc is the datasheet guaranteed minimum voltage to enter the HV mode. I am convinced that +10vdc pulse on the reset pin is responsable for the latch up the chip some of the time in some situations, it is the root cause. I feel that now that it is a known failure mechanism, however seldom or randomly it might be, the fix is just too simple to ignore, either add the diode or don't use the auto-reset cap. Certainly that is why the Arduino folks added the diode in the UNO R3 board.