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:
Three years ago I published “Debugging Failure: Check List and Hints” and unfortunately this article is one of the most popular ones: obviously debugging problems are very common. Debugging with GDB works usually fine, but if things are failing, then it can be hard to find the cause for it. Recently I have been asked to check some failures, so here are two more hints about what could go wrong…
Error while launching command: arm-none-eabi-gdb –version
Binary files are just a binary blob without debug information. Most debug tools and flashers are able to deal (raw) binary (see “S-Record, Intel Hex and Binary Files“). But GDB or the P&E GDB server really needs a ELF/Dwarf file which usually has all the debug information in it. This is a problem if all what I have is a binary file.
This post is about transforming a raw binary (.bin) file into an ELF/Dwarf file with adding a header to it:
I’m making great progress with the firmware for the new Mini Sumo Robot (see “New Concept for 2018 Mini Sumo Roboter“). The goal is a versatile and low-cost Mini Sumo robot, and the robot comes with the feature of magnetic position encoders. In a previous article I have explained how to mold custom tires for robots (see “Making Perfect Sticky DIY Sumo Robot Tires“), this article is about how to make DIY Magnetic disk encoders.
With the hiking trails covered with as much as 50-60 cm snow, the natural way to hike the trails is using snowshoes. Two days ago an extra 10-15 cm snow arrived, and the trails are just amazing. Here are a few impressions from the snowshoe hike today:
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:
Sumo robot challenges are fun. One important aspect of every Sumo robot are the tires: if they are sticky enough, the robot can push out the opponent. In this article I compare different available robot hubs and tires, and how to make DIY hubs and tires.
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.
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:
“Amazon FreeRTOS – IoT operating system for microcontrollers”: The announcement of FreeRTOS V10.0.0 was one of the biggest news last week for me. Not only is there now a Version 10, the bigger news is that FreeRTOS is now part of Amazon. Wow! Now this explains why Richard Barry (the founder behind FreeRTOS) was kind of hiding away for about a year: he joined Amazon as a principal engineer about a year ago. I think we all have to wait and see what it means for FreeRTOS.
The NXP Freedom boards are very popular. Many of them are inexpensive (less than $20), include a debug interface and can be easily extended with extra shields or boards. Especially the FRDM-KL25Z is very popular: I’m getting told because of Processor Expert and tutorials available on web sites like this one ;-).
Unfortunately there are no small or breadboard friendly Kinetis boards available. There is the NXP LPC800-DIP but with no onboard debugger and without Processor Expert support. We have the tinyK20, but projects tend to use more CPU power, FLASH and RAM space than what the tinyK20 board (50 MHz, 128 KByte FLASH, 16 KByte RAM) can provide. So we ended up designing the big brother of the first tinyK20: the tinyK22 with 120 MHz, 512 KByte of FLASH and 128 KByte of RAM.
Back in March 2017, NXP had rolled the MCUXpresso IDE starting with Version 10.0.0. With the intent to unify the SDK, LPCXpresso, CodeWarrior, Kinetis Design Studio and Processor Expert into one unified and integrated set of tools. V10.0.0 was a good start. The MCUXpresso IDE V10.0.2 in July was more of a smaller update, and the Pin and Clock configuration tools were not integrated, no added tool for peripheral configuration.
A week ago the MCUXpresso V10.1.0 has been released which shows where the journey is going: an free-of-charge and code size unlimited Eclipse based integrated set of tools to configure, build and debug Cortex-M (Kinetis, LPC and i.MX RT) microcontroller/processor based applications.
Clock Tool inside MCUXpresso IDE
I have used it for a week, and although many things are still new, I thought I’m able to give an overview about what is new.
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?
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!