GTA04 Block V4

[Ian Stirling]

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:
> 
> http://lists.openmoko.org/pipermail/hardware/2008-August/000307.html
> 

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. 
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/5233


Headset - USB plugs are widely available, used in the ipod shuffle for 
example.

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.