When an input pin isn't one May 2016
The article about the ESP-Link ended with what turned out to be an ominous note, in hindsight:
There’s still a buglet in this setup: the “reset” word leads to a runaway loop of “
Unhandled Interrupt 00000003” - but this can be recovered through […]
Something really strange was happening:
- toggling the DTR pin from the ESP-Link did correctly reset the Olimexino
- but doing a software reset sent the Olimexino into a tail spin
And here were the crazy bits:
- the software reset worked fine when DTR from the ESP-Link was not connected
- once in this endless fault loop, even pressing the RESET button did not work (!)
To summarise: the ESP-Link itself works brilliantly. It gets data across between the Olimexino serial FTDI port and WiFi, in both directions and at full 115,200 baud speed, without dropping a single byte. The Reset button on its “Console” web page allows getting control back from any runaway code loop or crash, and does this again without any hiccups whatsoever.
But enter the word “
reset” followed by a newline, and you get this:
The yellow trace is the RESET (DTR) pin, blue is serial data from ESP to STM, and green is serial output data, i.e. from STM to ESP. Note that the three traces overlap to fit on the screen.
First the characters “reset” are sent and echoed, then a brief delay, then a CR is sent (and echoed as a space), and then… total havoc!
With the RESET / DTR pin disconnected, it all works exactly as expected:
The Mecrisp welcome greeting, and a little later a custom message
from the “
The crucial observation: how on earth can a software reset behave differently when a hardware pin connection is changed? (thx to Matthias K for pointing this out) - a power glitch? noise?
After many, many hours of head-scratching, it turns out that the answer is hidden in this sneaky little diagram, mentioned in STM’s reference manual (RM0008, p.90):
The RESET pin is not just an input pin, it’s also driven low when a reset is generated internally! - with the pin tied to the “stiff” output pin on the ESP-Link, it was fighting against a high logic level and ended up causing a hardware fault interrupt. Note that the µC continued to work as it was sending out messages over serial at the proper baud rate. It just never reached a reset state…
Once identified, the solution was trivial: just add an extra diode, so that the ESP can only pull the µC’s RESET pin down. Now, internal resets no longer face the “1” output level when pulled down, and instead perform a clean reset, shaped by the RC circuit on the Olimexino board:
And indeed, everything works with the diode - here is the RESET pin during a software reset:
Spot-on: 10 kΩ + 100 nF = 1 ms RC rise time, at which point the RESET pin is ≈
67% of Vcc (ignore the the scope’s 1.80 ms value for
tr: it’s calculated from
the 10%/90% points).