MSP430 programmer

[VanLaser]

Hi, and - thanks for doing this! a non-programmable Topre keyboard is a blasphemy, no more, no less :) 👍

Could you tell me if I can flash the keyboard using this device: https://www.aliexpress.com/item/Advanced-MSP430-BSL-USB-programmer-download-Adapter-USB-Port/32671993072.html ? (or, perhaps, point me to another source) Thanks!

[vekkt0r]

Hi! At least they were friendly enough to leave the code protection off so we could have a look around in the firmware ;-)

I think the default BSL on the Novatouch (MSP430F5510) only supports programming via USB [1]. The programmer you linked to probably uses I2C / SPI / UART although the information was kind of sparse.

Was just thinking that it should be possible to enter BSL bootloader by performing the BSL entry sequence (connect VBUS to PUR) and flash firmware directly via the computer instead. PUR pin is a bit inaccessible though but it would be very neat if it worked, then we would need no external programmer. See [2] for some more pinouts.

Another alternative is to buy a Texas LaunchPad which I think is the cheapest way of getting a Spy-Bi-Wire programmer. This is what I used.

1: http://www.ti.com/lit/ug/slau319l/slau319l.pdf
2: http://vekkt0r.github.io/images/novatouch_pinout.png

[VanLaser]

Thanks for answering :)

I'm afraid I'm not much of a "hardware" guy; the best I could do was to restore an old IBM Model F Bigfoot, or to solder my own Cherry MX switches on custom keyboard PCBs, but that was only by "following instructions". But, from your post, I understand that shorting VBUS and PUR should make for example Linux see a different device (than the "normal" keyboard), which can (somehow?) be flashed. Who's gonna test this? :D

[vekkt0r]

Exactly, should be possible to flash via the BSL boot loader already on the MSP processor.

I was planning to test this last weekend but forgot to bring home the keyboard from work.. Will try to remember next week. Hopefully the PUR pin is routed somewhere more accessible than the place listed in the pinout picture.

[manolkalinov]

Hi, vekkt0r. Another thanks for your work! I have both of your articles bookmarked and bought a Texas LaunchPad kit a while ago. Was waiting for the holidays, so I could take the keyboard home. If I could mod the firmware to natively use the Colemak layout, it would become the best keyboard I've ever owned :).

Like VanLaser, though, I not much of a "hardware" guy, so any help would be greatly appreciated: how exactly do you connect the LaunchPad to the keyboard? As far as I can see, the LaunchPad only has pins and the USB cable.

This is what I bought:

https://www.amazon.co.uk/MSP430G2XX-LAUNCHPAD-MSP-EXP430G2-TEXAS-INSTRUMENTS/dp/B01186Z126/ref=sr_1_3?ie=UTF8&qid=1483179827&sr=8-3&keywords=msp430

Do I need to get something in addition to the LaunchPad PCB? I'm at a loss as to whether some wires need to be soldered to the keyboard, or...?

[vekkt0r]

Hi manolkalinov, what I did was to solder a pin header to the debug connector on the keyboard (since I did not have any connector that would fit):

Then just connect to the Launchpad according to the ascii in the README file (or the image in the first post if that is easier to understand). Let me know if you need any more info on how to connect.

Some updates on the other flashing solution:
I finally got around to bring my keyboard home from work to check the PUR pin, seems like it's possible to get the MSP into bootstrap mode by tying to VBUS! Enumerated as MSP430 USB HID Bootstrap loader and I can somewhat communicate with the keyboard with python-msp430-tools.

The built in bootstrap loader (BSL) on the msp is very basic, so to perform read / write to flash we need to load a full-featured BSL to RAM and execute it from there. But after loading the full BSL there is some issue, won't accept any commands.. So I'm looking into that right now to see if I can get it working.

Was quite easy (although it would have helped having a third hand :-)) to get the keyboard into BSL mode though, no soldering required. Just connect a wire between VBUS on the USB connector and PUR pin (third pin from the corner) on the MSP and then plug in USB to the computer. After connecting to computer the wire can be disconnected., keyboard should enumerate with VID 0x2047 and PID 0x0200.

(sorry for the potato-pics, held the camera with one hand while holding the wire)

[vekkt0r]

Ok, RTFM I guess.. The reason for having problems with the second BSL was that device always gets password protected after programming, since the BSL password is the top 16 words in the interrupt table.

Will see if I can update the Makefiles with some examples using the python-msp430-tools for flashing.

