I’m pleased to announce a new release of the McuOnEclipse components, available on SourceForge. This release includes several bug fixes, extra support for the NXP S32 Design Studio and SDK and includes FreeRTOS V10.1.1.
Not ready for the complexity of a full blown Embedded Linux, but need that extra compute performance? Need an ARM Cortex-M7 running at 600 MHz module on a half-sized business card, ready to be integrated? Here we go: the Embedded Artists i.MX RT1052 OEM module:
Compute modules are very common in the Embedded Linux space, for example see this Toradex module. The reason is simple: these high-performance boards simplify the design, as I don’t have to care about the BGA packages and the external SDRAM and FLASH devices: everything is on a module I can easily integrate into my base board.
My usual workflow is: edit – build – debug and repeat. And this for the same project again and again. So here are a few tips how to make these iterations faster with Eclipse. One thing is to use the F11 shortcut to debug the last launched/debugged application:
The McuOnEclipse GitHub repository hosts many Processor Expert projects and is very popular (cloned more than 1000 times, thank you!). Processor Expert is a powerful framework which generates driver and configuration code, simplifying application development for a wide range of microcontroller and families. But Processor Expert won’t be developed further by NXP and is not part of MCUXpresso IDE. While it is possible to install Processor Expert into MCUXpresso IDE 10.2, how can these projects used ini an IDE *without* Processor Expert? This article describes how to port an existing Processor Expert project into the NXP MCUXpresso IDE.
It is never too early to start thinking about Halloween projects :-).
When I ordered originally the MIMXRT1050-EVK from Mouser, it was without the LCD display (see “MCUXpresso IDE V10.1.0 with i.MX RT1052 Crossover Processor“. I ordered the LCD for the board soon after writing that article, but I was too busy with the university lectures and exams to get a hand on it. Finally I have spent a few hours at night and I proudly can say: the display is working 🙂
In “Tutorial: FreeRTOS 10.0.1 with NXP S32 Design Studio 2018.R1” I showed how to use a custom FreeRTOS with the S32 Design Studio (ARM). The OSIF (OS Interface) provides an operating system and services abstraction for the application which is used by other S32K SDK components:
“There is no ‘S’ for Security in IoT” has indeed some truth. With all the connected devices around us, security of code should be a concern for every developer. “Preventing Reverse Engineering: Enabling Flash Security” shows how to prevent external read-out of critical code from device. What some microcontroller have built in is yet another feature: ‘Execute-Only-Sections‘ or ‘Execute-Only-Memory‘. What it means is that only instruction fetches are allowed in this area. No read access at all. Similar like ‘read-only’ ‘execute-only’ it means that code can be executed there, but no other access from that memory is allowed.
In this article I describe the challenges for a toolchain like the GNU gcc, and how to compile and link code for such an execute-only memory.
In many cases it is very useful to see the generated assembly code produced by the compiler. One obvious way to see the assembly code is to use the Disassembly view in Eclipse:
But this requires a debug session. An easier way is to use command line options to generate the listing file(s).
NXP not only sells general purpose microcontroller, but as well a portfolio of automotive devices which includes the S32K which is ARM Cortex based. For this device family, they offer the S32 Design Studio (or S32DS) with its own Eclipse distribution and SDK. The interesting part is that the S32DS includes Processor Expert (which is a bit different from the ‘mainstream’ Processor Expert). It comes with its own components for the S32K SDK which includes a component for FreeRTOS. But that component in S32DS 2018.R1 comes with an old V8.2.1 FreeRTOS component:
So what to do if I want to use the latest FreeRTOS (currently 10.0.1) with all the bells and whistles?
Hardware Timers are essential to most embedded applications: I use them mostly for triggering actions at a given frequency, such as acquiring data from a sensor. With using an RTOS I can do a similar thing using a task: the task will run with a given frequency and I can periodic work in it. However, using a task might be too much overhead doing this. The good news is that there is a much more efficient way to do this in FreeRTOS with Software Timers. And this is what this tutorial is about: how to use Software Timers with FreeRTOS.
Decisions, decisions! Such long weekends like Pentecost are a real challenge for a family with engineers:
- Should we join that record long traffic jam to Italy and be stuck for more than 4 hours and analyze it?
- Or: should we stay home, turn the BBQ smoker engine on fire, load it with baby back pork rib racks for a slow-and-low smoke treatment, while doing some on-the-side IDE and technology exploration?
Well, my family vote was kind of clear: they have chosen that second option. Not to mention that hidden technology piece in it, but that was part of the deal ;-).
And I’m sorry: this article is not about BBQ (for this see “Smoking BBQ Baby Back Ribs – Swiss Style“), it is about technology: I’m using the NXP MCUXpresso IDE and tools for many of my projects (see “Eclipse MCUXpresso IDE 10.1 with integrated MCUXpresso Configuration Tools“). Right before the this extended weekend, NXP has released the new v10.2.0 version, so here is where that technology exploration piece comes into play. Checking the release notes, this version number change includes so many cool stuff I decided to have a look and to check it out. Of course always having an electronic eye on the baby back ribs!
I apologize: I have not been blogging much in the past weeks :-(. One reason is that I’m working on a DIY SMT/SMD Pick&Place machine which keeps me busy most of my spare time :-). I admit that this project is not finished yet, but now is the time I can give a sneak preview: a SMD/SMT pick and place machine:
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?
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.
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.
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:
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: