MetaWatch Hacking

25.7.: Currently I am hacking with V0.7.10 and V0.7.11of the firmware - things will change!
28.7.: V0.7.13 ;)

Hidden button press codes

There are two long-button-press key that might be of interest. Buttons are arranged looking at the display face, left three buttons flat, right three button standing out. From upper to lower let's call the left three A, B, C and the right three D, E, F, then:

Hardware

The hardware consists of two major parts, the watch itself and a charger clip.

The Watch

Architecture

The watch is probably based on a TI reference design for the MSP430 and CC2560 low power Bluetooth module. The MSP430 version used in the MetaWacth is a MSP430F5438AIZQWR. More information about the TI-MSP Bluetooth platform can be found here.

It is very annoying that TI itself does not provide any meaningful information about the CC2560 module itself - no datasheet, no extended HCI description, nothing. Judging from the description of the proprietary stack API there must be HCIll commands e.g. to configure / set certain low power states in the module.

Display

A quite remarkable part of the watch is the display, a bi-stable monochrome graphics display with 96x96 pixels. The quite unique part about the display is that it does not display black and not-black, as most monochrome LCD do! Instead it has a mirror on its back so that active pixels which would be black become transparent and by the mirror they become fully reflective. The non active pixels remain dull and do not fully reflect. The effect is that the display looks very unintrusive, stylish and cool! But it has the drawback that it is sometimes a little hard to read, e.g. when something white is reflected.

I am not sure but the display could be a Sharp LS014B4DN02, a datasheet can be downloaded from Mouser Electronics: LS013B4DN02.pdf

And here is the original information on Sharp's web-page.

Power Supply

The power supply is done through a CR2040(?) Lithium-Polymer (LiPoly) coin cell - it is new to me that those exist but very handy!

Connector

The watch can be charged and programmed with a four-position connector on the back-side. From top to buttom the pins are

Here are some pics of the hardware.

Charger Clip

The charger clip is more than just a simple charger. It contains another TI-MSP430 controller which emulates the TI-MSP430FET debugging and development interface. Using the clip the MSP430 inside the watch can be updated and reprogrammed! And besides of course it will charge the watch's internal battery.

Software, Development

Linux Bluetooth Client

I am hacking on some Linux host side Bluetooth software so that one can control the watch from Linux. The code is still very much in flux so be warned! You can look at it in our labs GIT repo: http://git.kernelconcepts.de/?p=metawatch.git;a=summary

I intend to make that code into a library so that Linux applications can be built upon it and use sort of a simple API to talk to the watch.

The Firmware

Once the firmware for the watch is release we can also start firmware hacking - yeha! For the time being you can already play with the clip's FET and the watch using the latest mspdebug tool. You can connect mspdebug to the watch using the rf2500 driver as described here for the Launchpad - for the MetaWatch this is almost the same. If you really want to be as perfect as possible use the "-v 2500" option to specify 2.5V voltage - but this is rather irrelevant since the clip does not contain any reprogrammable level shifters, it is fixed to 2.5V. 

$ mspdebug -v 2500 rf2500
MSPDebug version 0.13 - debugging tool for MSP430 MCUs
Copyright (C) 2009, 2010 Daniel Beer 
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Trying to open interface 1 on 066
rf2500: warning: can't detach kernel driver: No data available
Initializing FET...
FET protocol version is 30132072
Configured for Spy-Bi-Wire
Set Vcc: 2500 mV
Device ID: 0x0580
Device: MSP430F5438A
Code memory starts at 0x5c00
Number of breakpoints: 8

Available commands:
    =         dis       help      locka     prog      run       sym
    break     erase     hexout    md        read      set
    cgraph    exit      isearch   mw        regs      setbreak
    delbreak  gdb       load      opt       reset     step

Available options:
    color     gdb_loop  iradix    quiet

Type "help " for more information.
Press Ctrl+D to quit.

(mspdebug) reset
(mspdebug) run
Running. Press Ctrl+C to interrupt...
^C
    ( PC: 061aa)  ( R4: 44444)  ( R8: 88888)  (R12: 03eb6)
    ( SP: 03fb6)  ( R5: 55555)  ( R9: 99999)  (R13: 0983f)
    ( SR: 000da)  ( R6: 66666)  (R10: 00000)  (R14: 00014)
    ( R3: 00000)  ( R7: 77777)  (R11: bbbbb)  (R15: 00001)
    061aa: 18 00                     MOVA    @PC+,    R8
    061ac: 5a 16                     POPM.A  #0x5,    R10
    061ae: 00 13                     RETI
    061b0: b1 c0 d0 00 00 00         BIC     #0xd0,   0x0(SP)
    061b6: bf 14                     PUSHM.A #0xb,    R15
    061b8: 40 18
