GTA04 ... JTAG

[Andy Green]

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

Somebody in the thread at some point said:
| Andy Green schrieb:
|> Somebody in the thread at some point said:
|> | Joerg Reisenweber wrote:
|> |> Please, before we start to mux UARTs again, and get real bad headache
|> |> like on GTA01
|> |
|> | Yeah, I also don't particularly like this. We've been bitten before
|> | by this sort of multiplexing. Granted, it's more contained in this
|> | case than on GTA01.
|>
|> Yeah, muxing something like that needs an excuse rather than getting
|> waved through.  However the two modes are very distinct, you are either
|> blowing flash in MSP430 or you are seeing Linux console traffic, and the
|> modality is controlled by and affects only the FTDI interface.
|>
|> |> JTAG is designed _exactly_ to be chained up like this, no risk at all
|> in hw,
|> |
|> | That's what I thought as well - before I learned the truth of what
|> | TI have done to JTAG :-( Here's the thread on openocd-development:
|>
|> And indeed it was I that proposed tying them together from the start by
|> JTAG.  We all agree all things being equal we should have them both on
|> one scanchain.  But they ain't equal.
|>
|> Like Joerg says we need an eval board and write the applets to blow
|> flash, etc.
|>
|> -Andy
|
| So if this is MSP430 spoiling JTAG-*chainup*, can't we mux JTAG instead
| of switching from JTAG to muxed serial access? After all JTAG also are
| no more than 4 lines, probably we get away with muxing less than all the
| 4 of them.
| Or is MSP430-JTAG such a crap it even won't serve for an emergency
| backdoor when it's got a TDI-TDO-chain on it's own?

Who knows, Werner found it uses some weirdo TDI clocking scheme.  Do we
really want to buy into that?  There are other issues around needing to
deliver on timing constraints for flash programming which we can't
really guarantee to do with an arbitrary host either, but the bootloader
in the MSP430 does guarantee correct timing.

| Saves us from wasting standard IO-functions on 430 chip for debug
| purposes and thus need for a 'bigger' more expensive chip, while JTAG
| pins just floating useless :-(

We can't let a desire to implement all pins drive our delicate choices :-)

| Anyway for the mux conditions themselves:
| 6400 relies on 430 doing the power management, so 6400 should be hold in
| reset-state anyway, while flashing new code to 430 (means: reset to 6400
| also is muxing JTAG-line to 430).

Actually I think it's important that the 6400 can come up without MSP430
being there at all, since we know it just about works good enough for
GTA02.  Then we null out much of the risk of introducing the MSP430.

| On releasing this debug-reset to 6400, we probably should assert a reset
| pulse to 430 as well (flashing of 430 done, restart it).
| When accessing 6400 via JTAG, we have to rely on proper power setup for
| the 6400 CPU and support things (RAM etc), so we are not supposed to
| mess around with 430-JTAG or bootloader/serial-IF meanwhile (means: JTAG
| to 6400 mutually exclusive with flashing 430 -> 6400-reset not asserted
| excludes meaningful flashing actions to 430.)

Wow I really miss not being able to sit down together and just chew
through everything in one go.

We can hold one or the other thing in BYPASS and it doesn't affect
normal operation.  There isn't any inherent "special mode" for when we
use JTAG, although that's often what you are using JTAG registers to create.

But Joerg, I think the reason to use JTAG on MSP430 is gone and we are
looking at the UART / bootloader scheme.

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

iEYEARECAAYFAkgYJWAACgkQOjLpvpq7dMoebgCdGziWiDvB712+Qn3HNXXrKZHx
ME8An0cQLBIuVzo+iOS9dx4CXLVuaVjw
=gRxo
-----END PGP SIGNATURE-----