In my “Tutorial: Catching Rogue Memory Accesses with Eclipse and GDB Watchpoints” I have used Eclipse/CDT and GDB watchpoints. I used a conditional watchpoint, but this comes with a performance hit. In this article I show how to use the ARM Cortex trace hardware to catch specific writes to a memory location. Without severe performance degradation. But for this I need a little helper: the DEADBEEF catcher!
NXP has just released the 10.2.1 update of their flagship Eclipse based IDE. While the number increase from 10.2.0 to 10.2.1 indicates a minor release, there are a several things which make me move over to that new release.
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.
Ported Project with FRDM-K64F using Adafruit SSD1351 and Processor Expert
I’m pleased to announce that a new release of the McuOnEclipse components is available on SourceForge. This release includes several smaller bug fixes and initial component support for the NXP S32 Design Studio and SDK.
The ARM DWT (Data Watchpoint and Trace) is an optional feature of the ARM-Cortex-M, and many Cortex-M3, M4 and M7 devices have it implemented. With it comes a cycle counter which counts the cycles spent. In Cycle Counting on ARM Cortex-M with DWT I described an approach how the application on the target can access the cycle counter.
The MCUXpresso IDE shows that cycle counter in the Eclipse Registers view:
To support my talk next week at the Embedded Computing Conference 2018, I have put together a video with the hardware features of that Pick&Place based on OpenPnP machine. Below is a picture of the current machine:
By default, the GNU compiler (gcc) optimizes each compilation unit (source file) separately. This is effective, but misses the opportunity to optimize across compilation units. Here is where the Link Time Optimization (LTO, option -flto) can help out: with a global view it can optimize one step further.
The other positive side effect is that the linker can flag possible issues like the one below which are not visible to the compiler alone:
type of '__SP_INIT' does not match original declaration [enabled by default]
When using the FreeRTOS Task List in the Eclipse based MCUXpresso IDE, it shows the list of tasks with their stack size used. But with the default FreeRTOS settings it is not able to determine the correct stack size and shows a warning icon:
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:
Using IP (Ethernet) based debug probes is a very handy thing: I don’t have to be directly connected to the debug probe (e.g. with the USB cable). This article explains how to use an IP-based Segger or P&E probe with the Eclipse based MCUXpresso IDE.
It’s April Fool’s Day, but be assured this is not a joke ;-): I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge. This release includes several smaller bug fixes and components have been upgraded for FreeRTOS V10.0.1.
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.
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:
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:
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’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.