FTDI pulls reset low by default

[alevy]

(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:

1. 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?

[ppannuto]

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 ***@***.***> 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: 1. 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 <#13>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUt3p1NVbFZzk45U5i5WKqTd7FvsaG-ks5rEEnpgaJpZM4LCvwm> .

[alevy]

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:

1. hail has the same issue and patching in a resistor seemed to fix it (according to @bradjc, @brghena & @ppannuto)

2. When powering imix through JLink and not connecting a USB for power, the reset warnings go away.

[shaneleonard]

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.

[alevy]

@shaneleonard I agree with this assessment, I think it's fine. I'm closing.

[shaneleonard]

@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.

[shaneleonard]

@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.

[shaneleonard]

I think we should replicate this design on Hail, by the way, since it fixes all of the undesired behavior.

[ppannuto]

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)