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:
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 🙂
Now I can use the data on the Hexiwear over BLE with the gatttool (see “Tutorial: Hexiwear Bluetooth Low Energy Packet Sniffing with Wireshark” and “Tutorial: BLE Pairing the Raspberry Pi 3 Model B with Hexiwear“). This article is taking things a step further and uses a Python script on Linux to access the sensor data on the BLE device:
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.
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:
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?
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.
The year is coming to an end, the Holiday season is approaching. In case you are looking for a nice present: I have completed my version of a sand clock: a clock writing the time into sand:
If you are interested to build your own version, I have documented the different steps with tips and tricks…
The good thing with failure is: it is an opportunity to learn :-).
So here is a case: For a STEM roadshow (see “MINTomat: World’s Most Complicated Bubble Gum Automata?“), we have produced in a rush an autonomous robot with a shiny printed 3D cover:
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.
In my previous article (see “Tutorial: First Steps with NXP i.MX7 and Toradex Colibri Board“) I have booted the i.MX7 on a Toradex CPU module. In this post I’m showing how to run a FreeRTOS application on that board.
Recently I have been running into the following error message in Eclipse when I started the GDB debugger:
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.
In my first post about Segger Ozone (see “First Steps with Ozone and the Segger J-Link Trace Pro“) I missed the fact that it includes support for kernels like FreeRTOS. So here is how to show the FreeRTOS (or any other RTOS) threads with Ozone:
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 🙂
In “ARM Cortex-M, Interrupts and FreeRTOS: Part 1” I started with the ARM Cortex-M interrupt system. Because the ARM implementation cann be very confusing, I confused myself and had to fix and extend the description in Part 1 :-). Thank for all the feedback and comments!
Originally I wanted to cover FreeRTOS in Part 2. Based on the questions and discussions in Part 1 I thought it might be a good idea to provide visual examples.