I’m dealing a lot with bootloaders recently (see “Flash-Resident USB-HID Bootloader with the NXP Kinetis K22 Microcontroller“), and bootloaders are sometimes very picky about what file format they are able to consume. So what if I have a binary (see “S-Record, Intel Hex and Binary Files“) file and I need to convert it into the Intel Hex format?
converted binary to intel hex
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.
CRC Values for KBOOT
One of the great things with the FreeRTOS operating system is that it comes with free performance analysis: It shows me how much time is spent in each task. Best of all: it shows it in a graphical way inside Eclipse too:
FreeRTOS Runtime Information in Eclipse
To solve the real hard problem of Embedded Systems development, I usually need all the data I can get from the target. The Percepio Tracealizer is such a tool which can stream application and FreeRTOS trace from the target over a Segger J-Link connection using the Segger RTT protocol. I’m using that combination a lot.
Streaming trace data that way does not need a dedicated hardware like ETM Trace. Using RTT is usually not much intrusive and affects the performance of the target in the 1-2% range (of course depending on the amount of data).
But what worried me for several weeks is that after moving to FreeRTOS V10.0.0 and the same time updating the Segger libraries, the target performance was heavily affected:
RTT streaming affects target performance?
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:
Teensy 3.6 with NXP LPC-Link2
I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge., which is supposed to be the last release for 2017 :-). This release features several smaller bug fixes, the new FreeRTOS V10.0.0 and extended device support.
SourceForge
Doing Mini Sumo robot competition is really fun, and there is yet another one coming to end the current university semester. For several years we have used our own sumo robot, and this is the one used in the course this year too. But for future and extended events we are exploring a new robot. I proudly present the concept of the next generation sumo robot for the year 2018:
Sumo Robot with Bluetooth module
In “Eclipse MCUXpresso IDE 10.1 with integrated MCUXpresso Configuration Tools” I mentioned that I wanted to try the i.MX RT1050 processor. Well, finally my ordered board from Mouser arrived, right on time for the week-end, so I had a chance to use that ARM Cortex-M7 running at 600 MHz :-).
i.MX RT1050 EVK
I’m using many microcontroller in my projects. And a lot more are available out there in the ecosystem. Like many others, I tend to select what I am familiar with. But is this the correct approach to select the hardware and tools for a next project?
Microcontroller Boards
I have been running recently into an interesting case where the GNU ARM Linker failed to link an application with strange error messages:
referenced in section, defined in discarded section
MCU on Eclipse 