Werner Almesberger schrieb: > [EMAIL PROTECTED] 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
