GTA04 MPU alternatives / CPU can work without MPU

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> We go on with MSP430FG4618.
|
| Perfect. Pheew, what a battle :-)

What battle... violent agreement broke out from the start.

| Now, on to the two remaining MPU issues:

Loads of other things to figure out, but...

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

I like LDO6 much better than the backup battery idea.

I checked and on variant 04 LDO6 comes up at 3.0V from cold on
"activation phase 3" if I understood it.  It would have been better if
it came up earlier because DOWN1 -> 1.2V CPU Core voltage comes up at
the same time.  But it is probably OK.

I asked Milosch what he did about this, and if I understood it he has
the MSP430 powered outside of the PMU altogether.  But I don't think it
makes a serious issue if CPU core comes up at 1.2V before getting
adjusted, it mainly affects the fastest speed for it.

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

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

So long as you know the instruction register length, you can "null out"
intermediate devices using a standard-mandated known instruction
("BYPASS") .  So if you don't understand a device in the chain, it is
guaranteed to not stop you using the other devices in the chain.  So
long as the software can cope.

I think we are best off just hooking it to the CPU.

| 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

This isn't a real concern.

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

We didn't discuss JTAG.  JTAG is not really used in our test flow at the
moment except to push U-Boot in the CPU memory space.  It'd be
interesting to know from the MP statistics exactly how many devices
could have been detected as bad from JTAG and what it would have saved
us.  For example, are true problems coming from open pins on some chips,
shorts on others we could detect from JTAG, etc.

Milosch's project isn't Open like OM, so he used a freebie compiler from
the TI site which has some hard limit at 8K code IIRC.  I think we
should try to use gcc one.

However, thinking about prototype 1, I think we should try foremost to
see if we can design the thing to come up without an active MPU at all.
~ We already decided that we bring IO signals to CPU and MPU, and now we
look to power the MPU from the PMU, in fact we deal with a consistently
autonomous bringup already.  Let's see if we can leverage that in order
to reduce the risk the MPU brings to the design to a very low amount,
such that we expect the CPU can come up with MPU absent.  Then the
prototype does not depend on and is not delayed by what is happening
down at the MPU.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgVn/sACgkQOjLpvpq7dMqF4QCfdwhbE1XhcoLWK0AKXe7txYFx
QycAnRmVLfaIhheKigLyrJgX/VuXSQDl
=pvXT
-----END PGP SIGNATURE-----