0

I've been working on a project with Atmega328PB microcontroller using both the UARTs for communication. The controller runs fine for a long time but all of a sudden it does not respond at all. It happened two times in a span of one week. The weird issue is, it does not even respond to hardware reset, i.e., connecting RESET pin to ground. But it works normally if it is powered off by removing the supply and connecting it again. It is supplied with a 4V source with a 100nF capacitor to the Vcc pin of the controller and RESET pin is pulled up through a 10K resistor. Below is the schematic of the circuit.

Schematic

My questions are :

  1. Is it a hardware or a software problem?
  2. FYI, it has extensive use of pointers for string manipulation. Does memory leaks cause the issue?
  3. It has WDT (Watch dog timer) implemented. Does it affect the Hardware reset?
  4. What could be cause of this problem? Did any body face this kind of issue?
Mike
  • 2,146
  • 1
  • 14
  • 29
Sai Prasad
  • 101
  • 3
  • 15
  • How good is the PCB layout? How reliable is the 4 volt supply? – Andy aka Jul 02 '19 at 07:44
  • 1
    What is the 4V supply and how stable it is? Is there an expected voltage range for it? There is only 100nF bypass cap but no bulk cap at all. Also post the code so we can tell if it is a software problem. Is the brown-out detector in use? If yes, at which level? – Justme Jul 02 '19 at 09:44
  • @Justme If the MCU is truly ignoring /reset pin pulled low, and doesn't simply continuously reset itself, we can rule out software. It's a latch up in that case. – Lundin Jul 03 '19 at 12:54
  • The 4V supply is a LM2596 based buck converter. I used it with numerous circuits with no issues of this kind. The brownout detection is not programmed in the fuse bits configuration. – Sai Prasad Jul 04 '19 at 07:48

1 Answers1

2

  1. From what you describe, something in the MCU goes into "latch-up", a hardware error state. This could be caused by wrong supply voltage, transients, overcurrent etc etc.

  2. It can't have anything to do with software or a physical reset by pulling /reset pin low would have restored it. If you have dynamic heap allocation on a 8-bit MCU, you are doing it very very wrong. So there should be nothing that could cause memory leaks. (See Why should I not use dynamic memory allocation in embedded systems?)

  3. The watchdog would work similar to pulling the /reset pin low. What you can do though, is to measure if the MCU is repeatedly resetting through watchdog or other sources, by monitoring the /reset pin with an oscilloscope.

  4. One obviously fishy thing is 4V. Why on earth do you have such a weird supply voltage? Industry standards are 3.3V or 5V respectively. Are you driving the MCU directly from raw batteries or something? It needs a stable supply from a voltage regulator, or otherwise you'll experience brown-out phenomenon and/or resets caused by brown-out detect circuitry.

Lundin
  • 17,577
  • 1
  • 24
  • 67
  • thank you for the lead but the 4V supply is for the other chip that is connected to the same supply as the microncontroller. It needs 4v for its operation. I tried resetting the controller by pulling the RESET pin low but doesnot respond. But turning the power completely off and turning on does the trick but that is not desirable. FYI, the fuse bits are setup to not to consider brownout detection in this case. – Sai Prasad Jul 03 '19 at 11:23
  • @SaiPrasad So what is the power source? – Lundin Jul 03 '19 at 12:52
  • The 4V supply is a LM2596 based buck converter supplied from a 12v power brick. – Sai Prasad Jul 04 '19 at 07:49
  • @SaiPrasad Well, you have some manner of hardware error somewhere... and that's all I can say with the information given. But do verify with a scope that you don't have continuous resets on the reset pin, before anything else. – Lundin Jul 04 '19 at 07:53
  • I've tried some more tests recently which i want to share. I've now removed the watchdog timer for reset, the hardware reset works. I don't have any clue what's going on. – Sai Prasad Jul 04 '19 at 07:54
  • 1
    @SaiPrasad Then it isn't latch-up and it could be software causes. Which is why I have repeatedly told you "What you can do though, is to measure if the MCU is repeatedly resetting through watchdog or other sources, by monitoring the /reset pin with an oscilloscope." This is the first thing you should do when a MCU is misbehaving. – Lundin Jul 04 '19 at 07:56
  • It's almost certainly a "brown out" or a glitch on the Vcc. Means, that the Vcc goes below the minimum voltage of the chip but not to zero and than recovers. This can lead to latch-up. It could also be a short voltage spike (or drop in voltage) that leads the MCU to go into an undefined state. In my experience it's the EEPROM control that goes bonkers and does not reset its busy-flag anymore.This flag is NOT reset by a reset signal. – kruemi Sep 05 '22 at 08:26