The BSL password of my keyboard was:
ff ff ff ff ff ff 94 83 ff ff 9a a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 3a 98 ff ff a6 9c

It's a bit scary using the BSL though, if the wrong password is specified the MSP will erase itself... I guess I can always share my firmware file though so not impossible to recover (assuming there are no hardware differences / different revisions of the keyboard).

[VanLaser]

This is seriously cool :) I'm waiting for the "2nd method" Makefiles update (I assume that the code can check if the firmware is the right one and bail out early if not).

I also wander if there isn't some impossible key combination hidden there in the firmware, that automatically puts the keyboard in BSL mode ... that would be golden.

[manolkalinov]

@vekkt0r, many thanks for the information and your time! I cannot wait to try it in the next few days when I have a bit of time.

By the way, from what I can understand, the second flashing solution does not require a LaunchPad and the keyboard is directly connected via USB, correct?

[vekkt0r]

@VanLaser That is what I do in the current Makefile before applying patches, but the problem with BSL is that it won't even allow to read out the existing firmware without the correct password.

Did some digging around in the firmware to try to find any magic keys / ways of abusing the USB stack to jump to BSL but unfortunately did not manage to find anything :/ Would have been really awesome if we found something like that.

@manolkalinov You're correct, second flashing method works without LaunchPad, but as noted above might be a bit more risky if all keyboards do not have the same firmware.

What Model No. do you guys have on the backside of your keyboards? Mine is SGK-5000-GKCT1-US, S/N SGK-5000-GKCT1-US1143001174. Also, what version does the keyboard say it has when plugged into computer? (bcdDevice in lsusb -v output or Version field from the USB device in the OS X System Information)

[VanLaser]

Same model no. here: SGK-5000-GKCT1-US, with serial number a little higher than yours
(SGK-5000-GKCT1-US1150500086). Pity about the (missing) magic keys! :)

Snippet from lsusb -v:

Bus 001 Device 003: ID 2516:0027  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x2516 
  idProduct          0x0027 
  bcdDevice            0.01
  iManufacturer           1 CM Storm
  iProduct                2 Coolermaster Novatouch TKL
  iSerial                 0 
  bNumConfigurations      1

If everything is the same, I'd go for a try. Worst come to worst, I'll order a LaunchPad :D

[vekkt0r]

It's the exact same as for mine, so think we should be fine. Just saw that @NSHenry made a fork of this repo and tried it out on a newer keyboard than mine so at least used by two people now :-)

Just pushed some updates with infos on BSL flashing, let me know how it goes!

[VanLaser]

So, to describe my steps. First I figured out how to shorten those PUR & VCC pins (used a very thin, but not flimsy, wire). Done. Next, cloned this repo with git, ok, easy enough. Then (on my Arch Linux machine), I thought I could install all the required dependencies and run make -f Makefile.bsl flash from there. Big mistake! Not only python is now python2, msp430 toolchain has elf in its names allover, but also the python msp430 tools aren't compatible and throw errors (which I thought I could fix, etc.). Then, I noticed the Vagrantfile. Never worked with it, so I start digging ...

Half an hour later, I had VirtualBox and vagrant installed, machine rebooted, VBoxManage list usbhost correctly reporting usb devices available for filtering, the user was added to the vboxusers group, of course had to repeat the "short the pins" to put the keyboard in BSL mode; so everything was set.

$ cd novatoools
$ vagrant up
 [long process started here, basically downloading
 all needed files and creating the VM on the fly]
$ vagrant ssh
vagrant@vagrant-ubuntu-trusty-64$ lsusb
...
Bus 001 Device 002: ID 2047:0200 Texas Instruments MSP430 USB HID Bootstrap Loader
...
vagrant@vagrant-ubuntu-trusty-64$ cd novatools
vagrant@vagrant-ubuntu-trusty-64$ make -f Makefile.bsl clean
vagrant@vagrant-ubuntu-trusty-64$ make -f Makefile.bsl flash
Creating dummy hex file with supposed BSL password...
Reading Novatouch firmware to build/orig_fw.bin...
Download full BSL...
Create data section binary...
Patching data section...
Create isr vectors binary...
Create main.o...
Compiling shellcode...
Create main.elf...
Download full BSL...
Programming...
Programming: OK
vagrant@vagrant-ubuntu-trusty-64:~/novatools$ logout
Connection to 127.0.0.1 closed.

