GTA04 Block V4
yair at mahalalel.com
Sun Aug 17 08:07:55 CEST 2008
Sorry for jumping late into this thread, but having that I didn't notice
it earlier, and that I had no idea of these design challenges, I find
the puzzle interesting and I hope I can provide some insight from on
outsider point of view.
The way I see it, the two main problems, 'unbricking' the system and low
level debugging it, share the common requirement of having to be handled
externally, i.e. by running code outside the usual framework which is
either broken, gone, corrupted, or simply under scrutiny.
While this external code may still run on the main processor and
use its internal memory banks, I think this is not only complicated, but
also dangerous - if a piece of rogue code acquires root privileges, it
might very well possess unseen means to erase the entire flash for
either disabling or hijacking the phone. The recovery measures, at
least, should be protected in hardware.
Ideally, the processor on the other end of the JTAG, I2C or serial
loader interfaces should be a PC, but computers these days cannot be
assumed to have any communication port except USB, and that requires a
second micro-controller to mediate between the two (some USB<->UART
adapters will let you run them unconifugred, but then the host computer
will not recognize the device, will be only seeing a serial interface on
the other side, and will badly limit your options, unless you do have a
second core to flexibly handle the serial stream).
Putting the second core on an intermediate board seems to me inelegant
for a consumer device. A second core might have been unreasonable when
the PC was invented, but this is exactly why it is so 'brickable' - find
a way to thrash your BIOS and unless you have pretty decent technical
skills you can bin your computer. I'm sure we can do better than that.
I suggest a solution that will have the smallest impact on the rest of
the system - an 8-bit uC such as Microchip's PIC18LF4550, which will
stay dormant and waiting when unneeded (at 2V/100nanoWatt, it might even
be worth keeping alive when the phone is off) but when triggered (hidden
button, watchdog, etc.), it will hijack the USB port (or the headset
one) and take control over the main processor.
The hardware cost is not trivial - in addition to the chip size of
8x8mm, it will require a few decoupling capacitors, two switches to
divert the USB data lines and possibly an external oscillator
for USB (which might already exist on the board, but perhaps cannot be
relied on in all circumstances) - but I think it's still relatively
small. At ~$3, their impact on the BOM cost will be small as well.
In return, you get native full speed USB2.0 (i.e. 12Mbps) with 32
endpoints (perhaps the main processor's port can be tunneled through?
It'll be a pity not to be able to debug it), hardware I2C, SPI, USART,
SPP ְports (not all simultaneously, but you can bit bang the rest), 35
GPIOs, and even 13 A2D converters in case you want to beep the user that
the battery is dying without waking up the main CPU.
At full throttle, the chip can do 12MIPS (4.2-5.5V, 20~50mA) which isn't a
cell processor, but should be enough for the intended tasks. The
bootloader can be loaded over USB, which is useful both for
catastrophic data loss cases and for developing/debugging it, and can be
stored in an eeprom connected to the PIC, where it will be well protected,
easily updated, and can be written before populating the PCB so the phone
is bootable right out of assembly.
The reason why the PIC will be far more secure than the main processor
is that although it is capable of reprogramming itself (almost)
completely via USB, its USB port is only connected to the external
socket on the phone, and can be only accessed using deliberate,
_physical_, action by the user.
I can see why a second development environment can be a hassle, but as a
second processor seems unavoidable, this is one of the simplest, best
documented ones, with many Free tool chains, available code and supporting
community. Or perhaps, since until my shiny new FR only arrives next weekend
these crickets are still my hammer of choice, every problem seems to me
to be their nail. :-)
PS. I had a look at the MSP430 family, and although they are quite
similar in principle, you do need one of the larger ones in order to get
a comparable feature-set to that of the PIC. If their size and
requirements are what fuels the objection to a second MCU, perhaps the
small but very flexible PIC can provide a suitable compromise.
More information about the hardware