For a CubeSat project we only have a single board available. But multiple universities and developers need to have access to that board for developing and debugging the firmware. We cannot easily ship around the board: that takes a lot of time and during shipment nobody can use the board.
There is a nice feature in the Segger J-Link software which allows to share the debug connection over the network: the J-Link Remote Server. It even works nicely between different networks without complicated firewall setup:
When working and debugging a bootloader, debugging can be a challenge: During debugging the bootloader, a new binary gets loaded into the microcontroller address space which is unknown to the debugger. As soon as I step into the newly loaded binary, I only see assembly code, with that ugly “No source available” in Eclipse:
No Source Available, debugging in assembly
But wait: GDB is able to do pretty much everything you can imagine, so here is how to debug multiple binaries with GDB and Eclipse, and to turn the above into something which is easy to debug:
The Hexiwear docking station would have a nice feature: it has embedded a debug circuit (OpenSDA). That way I would not need an external debug probe to debug the Hexiwear. However, a debug probe is required to reprogram the docking station itself:
Repgrogramming the Mikroelektronika Docking Station
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 🙂
The Achilles Heel of the Mikroelektronika Hexiwear is its charging: the charging and USB connector are only designed for a limited number of plug-unplug cycles, and it does not have a wireless charging capability like the Apple iWatch. Until now! I have built a DIY wireless charging system for the Hexiwear 🙂 :
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.
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…
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
It seems to me that not many developers use hardware trace? ARM indicates that maybe only <5% of developers are using trace. Too bad! Why are all the ARM Cortex microcontroller vendors putting a powerful hardware (and complicated!) trace engine into their devices, if only few developers are using it? Seems like a waste of silicon and an unnecessary price adder? Well, hardware trace can be a life saver: Because only with hardware trace the most complicated bugs and problems can be solved. And maybe because only the best are using it ;-).
With the GNU compiler and linker I can place variables into custom sections (see “Defining Variables at Absolute Addresses with gcc“). This article is about how to get the section start and end address so I can for example access that range in my code. Or in general ways: how to use symbols defined in the linker script accessible in the C source code.
My Toradex i.MX7Dual module comes with a preflashed Linux distribution (see “Tutorial: First Steps with NXP i.MX7 and Toradex Colibri Board“). As with any other things, Linux gets updated from time to time, and Toradex publishes new firmware. In this article I’m documenting how I can update Linux in the external FLASH on that module.
As a standard procedure, I add some console functionality to my embedded applications. That way I have a command line interface and can inspect and influence the target system. One interesting hardware feature of ARM Cortex-M is Single Wire Output (SWO): it allows to send out data (e.g. strings) over up to 32 different stimulus ports, over a single wire.
Playing with RFID and NFC is definitely fun :-), and they are everywhere! For a research project I’m exploring different RFID tags and solutions. I several types around for a long time, but never found the time to actually work on it, so last nightI thought I give it a try, and I have it working with GNU ARM and Eclipse, powered by the NXP FRDM-K64F board 🙂