Go Down

Topic: Doesn't autoreset after loading new sketch (Read 1 time) previous topic - next topic

JimG

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
TC4 Open Source Digital Thermometer and Temperature Controller
http://code.google.com/p/tc4-shield

Grumpy_Mike

Quote
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?
Eu não sou o teu criado. Se respondo no fórum é para ajudar todos mediante a minha disponibilidade e disposição. Responder por mensagem pessoal iria contra o propósito do fórum e por isso evito-o.
Se realmente pretendes que eu te ajude por mensagem pessoal, então podemos chegar a um acordo e contrato onde me pagas pela ajuda que eu fornecer e poderás então definir os termos de confidencialidade do meu serviço. De forma contrária toda e qualquer ajuda que eu der tem de ser visível a todos os participantes do fórum (será boa ideia, veres o significado da palavra fórum).
Nota também que eu não me responsabilizo por parvoíces escritas neste espaço pelo que se vais seguir algo dito por mim, entende que o farás por tua conta e risco.

Dito isto, mensagens pessoais só se forem pessoais, ou seja, se já interagimos de alguma forma no passado ou se me pretendes convidar para uma churrascada com cerveja (paga por ti, obviamente).

JimG


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




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
TC4 Open Source Digital Thermometer and Temperature Controller
http://code.google.com/p/tc4-shield

JimG


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
TC4 Open Source Digital Thermometer and Temperature Controller
http://code.google.com/p/tc4-shield

JimG

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
TC4 Open Source Digital Thermometer and Temperature Controller
http://code.google.com/p/tc4-shield

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: http://code.google.com/p/arduino/issues/detail?id=446&can=1&q=r1

JimG


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: http://code.google.com/p/arduino/issues/detail?id=446&can=1&q=r1

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
TC4 Open Source Digital Thermometer and Temperature Controller
http://code.google.com/p/tc4-shield

westfw

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

JimG

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:
Code: [Select]
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:
Code: [Select]
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
TC4 Open Source Digital Thermometer and Temperature Controller
http://code.google.com/p/tc4-shield

JimG

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

TC4 Open Source Digital Thermometer and Temperature Controller
http://code.google.com/p/tc4-shield

JimG

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.
Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
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



TC4 Open Source Digital Thermometer and Temperature Controller
http://code.google.com/p/tc4-shield

kf2qd

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.

JimG

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

Jim
TC4 Open Source Digital Thermometer and Temperature Controller
http://code.google.com/p/tc4-shield

retrolefty

Quote
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.

Go Up