Go Down

Topic: Microcontroller halts and sketch stops working  (Read 205 times) previous topic - next topic


Jul 12, 2018, 10:04 pm Last Edit: Jul 13, 2018, 07:40 am by khaledeeebuet
Hello guys,

I'm facing a strange issue with my SMD atmega328p loaded with a Nano bootloader (barebone arduino nano). 

Code stops working after a minute (or less) of powering up the microcontroller. After the microcontroller halts, connecting reset pin to GND does nothing. I cannot even upload a new sketch using my FT232RL at this stage. Everything becomes normal after a power cycle of the microcontroller (disconnect 5V supply and reconnect). Then i can reset the microcontroller and upload a new sketch. But it halts again within a minute.

Any sketch i upload works perfectly fine until the microcontroller halts. This problem occurs for every sketch i upload  (even the example blink sketch). But increasing delay() in a sketch seems to make the microcontrollers halt faster.

I've also noticed that the time my microntroller runs before halting, which is constant for a particular sketch,  begins when i power it up, not when i reset it after powering up.   

To solve this issue i've

- checked the voltage level. it's clean 5V
- put a cap just beside the microcontroller between 5V and GND
- placed the 16MHz crystal and 22pf caps very close to the microcontrooler
- put pull up resistor on the reset pin
- checked the fuse bits of atmega328 with avrdude & usbasp programmer and matched them with arduino nano fusebits written in "boards.txt"
- burned bootloader using both usbasp and arduino as ISP.

but nothing worked. I don't have any other smd mega328 right now. So, can't tell if it's a microcontroller fault.

Any suggestion for solving this issue will be helpful.



I'm facing a strange issue with my atmega328p loaded with a Nano bootloader (barebone arduino nano).
I'd first try loading the opti bootloader by simply selecting the 'Uno' board your atmega328p instead of the Nano. Once you've loaded the bootloader, how do you try to load a sketch ? via the bootloader with a USB TTL device or using again the ISP ?


Jul 13, 2018, 06:31 am Last Edit: Jul 13, 2018, 07:45 am by khaledeeebuet
hello 6v6gt. Thanks for your response.

My mega328p is a SMD 32 pin chip soldered on a breakout board and that's why i burned the nano bootloader instead of uno. And i know that uploading program using ISP removes the bootloader. I'm using a FTDI board (FT232RL) from sparkfun as USB-TTL converter to upload sketches after burning bootloader.

And it works perfectly fine within that 30 seconds to 1 minute timeframe before the mega328 halts. After it halts, no programmer works (FTDI, USBASP, arduiono as ISP...nothing) unless i power cycle the microcontroller :(

I'm quite sure that i'm not making any silly beginners mistake.

And there's one more thing that  i forgot to do. I haven't checked if the microcontroller halts if i upload sketch using ISP. Will do it soon. Then i'll know whether or not the bootloader is responsible for the issue.


Code: [Select]
the mega328 halts.
Microcontrollers could their clocks fail, or go into sleep modes, be reset due to power problems, or be in an infinite loop, but they don't "halt."
You need to figure out exactly what's happening.
You said "power is fine" - did you measure it during the actual failure?
What do you have connected to the "reset" signal?  I can imagine some failing reset circuitry that would lead to a permanent RESET condition after some time of power-up...


Jul 13, 2018, 04:46 pm Last Edit: Jul 13, 2018, 04:48 pm by khaledeeebuet

Measured vcc pin voltage before and during the failure. It's okay.  Reset circuit consists a 10k pull up resistor and a push button. I'll measure the voltage of atmega328 reset pin during the failure tomorrow and come back with the results.


It should be really really hard to hang the board in a way that the reset button will not revive it.

Things to check (in order)

Do you have a 0.1uF ceramic decoupling cap between Vcc and Gnd, right next to those pins? (I have had to throw out boards I had made simply because of too long a trace between Vcc to the cap!) These are necessary, and without them, the chip may reset or hang unexpectedly, and potentially end up in a state from which it was difficult to recover from. These are always needed, and must be ~0.1uF and ceramic (or tant, but who uses those now?) You want one of these on each pair of Vcc and Gnd pins, and AVcc. Is AVcc connected to Vcc? It must be, otherwise the chip may malfunction and could be permanently damaged. Unfortunately, a number of guides floating around the internet omit these caps, and sometimes even the AVcc connection.

How did you determine that the power was ok? A glitch sufficient to put a microcontroller into a hung state could be too fast to detect with a multimeter - you might need a 'scope.

Do you have the Brown Out Detection fuse enabled? If not, enable it - it is designed to ensure that the microcontroller does not misbehave, and resets cleanly, in the event of a glitch on the power supply. However, most Arduino people disable it entirely, despite this not being the recommended configuration.

Could it be some other connected device getting into a bad state, and the code blocking when attempting to interact with this device? Often libraries will block waiting for a response, as this is typically easier to implement than a non-blocking library and results in smaller code that is more readily modified by non-expert users. So this malfunctioning device makes the code hang until the whole thing is powercycled. This could be happening due to power problems (maybe you're pushing the on-board 3.3v reg to the limit trying to power an esp8266 or something?), code not treating it correctly, or a defective part. If there are connected parts that could block like that on a board you have designed, do you have decoupling caps on them? Missing decoupling caps could do it (basically any digital IC requires these - unless the datasheet says otherwise)

ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy


changed the microcontroller. problem solved. thanks everyone

Go Up