0
\$\begingroup\$

After nearly two weeks of testing, STM32L MCU suddenly stopped working. It is not recognized by ST-LINKv2 debugger (tried connecting using stlink under Linux and STM's ST-LINK utility under Windows).

MCU power is OK, ground and SWD pins are connected.

  • I did not do anything special with device when it suddenly stopped working
  • software does not redefine SWD pins
  • device is powered from battery, so do not expect that MCU was burned by some voltage spike
  • MCU was bought from local reseller that seems to have original parts (but not sure)
  • although present on schematic, quartz crystal and capacitors are not soldered. Device is driven from internal clock (HSI).

It seems that MCU is dead. The only explanation that come to my mind is EMI.

Please help to understand what could be the source of problem.

enter image description here

enter image description here

\$\endgroup\$
10
  • 5
    \$\begingroup\$ "software does not redefine SWD pins" not intentionally perhaps, but this can still happen with a bad firmware load. Look at the past questions which discuss connecting SWD with nReset asserted - that usually lets you do an erase and then reprogram. But also check if the chip is hot or drawing excessive power, either of which would indicate electrical damage. \$\endgroup\$
    – Chris Stratton
    Commented Mar 27, 2017 at 15:36
  • 1
    \$\begingroup\$ If it's not a bad firmware load I wouldn't suspect EMI but ESD damage would be more likely. \$\endgroup\$
    – John D
    Commented Mar 27, 2017 at 15:48
  • 1
    \$\begingroup\$ also, the good ol' mechanical problems should be ruled out, too: cold solder joints becoming non-contacts due to time, vibrations, temperature, capacitors breaking, particles shorting pins, that kind of fun \$\endgroup\$
    – Marcus Müller
    Commented Mar 27, 2017 at 15:54
  • 1
    \$\begingroup\$ @Trevor 2 weeks of man-handling without using a case. Got your point \$\endgroup\$
    – rostokus
    Commented Mar 27, 2017 at 19:47
  • 2
    \$\begingroup\$ @ChrisStratton it was my bad. Instead of NRST I've connected TRST (pin 3 on STLINKv2 connector). After using NRST pin and setting "Connect after Reset" option in ST-LINK utility I was finally able to connect to MCU. \$\endgroup\$
    – rostokus
    Commented Mar 27, 2017 at 21:48

1 Answer 1

Reset to default
4
\$\begingroup\$

Assuming batt/MCP73831 is 4.2v, the TPS7361's R9 and R4 produce an output of 3.0v so this is Vdd. If PWR_OFF were an output (either state) while S1 were closed, even for an instant - that is a direct path back to the battery (4.2v, 1.2v more than Vdd.)

Edit: The STM32L152RBT6 does have many 5v-tolerable inputs (and no \$V_{DDIO}\$ pin to limit this), of which PB12 (pin 33) is one. So what must have happened is, the button was pressed while the micro was asserting an output on this pin, then more current than was allowable flowed into the device (from a pin higher than Vdd.)

Section 6.2, table 11, Absolute maximum current ratings, shows \$I_{INJ(PIN)}\$ is limited to -5/+0mA. My guess is that pressing the button while the output was asserted happened, and the chip failed from an over-current condition.

I'd use a mosfet or BJT to pull EN low instead of pulling the line directly from an output. As @Chris says in the comments, it may be possible to cut a trace and splice in an alteration, but this part of the circuit needs some more thought.

\$\endgroup\$
6
  • 2
    \$\begingroup\$ Nice catch .... \$\endgroup\$
    – Trevor_G
    Commented Mar 27, 2017 at 16:33
  • \$\begingroup\$ It would appear that the mistake may be in connecting the PWR_OFF signal to the MCU at all. Perhaps that was added to an existing design that used the sensible path through the diode from MCU_PWR_EN in an attempt to provide a force-off that could override the switch, if so, that needs to be re-thought. Possibly something as simple as a series resistor that would form a divider with the existing pull-down would keep the voltage in a safe range, or at least limit the current through the protection diode. \$\endgroup\$
    – Chris Stratton
    Commented Mar 27, 2017 at 19:52
  • \$\begingroup\$ Cutting the PWR_OFF trace, making D3 a resistor and D1 0-ohm, then using MCU_PWR_EN for both purposes could perhaps salvage the existing PCB, though it's not really clear why overriding the switch is necessary. Another approach sometimes used is a series capacitor for the turn-on path, and the MCU then either starts sustaining the enable, or if the program or brownout detector decides the cell voltage is too low, lets it drop; the capacitor means it can only keep draining the cell if pressed and released, not merely held on by being jammed into a backpack. \$\endgroup\$
    – Chris Stratton
    Commented Mar 27, 2017 at 19:55
  • \$\begingroup\$ @rdtsc PWR_OFF is connected to five volt tolerant pin. Does 4.2V can hurt? \$\endgroup\$
    – rostokus
    Commented Mar 27, 2017 at 20:26
  • \$\begingroup\$ @ChrisStratton exactly, PWR_OFF was added later in order to implement software power off of device. Adding resistors instead of diodes wont help to distinguish when button was pressed to power off the device. \$\endgroup\$
    – rostokus
    Commented Mar 27, 2017 at 20:43

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