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!
0xdeadbeef catcher
Eclipse is great: it gives me the tools and capabilities to solve the really hard bugs to find. An example of that ‘hard’ category are ‘rogue’ memory accesses: something in the application is accessing an unwanted memory location and corrupts the data. This might be very sporadic, or takes a long while until it happens. With normal ‘stop-mode’ debugging (setting a normal breakpoint) and stepping usually won’t let me find that bug, as it might be coming from a pointer somewhere. Maybe from an interrupt routine. Or maybe an unitialized or corrupted pointer corrupts to my memory. Usually all what I know is the memory adddress of the data, maybe what is written, but not what or who is writing to that location.
In this article I’m using one of the ‘less-known’ debugging techniques available in Eclipse and CDT and how it works: watchpoints!
Watchpoint with Condition
In this article I’m using one of the ‘less-known’ debugging techniques available in Eclipse and CDT and how it works: watchpoints!
Powerful ARM Cortex-M7 microcontroller are on the rise, bridging the gap between traditional microcontroller and Embedded Linux systems. I already published articles for the NXP i.MX RT1052 which is an ARM Cortex-M7 running at 600 MHz. Because the RT105x is available in BGA196 package only, I have as oredered the i.MX RT 1050 EVK which has a similar device on it, but in LQFP package:
i.MX RT1021
I noticed on Mouser.com that there is a new i.MX RT1050 board: the EVKB one. I have used the EVK (the one without the ‘B’) for several weeks (see “MCUXpresso IDE V10.1.0 with i.MX RT1052 Crossover Processor” and “Adding a Rocktech Capacitive Touch LCD to the NXP i.MX RT1052 EVK“). I needed anyway a second board, so I ordered that EVKB from Mouser, and after some delay and waiting it arrived on my desk. So far this boards seems to be a better one:
i.MX RT1050 EVKB Board
In this short article I show you how to enable one of the hidden gems in Eclipse: how to get a description of the library function used in the code
snprintf() help text
FreeRTOS includes a nice feature to give me information about how much time every task is spending running on the system:
FreeRTOS Runtime Information
This tutorial explains that FreeRTOS Runtime Statistics feature and how it can be turned on and used.
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.
MCUXpresso IDE 10.2.1 build 795
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
It is never too early to start thinking about Halloween projects :-).
rendered Eyes with i.MX RT
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 🙂
By default, the NXP S32K144EVB and microcontroller is using a 5V supply voltage and logic levels which is great for noisy environment or any 5V devices. Many of my displays and sensors use 3.3V logic levels, so I would have to use a level shifter from 5V to 3.3V. There is another way: to change the board for 3.3V logic levels so I can use directly things like a SSD1306 display.
S32K144EVB with OLED SSD1306 using 3.3V Logic Levels
MCU on Eclipse 