GTA04 ... JTAG

[Werner Almesberger]

joerg at openmoko.org wrote:
> ....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.

I think you're confused :-) The FT2232 has two ports. One handles
JTAG, the other acts as a UART. There are a few unused lines on the
first port (ADBUS4 through ADBUS7 aka GPIOL0 through GPIOL3) which
can be used as GPIO.

(Note: in our debug v3 board, we connect ADBUS6 to VCC3. I don't know
why.)

The second port (UART) has no freely configurable "general purpose"
lines. I'm not sure to what extent the host has control over the
modem control lines. Since we have plenty of GPIOs on ADBUS, I'd
suggest we use these for special effects, so that some terminal
program doing the wrong things with the modem controls won't
accidently confuse the MPU or similar.)

Regarding multiplexing JTAG: that sounds scary, and JTAG actually
has the same number of lines to multiplex as the UART. (TDI/TDO for
JTAG, TX and RX for the UART.)

For JTAG, I'd like to have the option of adding the MSP430 to the
JTAG chain, e.g., by changing some 0R/NC components. Then we can
first start work with the serial bootloader, and when we have a bit
of time to clean up things, try to make JTAG work for the MPU.

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

Yes, since MPU and CPU can both access I2C, we must be able to hold
both in reset when the system powers up. Then each can be
reprogrammed while the other is still in reset.

"Hold in reset" doesn't mean to literally assert the reset line.
Some mode where it doesn't execute user code (i.e., CPU halted by
JTAG or MPU running the bootloader) will do.

- Werner