Completing the build

Last tests of thumbmouse were made using the board as a breakout for the sensor: the BLE module was not soldered and I connected the PCB via flying wires to an external Nucleo board (as you can see in last post's video). 

After this test, the next step was to solder the BLE module. This was quite a difficult thing since the BLE module has the pads only at the bottom and not to the sides. Also, this thing is damn TINY. I think for this module it would have been better to use solder paste and a stencil but I didn't want to spend too much for this board at this point.

So, I soldered the BLE module using the iron and I started getting bridges below which were really difficult to correct. Eventually I accepted that I had to use hot air to try to remove it. This took me long time since the module sucked a lot of heat. Eventually I managed to remove it but I ripped a pad of my PCB in the process. So, know I needed to populate the tiny PCB for the third time! Also, I didn't know if I cooked the module in the process or not.

First tests

After soldering the third board (this time it went much better and faster, at least it was good practice), I tried to do a little test with Zephyr RTOS (which I never used before, as I'm used to NuttX). It took me some time to adapt a similar board based also on NRF51822 but eventually I managed to control the LED. However, it was a blink example and the LED would not turn off. I started debugging and found that the board hung when going to sleep between LED turning on and off. This was really strange and after many hours of debugging, since I didn't know for sure this wasn't due to the module being ruined by the heat, I managed to get a blinky test using platformio, which uses the mBed framework. Surpisingly, the LED blinked. Debugging the code, I could see that it used the same RTC1 peripheral to control the sleep(). So, something must be wrong on Zephyr. This led to another set of long debugging hours, e-mailing Zephyr devs, opening an issue, etc. Then, for some reason I remembered seeing some errata documents from Nordic and decided to check if there wasn't actually a bug in the silicon which affected this module (but not other more popular ones which were working on Zephyr). To my surprise, there was indeed a BIG bug, whereas if you didn't set some magic value to some magic address NO PERIPHERALS WOULD TURN ON. I went back to mBed code and indeed this magic code was there. So, I transplanted the code to Zephyr and finally the damn LED blinked!

The bad thing is that even now that this was working, no Bluetooth examples seemed to work (I can't see the advertisements on my phone). Again, I'm sure it is not a hardware failure since the original firmware from Nordic is working and I can see it from my phone. So, I'm guessing there are other bugs affecting this chip or at least Zephyr has some problem with this model. Since I don't really understand much about low-level Bluetooth radio handling, I feel this is a bit out of my reach now. Moreover, I'm starting to feel that it was not a good choice to use this module (considering also the 16KB of SRAM it has).

What now?

So, unless Zephyr devs manage to point me in the right direction for this bug, I think I will most likely have to focus on a second revision of the hardware (which I already started to use the other trackpad series, include battery charging IC, regulator, etc), but this time using a newer module, based on NRF52 series and with easy to solder leads.

However, I would need some help funding this second revision so if you're interested in making this happen, you can help by donating here: https://ko-fi.com/protobits