In “Flash-Resident USB-HID Bootloader with the NXP Kinetis K22 Microcontroller” I presented how I’m using the tinyK22 (or FRDM-K22F) with a flash resident USB HID bootloader. To make sure that the loaded application is not corrupted somehow, it is important to verify it with a Cyclic redundancy Checksum (CRC). The NXP KBOOT Bootloader can verify such a CRC, but how to generate one and how to use it is not really obvious (at least to me), so this article explains how to generate that CRC.
The Teensy boards are great, but as they are they are not really useful for real development, as they lack proper SWD debugging. In “Modifying the Teensy 3.5 and 3.6 for ARM SWD Debugging” I have found a way to get SWD debugging working, at that time with Kinetis Design Studio and the Segger J-Link. This article is about how debug the Teensy with free MCUXpresso IDE and the $20 NXP LPC-Link2 debug probe:
I have used E-Ink displays in projects three years ago, but from that time the technology has greatly evolved. That time displays were hard to get, expensive and difficult to use. Now things seem to change with e-ink displays available to the maker market :-). I’m able to get a 128×296 pixel e-paper display for $10! And for little more money I can have displays with black/white/red colors!
I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge. In this release more ARM Cortex devices/vendors are supported with different SDKs, plus it comes with several FreeRTOS enhancements for debugging highly optimized code.
For several projects I’m using library projects: I build a library and then use that library in the other project. If I change something in a library, I want to run make both on the referenced libraries and rebuild my application if needed. If you don’t know how to do this, then read on… 🙂
(… actually it means workign around known Eclipse CDT bug too….)
ARM Cortex-M microcontrollers can have multiple memory controllers. This is a good thing as it allows the hardware to do multiple parallel memory read/writes. However this makes the memory map more complicated for the software: it divides the memory into different regions and memory segments. This article is about how to enable FreeRTOS to use multiple memory blocks for a virtual combined memory heap:
Many of the NXP OpenSDA boot loaders are vulnerable to Windows 8.x or Windows 10: write accesses of Windows can confuse the factory bootloader and make the debug firmware and bootloader useless. In this post I show how to recover the bootloader using MCUXpresso IDE and the P&E Universal Multilink.
The tools and IDE market is constantly changing. Not only there is every year at least one new major Eclipse IDE release, the commercial tool chain and IDE vendors are constantly changing the environment too. For any ARM Cortex-M development, the combination of Eclipse with the GNU tool chain provided by ARM Inc. is the golden standard. But this does not mean that things can be easily moved from one IDE package to another.
While moving between Eclipse versions and GNU versions is usually not a big deal at all, moving between the Eclipse build tool integration is usually not simple. While the GNU MCU Eclipse plugins are widely used (see Breathing with Oxygen: DIY ARM Cortex-M C/C++ IDE and Toolchain with Eclipse Oxygen), the Eclipse based IDEs from the silicon vendors or commercial Eclipse toolchain vendors are using their own GNU toolchain integration. Which means the project files are not compatible :-(.
Eclipse is probably the most used and de-facto standard IDE for any development for ARM Cortex or any other devices. It is very easy these days to construct an unlimited and unrestricted IDE (see “Breathing with Oxygen: DIY ARM Cortex-M C/C++ IDE and Toolchain with Eclipse Oxygen“). Up to the point that I can pack it into a .zip file and pass it around e.g. in a class room environment, so no installer at all is needed with the exception of the debug probe USB drivers. As Eclipse is using a Java Virtual Machine (VM), it is a good idea to bundle the VM with the IDE, and this article is about how to do this.
Eclipse as IDE takes care about compiling and building all my source files. But in an automated build system I would like to build it from the command line too. While using make files (see “Tutorial: Makefile Projects with Eclipse“) is an option, there is another easy way to build Eclipse projects from the command line:
Last month (June 2017), the latest version of Eclipse “Oxygen” has been released, and I have successfully used it in several embedded projects. Time to write a tutorial how to use it to build a custom Do-It-Yourself IDE for ARM Cortex-M development: simple, easy, unlimited and free of charge. While the DIY approach takes a few minutes more to install, it has the advantage that I have full control and I actually know what I have.
The benefit of an IDE like Eclipse is: it makes working with projects very easy, as generates make files and it takes and automatically manages the make file(s). But sometimes this might not be what I want because I need greater flexibility and control, or I want to use the same make files for my continues integration and automated testing system. In that case a hand crafted make file is the way to go.
One thing does not exclude the other: This article explains how to use make files with Eclipse with similar comfort as the managed build system in Eclipse, but with the unlimited power of make files:
NXP has released an updated of their Eclipse based IDE for ARM Cortex-M (Kinetis and LPC) microcontroller: the version v10.0.2 build 411:
A bootloader on a microcontroller is a very useful thing. It allows me to update the firmware in the field if necessary. There are many ways to use and make a bootloader (see “Serial Bootloader for the Freedom Board with Processor Expert“). But such a bootloader needs some space in FLASH, plus it needs to be programmed first on a blank device, so a JTAG programmer is needed. That’s why vendors have started including a ROM bootloader into their devices: the microcontroller comes out of the factory with a bootloader in FLASH. So instead writing my bootloader, I can use the one in the ROM.
And as with everything, there are pros and cons of that approach.
I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge, with the following major changes and updates:
- Complete refactoring for 1-Wire stack and DS18B20 temperature sensor components
- Added HID Joystick device class to the FSL_USB_Stack
- New SDK_Timer component to work with Kinetis SDK
- New ST756P LCD driver component
- New TSL2561 digitial temperature sensor driver
- Added ReadByte() and WriteByte() GenericI2C functions
- Added 64bit mapping functions to Utility
- added configUSE_NEWLIB_REENTRANT and newlib reentrancy support to FreeRTOS
- Pull resistor support for SDK_BitIO
- Many smaller bug fixes and enhancements
For reliable applications, I avoid using functions of the standard libraries. They are banned for most safety related applications anyway. I do not use or avoid
printf() and all the other variants, for many reasons including the ones listed in “Why I don’t like printf()“. Instead, I’m using smaller variants (see “XFormat“). Or I’m using only the thread-safe FreeRTOS heap memory allocation which exist for many good reasons.
Things get problematic if
malloc() still is pulled in, either because it is used by a middleware (e.g. TCP/IP stack) or if using C++. Dave Nadler posted a detailed article (http://www.nadler.com/embedded/newlibAndFreeRTOS.html) about how to use newlib and newlib-nano with FreeRTOS.
For a research project, we are going to send a satellite with an embedded ARM Cortex microcontroller into space early next year. Naturally, it has to work the first time. As part of all the ESA paperwork, we have to prove that we tested the hardware and software thoroughly. One pice of the that is to collect and give test coverage evidence. And there is no need for expensive tools: Free-of-charge Eclipse and GNU tools can do the job for a space mission 🙂
The GNU tools include powerful utilities to collect coverage information. With coverage I know which lines of my code have been executed, which is a very useful test metric. The GNU coverage tools are commonly used for Linux applications. But to my surprise not much for embedded application development, mostly because it requires a few extra steps to have it available? Why not using free and powerful tools for improving software quality? This article explains how to install the GNU gcov tools into the Eclipse IDE.