Looking for a small, inexpensive ($25-30) ARM development board (say 120-180 MHz ARM Cortex-M4 with FPU, 512kB-1MB of FLASH and 256 KByte of RAM? Then have a look at the Teensy 3.5 and Teensy 3.6 by PJRC/Paul Stoffregen:
Teensy 3.5 with NXP K64F ARM Cortex-M4F
The only problem? it is not possible to debug it :-(. At least not in the traditional sense. This article is about how to change the board to use it with any normal SWD debugging tool e.g. Eclipse and the Segger J-Link :-).
One of the most important aspects of the ‘IoT’ world is having a secure communication. Running MQTT on lwip (see “MQTT with lwip and NXP FRDM-K64F Board“) is no exception. Despite of the popularity of MQTT and lwip, I have not been able to find an example using a secure TLS connection over raw/native lwip TCP :-(. Could it be that such an example exists, and I have not found it? Or that someone implemented it, but has not published it? Only what I have found on the internet are many others asking for the same kind of thing “running MQTT on lwip with TLS”, but there was no answer? So I have to answer my question, which seems to be a good thing anyway: I can learn new things the hard way :-).
Block diagram MQTT Application with TLS using lwip
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.
The concept of Linux (Open Source, broad developer base and broad usage) is a success story. While there is a lot of diversity (and freedom) in the Linux world, Linux is Linux and again Linux :-). And the world has (mostly) standardized on Linux and its variants on the high embedded system side.
“The Linux Foundation Announces Project to Build Real-Time Operating System for Internet of Things Devices. Open source Zephyr™ Project aims to deliver an RTOS; opens call for developers to help advance project for the smallest footprint IoT devices.“
Ζεφυρος (Zephyros) is the Greek good of spring and the west wind. Obviously this inspired the logo for the Zephyr project:
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
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 🙂
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.
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:
Percepio Trace V3.1 for FreeRTOS which includes both Segger RTT continuous streaming and snapshot tracing in a single API
Generation of sources and drivers so they can be used without Processor Expert using McuLibConfig, removal of dependency to NXP Kinetis SDK: components use a generic API approach to have them working with other SDKs.
New contributed ExceptionsHandler component
Callback Setter and Getter in USB CDC stack for simpler option handling
GenericTimeDate with flexible RTC support and added Unix Timestamp functions
LongKey events in Key component
FreeRTOS with optimized task selection on Cortex-M4/M7
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
For many of my applications I need to measure a distance. I have used ultrasonic sensors, but there view angle (beam) is not able to detect smaller objects, it very much depends on the object surface and angle, it is slow and not very precise. I have used infrared sensors, but here again it depends on the infrared reflection of the object in range, it depends the amount of reflected light is not really telling much about the distance, and yet IR reflection is subject of material and object targeted.
But there is yet another sensor type to consider: ToF! ToF (or Time-of-Flight) sensors have a built-in LIDAR: The sensor is sending out light pulses and measures how much time it takes for the light to come back. Similar to ultrasonic sensors (see “Tutorial: Ultrasonic Ranging with the Freedom Board“), but instead of ultrasonic it uses an infrared laser light. Or think about a radar system using an infrared laser light.
Vl6180x Breakout Board with tinyK20 (NXP Kinetis K20) Microcontroller-board
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 ;-).
Command line tools to build applications are great. But productivity goes up if I can use the standard Eclipse environment with GNU tools. This tutorial is about how to use standard and free GNU and Eclipse tools to build my FreeRTOS application for the ARM Cortex-M4 on i.MX7 🙂 :
Eclipse used to build FreeRTOS applications for M4 on i.MX7
I’m using in several projects different variants of Raspberry Pi boards: they are great and providing a lot of processing power. However, they are not suitable for any hard realtime systems. For a different class of projects I’m currently evaluating the NXP i.MX7 processors: the cool thing with these is that they have up to two ARM Cortex-A7 running at 1 GHz, plus a Cortex-M4 running at 200 MHz. And here things get really interesting: I can run a realtime application and FreeRTOS on that M4, while running Linux on the A7 :-).