helena-project
FTDI pulls reset low by default
(I'm not sure there is anything great to do about this)
When I attach a terminal to the FTDI, DTR--which is connected directly to the SAM4L's RESET signal--is pulled low, and the board effectively halts. stormloader relies on this to be able to reset the board, so this behavior is identical on the Firestorm, but it's a huge bummer because it means that typical utilities for connect to a serial port (e.g. miniterm, minicom, screen, etc) don't work by default.
There are currently two workarounds I've found:
-
miniterm2.pytakes a--dtrargument which tells it to assert or de-assert the DTR signal.miniterm2.py --dtr 0 /dev/ttyUSB0 115200works for me. I'm not sure how to do this with other utilities. -
We can program the FTDI chip to invert the DTR signal, which would allow connecting through a terminal serial applications to work out of the box, but the reset signal will be held low by default, so the board won't run.
How does Arduino manage this? Thoughts?
Arudino manages this in hardware. It uses a DTR transition to trigger a timer, so a reset pulse is emitted on a DTR transition, but the steady state of DTR is ignored.
On Fri, Dec 2, 2016 at 11:40 AM Amit Levy [email protected] wrote:
(I'm not sure there is anything great to do about this)
When I attach a terminal to the FTDI, DTR--which is connected directly to the SAM4L's RESET signal--is pulled low, and the board effectively halts. stormloader relies on this to be able to reset the board, so this behavior is identical on the Firestorm, but it's a huge bummer because it means that typical utilities for connect to a serial port (e.g. miniterm, minicom, screen, etc) don't work by default.
There are currently two workarounds I've found:
miniterm2.py takes a --dtr argument which tells it to assert or de-assert the DTR signal. miniterm2.py --dtr 0 /dev/ttyUSB0 115200 works for me. I'm not sure how to do this with other utilities. 2.
We can program the FTDI chip to invert the DTR signal, which would allow connecting through a terminal serial applications to work out of the box, but the reset signal will be held low by default, so the board won't run.
How does Arduino manage this? Thoughts?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/helena-project/imix/issues/13, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUt3p1NVbFZzk45U5i5WKqTd7FvsaG-ks5rEEnpgaJpZM4LCvwm .
Related to this, it also looks like imix doesn't have a 1K resistor between RESET and VCC as the Firestorm does and that this might be the cause of issues with JLink failing to pull RESET low. There two new pieces of evidence for this:
-
hailhas the same issue and patching in a resistor seemed to fix it (according to @bradjc, @brghena & @ppannuto) -
When powering imix through JLink and not connecting a USB for power, the reset warnings go away.
After testing with miniterm, Amit and I concluded that the current behavior is identical to hail, and I'm not planning to fix this for the next revision. Leaving it open and labeled as wontfix for further potential future research.
@ppannuto If I AC-couple the DTR line to the RESET line (as Arduino does), would it be possible to get the behavior we want? It actually seems like a trivial fix (one capacitor), but I don't know if it would cause an undue overhaul in the tockloader or if it would break compatibility with Hail.
@ppannuto @alevy After some experiments, I found by that removing the reset pullup resistor and replacing the DTR-RESET resistor with a 1uF cap, the DTR can pull down the reset line when desired but the steady-state doesn't make a difference. I was able to successfully get a terminal with all different configurations of miniterm and screen. tockloader listen works correctly, so I'm assuming that the other tockloader functions will work if I use the bootloader. Unless there are any objections, I'm going to make this change.
I think we should replicate this design on Hail, by the way, since it fixes all of the undesired behavior.
Interesting (and cool, nice work). My understanding is that Arduino adds the unbalanced resistors to lengthen the reset pulse. What does the reset pulse with just the cap look like (duration, especially below reset threshold?). The SAM4L datasheet (sec 42.10.1 RESET_N Timing) specifies a minimum pulse width of 10ns (which upon looking up is wonderfully short, so I suspect the coupling approach works well)
(I have just no idea what to make of that footnote though; would make me inclined to be comfortably longer than 10ns pulse)
(this is pretty far out of my comfort zone, so I'm just listening with interest, not commenting)
@shaneleonard could you grab a scope trace probing both sides (DTR and RESET_N) of the cap?
@brghena assuming that looks good, moving hail over to a cap probably a good improvement
Yeah, ran that experiment last night but forgot to snap a pic. When DTR transitions low, Reset immediately goes to 0V and exponentially rises with a rise time of about 80 ms (it's logic low for about 20 ms). When DTR transitions high (after Reset has resettled high), Reset spikes to 4.2V and decays back to 3.3V. I'll post the screenshot once I take it again.
The 1uF seems to be overkill, so if it's interesting, I can try a handful of values. I have 470nF and 100nF on hand (although 100nF didn't seem to work when I first tried it)
@ppannuto @brghena
This first picture shows DTR (yellow) transitioning high to low. The reset line (blue) is logic low for 8 ms (shown by the cursors)
Here, DTR is transitioning low to high. The reset line hits 4.24V at its maximum. Note that DTR doesn't have as sharp of a transition here.
Sorry for the cell-phone photography by the way. Couldn't find my flash drive to plug into the oscilloscope :/
@ppannuto @brghena Let me know if you would like me to repeat this for 470nF and/or 100nF.
I think that cap choice is fine. Strictly speaking, it'd probably be good to double check in the datasheet that the reset pin is 4.2V tolerant and that this doesn't wear on the chip (o/w you'd need a clamping diode), but I suspect that's a low enough and short enough transient that it's not a big deal.
@brghena pointed out that when @daniel-scs gets USB support up an running, we can just incorporate that into the bootloader, and drop the FTDI chip altogether, so likely not worth propagating this change to hail. But since you're already spinning a new rev of imix, it looks good to me.
Datasheet doesn't mention reset being tolerant to a particular level, it just gives a flat 3.6V as the maximum operating voltage for the power domains and I/O. I can add a clamping diode.