(mspdebug)

The current version of the firmware is based on FreeRTOS with a proprietary Bluetoothstack under IAR. This has some severe disadvantages:

There are thoughts currently being discussed if other open source and low profile Bluetooth stack should be ported / used instead, like

The RAM constraints of the MSP430 are the biggest concerns here. Since the watch also has to keep track of some bitmap buffer for the 96x96 LCD (1152 bytes) and only 16kB being available, this can get pretty tight very fast.

For the time being there are two major obstacles in getting a really free firmware:

  1. According to the BTstack key developer the CC2560 needs a proprietary HCI init sequence which TI has not yet made publicly available. It is of course included in the proprietary stacks that come with the eval system etc. but is not available stand alone. Without that init script the module can not be used.
  2. The current mspgcc does not yet support code size larger than 64kbytes. This limitation is dues to the missing support for 20-bit addressing modes. But this is hopefully being worked upon, see this mspgcc mailinglist post.

Here is a nice tutorial on how to set-up the latest mspgcc with multi-arch support: https://github.com/sergiocampama/Launchpad/blob/master/README.md

Known Problems

Watch shows display errors, stripes or display stays blank

It seems that the firmware can get into a pretty hosed state where even a reset, be it hardware or software, does not recover anymore. But rest assured, your watch is not broken!

The MSP430 can be pretty low power, very low power. And some parts of it are static as long as power is supplied. It seems that this error toggles something in a static area that is even kept over reset. But it can be cleared by cutting power - for a long time!

To cut power you have to open the watch - unfortunaletly. But it is not that nasty as it may seem. Removing the battery is not that easy. Best way is to carefully remove the display frame and display. Then you can access the lower battery contacts which you can then isolate using e.g. think plastic straps. After that wait for at least three hours or more - best let it sit over night.

The clip is not recognised as USB device

Some clips seem to have issues with the USB interface - ranging from not being detected at all to being detected sometimes. According to my info you can not change that, except by exchanging the clip. On Linux after plugging in the clip you should see something like this in your dmesg: 

[218084.712080] usb 3-2: new full speed USB device using uhci_hcd and address 62
[218084.925437] cdc_acm 3-2:1.0: This device cannot do calls on its own. It is not a modem.
[218084.925451] cdc_acm 3-2:1.0: No union descriptor, testing for castrated device
[218084.925505] cdc_acm 3-2:1.0: ttyACM0: USB ACM device
[218091.414002] generic-usb 0003:0451:F432.0017: hiddev0,hidraw1: USB HID v1.01 Device [Texas Instruments Texas Instruments MSP-FET430UIF] on usb-0000:00:1d.1-2/input1

Fossil and TI have analysed that issue and it seems that a software update on the clip can cure that issue. The update though has to be done directly on the hardware and can not be done over USB. So most likely the clip needs to be returned.

RFCOMM communication is super slow / shows high latency

Up to watch firmware V0.7.15 there is an issue at least with connecting to Linux BlueZ with enabled SNIFF mode. Once the watch has entered sniff mode the first time it will not exit sniff again causing high latency on any transfer. This can be avoided by disabling sniff mode in the link policy settings on the Linux host, as root-user: 

# hciconfig -a hci0
hci0:   Type: USB
        BD Address: 00:19:7E:F7:CD:98 ACL MTU: 1017:8 SCO MTU: 64:8
        UP RUNNING PSCAN
        RX bytes:953 acl:0 sco:0 events:26 errors:0
        TX bytes:358 acl:0 sco:0 commands:26 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
---snip---

You can see the "Link policy" as "RSWITCH HOLD SNIFF PARK". You can disable sniff by setting new link policies like this: 

# hciconfig hci0 lp RSWITCH,HOLD,PARK

Disabling sniff mode has the disadvantage of higher power consumption on both ends, the watch and the Linux host, with the watch being the more critical party.

© 2011 by Nils Faerber