GTA04 USB OVP, USB charger detect, USB-OTG & 6400, earjack DL_GSM, JTAG

[Andy Green]

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

Somebody in the thread at some point said:
| Werner Almesberger schrieb:
|> Andy Green wrote:
|>> I don't know what all the constraints were for making that external jack
|>> method in the first place,
|> I have yet to see a good reason for it :-)
|
| Maybe flash new GSM-FW at POS or remote service? Dunno... Anyway we're
| all happy once we get rid of it.

Yes indeed!

|> Way too sophisticated :-) There's exactly one time in the life of the
|> phone when this interface is used, and that's during calibration at
|> the factory. We can use test points on the PCB and a fixture with the
|> corresponding pogo pins.
|
| Exactly my suggestion a few hours ago, which was pretty appreciated by
| Tim Lee and Allen Chang

Super duper then.

|>> We should not connect JTAG to MSP430 and just have JTAG on CPU.  We can
|>> program the MSP430 using a UART connection.
|> Hmm, I'm curious what made you change your mind on that. To me this
|> looks like we're planting a big fat wart on a previously beautiful
|> solution. I guess Milosch must have told you something scary ... :-(
|
| Yup, what's this now? JTAG was the main beauty of 430, no?

Low power is the main beauty of MSP430.

| Only question for me was how the JTAG-software is supposed to be
| configured to handle the particular serial daisychain.
| (And not to incidentally blow the fuse of 430 btw XD )

We thought we could integrate it simply into the existing JTAG chain but
there is no support in OpenOCD for this chip anyway.  Allen does not
want to tie the chains together either for "A0" revision.  So we can
come at it another way, remove risk from CPU JTAG access getting messed
up by leaving JTAG -> CPU only, and use a UART-based communication to
MSP430 which should also be relatively low risk.

|>> Well we can make a debug connector how we like for the prototype,
|
| That's what it's all abut if I got this right: the prototype, to test
| the 'new' JTAG circuitry and have a fallback option.
| I suggested a 4pin mini-jumper thing for this purpose. You could jumper
| it to chain 6400 and 430, and you could access each of them with an
| individual debug board, as proposed by Allen.
| BTW: mustn't forget to have separate clock and rst then as well. :-o

The FTDI circuit should be low risk since we copy it from old Debug
board schematics.  I will try to propose a little mux action controlled
from FTDI IO to allow clean access to MSP430 UART for programming it
also from FTDI chip.

|>> ... but
|>> what we need is the FTDI chip on there with USB connection of its own to
|>> drive the CPU JTAG and provide console.
|> Yup. I don't think we want to invent any new debug connector. If
|> there's anything else we need, we're better off if this goes to
|> test points and then a fixture.

OK.

| Just for he cnvenience of our sw-engineers who are going to use this
| thing as a evaluation board eventually, I think we have to find at least
| one method to do flash and JTAG, that's not involving a fixture.

Yes it is even part of the spec to allow flash and JTAG from this
secondary USB connector via FTDI chip.  So we should focus on proving
this working and then using it ourselves for validation of the prototype
and also production test.

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

iEYEARECAAYFAkgVo2EACgkQOjLpvpq7dMpA1ACfR+ebjXocw1s6ixKdZgsnKXLw
4VsAnRnDIf7oN0NEqJiYYVl/UyCnFw8E
=HdBd
-----END PGP SIGNATURE-----