I have a USB to TTL (UART bridge) that is connected permanently to a custom board with an ARM MCU. The UART lines are shared with the JTAG programming lines. The problem is that even without any activity on the UART, the presence of the USB to TTL converter loads the line and sometimes this creates problem with trying to connect with the JTAG programmer.
The most trivial solution would be to disconnect the UART lines from the UART bridge, however that is a bit complicated in the present setup. The other solution is perhaps to pulldown the lines with a large resistors, perhaps 100k? Any other thoughts?
-
2\$\begingroup\$ It would really help if you could post a schematic of this part of the board and identify both the JTAG target and the USB-UART parts. Some would say you should also link the data sheets. Without this information, the question may get some negative reactions possibly including close votes. \$\endgroup\$Chris Stratton– Chris Stratton2020年12月06日 21:02:52 +00:00Commented Dec 6, 2020 at 21:02
-
\$\begingroup\$ In general, two outputs cannot be connected together. So at least the TXD output from the TTL-UART bridge will conflict with whatever other functionality of the pin. \$\endgroup\$Justme– Justme2020年12月06日 22:33:14 +00:00Commented Dec 6, 2020 at 22:33
1 Answer 1
Unless you have general signal-integrity board design issues and are trying to use quite fast clocks, your issue doesn't seem to be "noise" but rather loading and driver conflict.
What you need to do is to get the USB-UART chip to tristate all signals. How you would do that is typical device-unique, but many can be commanded to do this from a host, or may have a reset pin accomplishing such purpose.
If you cannot do that, you'll need to put in series resistors of several kilhohms and hope that this allows the JTAG adapter to out-drive the thus weakened states of the USB-UART outputs.
Another solution might be to find something that could function as either the USB-UART or the JTAG adapter, under software command from the host. Depending on the signal assignments, something like an FT2232H could perhaps do it. Something more flexible like an FX2 or FX3 almost certainly. And an implementation in a generic USB-enabled MCU could obviously be customized to accomplish both roles.