GTA04 Block V4
OpenMoko at mauve.plus.com
Fri Aug 15 17:19:20 CEST 2008
Werner Almesberger wrote:
> Ian Stirling wrote:
>> This would basically be a 'last chance, should never happen' event.
>> It's in case someone intentionally unprotects and flashes the bootloader.
>> (Intentionally, as it requires 2 specific 32 bit words written to the
>> flash controller - which should not be present on the device, and be
>> communicated to it by the 'flash' program.)
> Ah, now I see what you mean. If I understand things right, we may
> not have to worry about this scenario:
That works too.
I went off on another tangent after this, and started thinking about
something else, though I have not had time to flesh it out properly.
Headset connector is quite sane and already exists.
Well protected USB switches are available.
Headset - USB plugs are widely available, used in the ipod shuffle for
In normal headphone/headset operation, the switch simply connects L and
R to the audio amp.
When a USB->headset connector is detected, it switches to USB.
When Vbatt = 0, and VheadsetIn = 5 (the state caused by the rest of the
circuitry being unpowered, and the switch powered by VheadsetIn), it
supplies a few mA to the STM, and then connects the rxd and txd of the
STM to the serial bootloader.
I was trying to elaborate this with another voltage, to allow the serial
wire debug of the STM, when I realised I might be insane.
This also potentially allows a much easier connector to 'dock' with.
As I understand it, this would be compatible with headset wiring, but I
haven't gone into this in detail.
This does not answer the 'user does not have debug board' - but it
reduces the nastiness of the 'dev board' - it's just a picked RS232-USB
adaptor, a DB9 on a board, with a headset plug, and 4 or so passives,
rather than having a FPN.
Sorry for not fleshing this out properly before posting.
More information about the hardware