Good news for everyone using Eclipse, FreeRTOS and Percepio Tracealyzer: Percepio has released an Eclipse plugin which makes snapshot tracing very easy and convenient using the a GNU gdb debugger in Eclipse like Kinetis Design Studio:
An interesting trend in the industry are SOM (System on Module): a high performance processor typically running Linux, Windows or Android with all the memory and necessary power logic gets put on a small module. The key benefit is that I don’t need to worry about the complex ball grid routing and the DDR memory connections/lines: all these problems are solved on a small module which then I can use in my design. It seems that NXP i.MX application processors are getting popular in this domain, and after looking at the Toradex Colibri modules, I have an i.MX6 module on my desk from e-con Systems:
P&E has a new version of their GDB/Eclipse debug plugins available on their Eclipse update site, and it comes with to great features: Real Time Expressions (show variables while target is running) and FreeRTOS thread awareness 🙂
Some ARM Cortex-M have a DWT (Data Watchpoint and Trace) unit implemented, and it has a nice feature in that unit which counts the execution cycles. The DWT is usually implemented on most Cortex-M3, M4 and M7 devices, including e.g. the NXP Kinetis or LPC devices.
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:
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.
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 🙂 :
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…
For a research project we are using Hexiwear to measure the effectiveness of teaching and learning. The Hexiwear is used as a networking sensor device in that project. For that project we needed a docking station with wireless capabilities:
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 ;-).