GTA04 ... JTAG

joerg at joerg at
Wed Apr 30 10:20:33 CEST 2008

Am Mi  30. April 2008 schrieb Andy Green:

Except for the one erroneous line marked below....

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

....I'm not mentioning *JTAG* for 430. The scheme proposed above might apply 
as well when using serial IF of 430 for flashing - as long as we may mux a 
JTAG chain used for 6400 to the same port of FTDI chip as a serial line used 
for 430.

Power: even when we say there is an ability to come up autonomously without 
430, there still is the possibility that 430 spoils clean power actively when 
it's missconfigured. Anyway we probably never will need to or want to flash 
430 AND 6400 *at the same time*, so we could and should share *one* port of 
FTDI for the two purposes, and there's very little chance for headache then. 
That's all I say in my suggestion.

Also did you notice my remarks from 11:00 meting regarding the rich choice of 
serial IO on GSM module?


More information about the openmoko-kernel mailing list