0
\$\begingroup\$

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?
\$\endgroup\$
4
  • \$\begingroup\$ How good is the PCB layout? How reliable is the 4 volt supply? \$\endgroup\$
    – Andy aka
    Jul 2, 2019 at 7:44
  • 1
    \$\begingroup\$ 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? \$\endgroup\$
    – Justme
    Jul 2, 2019 at 9:44
  • \$\begingroup\$ @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. \$\endgroup\$
    – Lundin
    Jul 3, 2019 at 12:54
  • \$\begingroup\$ 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. \$\endgroup\$
    – Sai Prasad
    Jul 4, 2019 at 7:48

1 Answer 1

2
\$\begingroup\$
  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.

\$\endgroup\$
7
  • \$\begingroup\$ 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. \$\endgroup\$
    – Sai Prasad
    Jul 3, 2019 at 11:23
  • \$\begingroup\$ @SaiPrasad So what is the power source? \$\endgroup\$
    – Lundin
    Jul 3, 2019 at 12:52
  • \$\begingroup\$ The 4V supply is a LM2596 based buck converter supplied from a 12v power brick. \$\endgroup\$
    – Sai Prasad
    Jul 4, 2019 at 7:49
  • \$\begingroup\$ @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. \$\endgroup\$
    – Lundin
    Jul 4, 2019 at 7:53
  • 1
    \$\begingroup\$ @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. \$\endgroup\$
    – Lundin
    Jul 4, 2019 at 7:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.