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

Andy Green andy at
Mon Apr 28 09:55:49 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| Hi Werner, Andy!
| On Friday 11:00 GTA04-hw meeting, following topics left to discuss
with you
| guys:
| o- I suggest PTC-fuse&crowbar USB OVP like attached sketch. Component
| and exact types to be decided upon by Allen/hw team - just suggestion
in my
| sketch.

I don't know that we really need this protection, or it is a reaction to
the unknown "switch burnings" that are seen.  If it is a goal to survive
large overvoltage events for long periods on USB, this circuit will be
good, maybe it will help also with the switch burnings, but is it a goal?

| o- detect USB charger: should we try to detect D+/D- short? Can we detect
| 47kR-ID-Pin with 6400 or do we need additional hw to handle this?

This short is meant to be seen by the "USB OTG" PHY I believe... if 6400
supports it I didn't look yet.

| o- what do we need additional hw for 6400 USB-OTG (charge pump, OVP,
| ESD-prot...)?

Now we chose pcf50633 we either need some OTG-specific management chip
that does this, or to re-use the GTA02 parts.

| o- DL_GSM issue: get rid of dual usage of earjack. Do we need external
| option, or are "internal" testpoints lis FLUID enough? IF we need dual
| earjack, maybe replace electronic switching via DL_GSM by miniature
| mechanical DIP-switch?

I don't know what all the constraints were for making that external jack
method in the first place, but it would be far simpler if we can
communicate with the GSM chip UART fully internally somehow (ie, the CPU
can communicate with this UART) and tunnel the data how we like over USB
or whatever.  I seem to recall Werner mentioned there is arbitrary test
gear from TI or somesuch that terminates in LVTTL UART, but we can still
tunnel this.

| o- JTAG: Is this consens to have 6400 - 430 chain split to configure
| chain or separate access via jumpers / 0R, just for the prototype?
| Allen suggests to have dual debug board setup for split config.

We should not connect JTAG to MSP430 and just have JTAG on CPU.  We can
program the MSP430 using a UART connection.

After I been through the other 200 mails waiting I will post about this.

| o- For prototype(?) the debug-connector sums up to connect JTAG CPU,
| CPU UART (console), GSM UART.

Well we can make a debug connector how we like for the prototype, but
what we need is the FTDI chip on there with USB connection of its own to
drive the CPU JTAG and provide console.

| o- are we going to have Samsung evaluation boards or make them ourselves?

I hope we don't try this hybrid approach where we add some peripherals
to the eval board.  But having one eval board at least "somewhere" will
be good for comparison and early experience about BSP -- we still don't
know about suspend / resume performance we can expect but it is really
important for us.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list