To me, one of the most frustrating things working with ARM Cortex-M cores are the hard fault exceptions. I have lost several hours this week debugging and tracking an instance of a hard fault on an ARM Cortex-M0+ device.
In “Low Power LCD: Adafruit Breakout Board with Sharp Memory Display” I used a 96×96 Sharp Display (LS013B4DN04) with the Adafruit breakout board, but because that one seems to be EOL (End Of Life), I searched for a replacement. I have found the 128×128 pixel version (Sharp LS013B7DH03), and best of all, it is pin compatible :-). With a small tweak of the driver, it works :-):
Sharp Memory Display 128×128
One of the biggest road blocks (beside of closed source) using the BLE (Bluetooth Low Energy) stack from NXP is that it requires expensive tools to compile and build the stack. The good news is that I have now the NXP BLE stack for the Mikroelektronika Hexiwear ported to Eclipse and GNU gcc build tools for ARM 🙂
NXP BLE Stack in Eclipse
This is yet another milestone on my journey to combine the Hexiwear with the Raspberry Pi: now I can send take over control of the Hexiwear with openHAB running on the Raspberry Pi:
Controlling Hexiwear with openHAB
For a university reasearch project I try to pair the Raspberry Pi 3 with a Mikroelektronika Hexiwear using BLE (Bluetooth Low Energy). Most of things worked after a lot of trial and error, but at a certain point I was stuck trying to write to send data from the Raspy to the BLE device.The Hexiwear BLE protocol description is very thin, so I ended up using a BLE sniffer to reverse engineer the protocol with Wireshark.
Hardware setup between Raspy and Hexiwear
I’m using the NXP FRDM-K64F board in several projects: it is reasonably prices, has USB, Ethernet, micro SD card socket and connectors for Bluetooth classic and Nordic Semiconductor nRF24L01+ 2.4 GHz transceiver:
NXP FRDM-K64F Board
But one issue I have faced several times is that the board works fine while debugging and connected and powered by a host machine, but does not startup sometimes if powered by a battery or started without a debugger attached. I have found that the EzPort on the microcontroller is causing startup issues.
The Hexiwear (see “Hexiwear: Teardown of the Hackable ‘Do-Anything’ Device“) is a small and portable sensor node with built-in BLE (Bluetooth Low Energy) transceiver. In a research project we try to use multiple Hexiwear in a classroom environment and to collect sensor data on a Raspberry Pi. The Raspberry Pi 3 Model B running Linux has an on-board BLE transceiver too, so why not binding them (wirelessly) together?
Raspberry Pi 3 connected with Hexiwear over BLE
Well, things seemed easy at the beginning, and as always, there are many things to learn on a journey like this…
Time is passing by so fast, and the year end is approache fast! I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge:
SourceForge
The Hexiwear device is a great and versatile device with two microcontrollers on it. Developing firmware on a Hexiwear means changing what was originally on it. And sometimes it happens that I’m not sure if the changes are for good. Or that I accidentally destroyed the firmware on the NXP Kinetis KW40 BLE microcontroller :-(. So I had to find a way to restore the original firmware, and this is what this post is about.
Restoring the Hexiwear Firmware with a Segger J-Link
MCU on Eclipse 