GTA04 ... JTAG

[Joerg Reisenweber]

Werner Almesberger schrieb:
> 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 :-) 

Maybe - but not for FTDI chip I think ;-)


The FT2232 has two ports. One handles
> JTAG, the other acts as a UART. 

In fact both are programmable to support a variety of different modes, IIRC.


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

Seen this, a plain bug, nothing else (or maybe the selfdestruct feature ;-)



> The second port (UART) has no freely configurable "general purpose"
> lines. 

Both ports are identical. Only in UART mode that is the usual mode for
channel B on debugboard_v3. No?


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

Hey what's wrong with 'muxing' JTAG? We just do by silicon, what you
suggest to do with 0R/NC a few lines below. We *don't need* concurrent
access to both JTAG chains while acitve. Just tweak the one, end
session, 'set jumpers', and start new session with the other one.

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

I suggested a jumper block to have 6400, or 43, or 430 + 6400, depending
on jumper setting. You could also use it to directly connect to any one
of the 2 chains.


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

That's the idea.



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

Exactly that's where I think you can have dual-use of reset lines as
select-signal for the chain (or serial line + reconfig FTDI channel from
JTAG to UART/whatever_serialline_for_430) to enable and hook up to FTDI.
Using some 4line muxer or bus driver or sth cheap birdseed. dbg_Reset_A
enables dbg_line_B and vice versa.

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

Hmm, I don't see this: Use JTAG to disable, to prepare to use JTAG? Have
to think a litle about this... maybe later on I get it.
Anyway I tought of dedicated reset-lines frm FTDI-GPIO to both CPUs.
Straight and clean, easy to probe and to handle.


/jOERG