GTA02 MPU alternatives

[Werner Almesberger]

Andy Green wrote:
> We go on with MSP430FG4618.

Perfect. Pheew, what a battle :-)

Now, on to the two remaining MPU issues:

- power supply

- programming (as in "loading Flash content")

For the power, I'd suggest we take the LDO6 approach as our current
working hypothesis. In the unlikely event that we later run into a
case where we actually need the MPU to have power even if Vsys is
down, we can always tweak go back to exploring the alternatives.

Another thing that could kill this approach is if we need LDO6 for
some other purpose. In GTA02, it only supplies LCM_3V, which we could
probably also just attach to RF_3V (that's the supply for GPS),
provided our GPS module has suitable internal gating. We'll also have
to look at whether we stay in the total current budget.

Does anyone think this is not a good idea, or are there any obvious
reasons why this wouldn't work ?


On to the programming. There was some discomfort with using JTAG. I
think the main objections were:

1) if we connect the JTAG chain improperly, JTAG will not work at all

2) OpenOCD doesn't support the MSP430

3) the JTAG chain grows

Are there any other potential issues with using JTAG ?

I wonder if 1 is a high-risk item. Connecting those few lines seems
simple enough to me and we should be able to eliminate any mistakes in
review. Am I overlooking some insidious source of danger ?

I'm not sure how bad point 2 is. Would it be really all that hard to
add MSP430 Flash programming support ? (We don't need all the
debugging features that JTAG also can provide.) Do Linux-based MSP430
developers use JTAG today to program their MSP430 ? If yes, could we
use their solution ?

Point 3 means that OpenOCD has to be able to deal with a JTAG chain
that contains things we're not currently interested in. I don't know
if this is a problem for OpenOCD or not. We'd certainly need a new
OpenOCD configuration file describing the chain layout.

Another effect of having a longer chain would be that shifting data
through it takes longer. Also, a longer chain may be more susceptible
to bit corruptions or similar errors. Since JTAG is designed precisely
for a configuration where all the JTAG-capable devices on a board are
in a chain, I wonder how probable it is that these potential issues
turn into real ones.

What would happen if we didn't have JTAG to program the MPU ? Then
we'd either have to establish a "private" access path (test points,
special configuration through the FTDI, etc.) to one of the MPU's
mechanisms to load the firmware.

Alternatively, and I think this is what Andy mentioned as a
possibility, we could interface the MPU with the CPU, so that the CPU
would connect to these interfaces, and that we'd program the MPU
through the CPU. This, however would imply that we can't rely on the
MPU to help setting up the PMU. I.e., if a firmware download goes
awry, we'd need some alternative unbricking method.

We'd also have to provide the tools that implement that alternative
programming method over the interfaces we offer. Whether this is easy
or incredibly messy depends a lot on where these interfaces are.

In any case, it seems to me that creating such a "homebrewn" solution
has a much higher risk of unintended consequences, both on the
hardware and the software side, than just getting JTAG to work.

Long-term, I having JTAG on as many chips as possible would also allow
us to do boundary scans as part of our production testing process. I'm
not sure how many of the hardware problems we actually encounter in
our production could be spotted more efficiently through JTAG than
through a different testing process, but I think it's only prudent to
keep this option open.

Andy, since you'll discuss the MSP430 with Milosch this weekend anyway
(duh, it's this weekend, right ? Or was it the last one ? The weeks
blur into each other ...), perhaps you could find out what his
experience with JTAG there is, and then we can decide on a further
course of action. Does this sound good ?

- Werner