Re-connect the keyboard, quickly test some keys with xev, seems to work ... :D Hurrah! ;)

BTW, if you prefer, I can close the "issue" :) Thanks again for all the details. Now to read the code to see how I actually modify the keys for my taste.

One more (silly) question: if I re-enter BSL mode (with Fn + F1 + F4 this time), and reflash again with a different patch etc, is that password tweak still valid? (i.e. either it stays the same, or it's correctly recomputed). Hmm, I suppose the interrupt table doesn't change ...

[vekkt0r]

Great to hear it worked out for you!

You're correct, patching wont change the interrupt table to password should remain the same. Also, now that you have a copy of the original firmware you don't need the password anymore since it's only used when reading out firmware. When flashing it will just erase current firmware and then

I should really update the Makefile to copy out the original firmware file to a better place than the build folder though. Now it will be removed if running make clean which is maybe not so good..

[VanLaser]

First of all, let me thank you again for your work (I'm talking not only about this repo, but also your 'hacking' / disassembly work) ! At one point in the past, I did some hacking on Dynamix' great flight simulator "Red Baron 3D" - and the feeling of 'beating the bytes' was a great one :)

Do you happen to visit the Deskthority and/or Geekhack keyboard forums? There are some people there that created custom firmware for several keyboards (using Teensy 2.0 or Arduino Pro Micro etc. - for example, I run TMK firmware on my HHKB keyboard) - well, maybe your rev.eng. documentation (assuming it's complete) and their work could be combined for a completely customized, alternative Novatouch firmware, at some point in the future? (before that, how would I do to custom create FN+key combos?)

I also stumbled upon another Novatouch, Italian ISO layout this time (bought it, since it was relatively cheap) - so it seems I'll have to buy that Launchpad after all.

[vekkt0r]

It's a very fun hobby, knowing you can make stuff work the way you want even on products that aren't 'open' :-)

I do lurk there sometimes, but I also try to keep away to not get any ideas of buying new keyboards and keysets I do not need ;-) Actually had a quick look at the TMK firmware when I was doing the Novatouch reversing but ended up patching the original fw instead because it felt like less effort. Would probably be possible to get TMK running on the Novatouch with the information from my posts, will of course try to provide any missing info if someone needs it. Maybe I will take a look in the distant future when I get bored.

You want to use FN + key to send another key? Should be possible with a hook similar to the BSL entry one I think, will see if I can find the address of the function that queues keys for sending to the PC in my old IDA project. Or maybe we can do it directly by addings stuff to the existing keycode tables, need to have a look.

Probably good to stock up on some extra Novatouches now that they are out of production ;-)

[VanLaser]

Ah yes, the keyset-buying temptation can be quite like a "vertigo"! Of course, you could "constrain" yourself to visit only the "Workshop" sub-forum @ Deskthority :)

Would be nice to have a way to easily setup codes for custom FN+key combos. Of course, a "new" (i.e. open) firmware would be probably better (but hard to make, I know) - it would make it easier to further support other key mapping features, such as: dual role keys (example: press and release caps lock -> esc, press caps lock and another key -> Ctrl-key), macros or - as I saw in a comment to your blog post, configuring extra added HW features (e.g. to support Bluetooth).

Regarding TMK, the author (Hasu) mentions that it would need (at least) extending ChibiOS's USB driver support to include MSP430's architecture: https://geekhack.org/index.php?topic=71517.msg2345201#msg2345201

[vekkt0r]

Started working on FN+key combos, have a hack in place which I need to test when I have access to the keyboard. Unfortunately it was not possible to adjust the existing tables and get this feature. Should be doable by injecting another hook function though. For more advanced stuff it's probably better to start working on TMK porting instead.

Yeah seems like there is already some support for MSP430 in ChibiOS! Texas Instruments provides some reference code for USB HID device, not sure how easy it is to properly add that code to ChibiOS though (and if there are any licensing issues). The reference code from TI is also what CM is using in the original fw (are some string references to "USB_DEVELOPERS_PACKAGE_3_20_00".

[VanLaser]

Cool! :) One one hand, if enough functionality can be injected (easily, from a user's point of view) in the current firmware, then I guess all is fine and dandy :) OTOH, I don't see a problem with the license, even in the worst case, as long as one either keeps things private or in a close circle, or makes a patch and some distribution notes in which it's described how to combine ChibiOS and the TI USB reference code (using the patch) at the user's side.