USB-debug // FTDI FT2232D -- need more specs for particular hw design

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Hi Andy,
|
| Andy Green schrieb:
|> |> Power isn't the only consideration, we already thought about bringing
|> |> out debug USB connector to the outside world.  If that is what we do,
|> |> then it is sitting there ready to eat power the same as the OTG
|> |> connector, and it makes sense to allow it.
|> OK, that's an issue alright :-/  We could make it mini USB for debug I
|> guess.  But then we can't share one Power adapter between the two ports.
|> ~ So it stops making sense.
|
| Some Q and Remarks regarding "moving debug-board" --
| Q- Talking about power to debug-USB: should we power the FTDIchip and
| his team by debugcon-Vusb only (using U3, or something less
| sophisticated), so it doesn't take any power while no connection to
| USBdbg? Are we sure FTDIchip will show the behaviour we need regarding
| GPIO-Z|gentle-pulldown etc, while powered down? Or do we need to
| maintain power to debug circuitry all the time, to have the states we
need.
| R- great: the connectors' pin numbers don't correspond on GTA02 &
| debugboard. Probably that's the way it is, but... :-S

OK well we don't use the connector, hopefully it makes no trouble.

If we can power it from host USB power it will solve most of the problem
of it taking current in normal use.  But then we need to take care about
not driving high levels into it from main board when it has no local power.

Joerg, you are at the forefront of finding headaches as we hoped :-))

| O- are there any additional Reset issues to take care of? Like reset of
| MSP430, reset of the FTDI itself etc...

MSP430 has POR built in, if possible though I guess we should also give
it the pcf50633 nRESETHC that is the master for the rest of the system.

| O- could you have a look at the circuit diagram of debug board and maybe
| just prepare a list of parts that are going to vanish? Maybe, even
| better, provide a proposal c-diag, that includes detail regarding the
| serial communication with MSP430? You told there's something you'll come
| up with...

Basically everything goes except the FTDI, USB, couple of HC125 for
reset and TRST generation.  6400 datasheet also requires 10K pullups (to
IO_3V3) on TRST, TCK, TDI and TMS inputs -- which makes for bad static
current dissipation when the FTDI is not powered unless we figure a nice
way.

Everything else on the debug board is not useful AFAICT.

Yes I have to sit and read the app notes.  Basic idea is to use one
signal from FTDI like RTS/CTS kind of thing to mux the serial console
from Linux with UART access to MSP430.

| R- the chip needs quite some real estate (LQFP-48) :-(. Allen will groan
| about it.

Already been pointed out some weeks ago.  I think we will have a
discussion about if we really get to have onboard debug port when we
finalize where the connector comes.

| O- maybe we should keep led2? Or even move it to pin6 3V3OUT.

No I never study these LEDs I doubt anyone else does either.

| O- do we need U3 TPS2149IDGN anyway for FTDI_5V, or may we take 3.3V for
| IO power (14, 31, 17(!??), (10,26 +5V), R67-69) from any other source
(PMU)?

I think we can get away without it (p25)

''In some cases, where only a small amount of current is required (<
5mA) , it may be possible to use the in-built regulator of the FT2232D
to supply the 3.3V without any other components being required. In this
case, connect VCCIOA or VCCIOB to the 3V3OUT pin of the FT2232D.''

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgXAusACgkQOjLpvpq7dMqlvgCfdzYPhvSmmH2EWc9FvHJ+xa6a
DasAn1gmzJy+uPP1RVn8TgSbAqlHrxaw
=WjXI
-----END PGP SIGNATURE-----