The Eclipse CODAN (Code Analysis) plugin is part of CDT and is a powerful static analysis tool finding all kind of possible bugs and issues. Still to my surprise not many C/C++ developers take advantage of it maybe because they are not aware that it exists?
ups! Programming error detected by CODAN
In this article I show a few tips how to effectively use it, especially with the NXP MCUXpresso SDK.
The NXP MCU-Link is a powerful $10 debug probe for ARM Cortex-M devices and works with the NXP LinkServer for debugging. The LinkServer does not an implement a gdb server, so it limits its usage e.g. for scripting or command line debugging. But as MCU-Link is also a CMSIS-DAP compatible debug probe, I can use it with OpenOCD which is open source and implements a GDB server. This article shows how I can use it with the MCU-Link.
The MCU-Link is a $10 CMSIS-DAP capable debug probe which works out-of-the box with the MCUXpresso Eclipse based IDE. This is great for development, but how can I programming with the push of a button or a script? The answer is no: there is an easy way to use the debug probe outside Eclipse from a shell script, and you can use that MCU-Link probe to do the job. This is especially useful as with the example below where I have to program 60 boards this week-end :-).
Amazon has released in the past week the FreeRTOS version V10.4.0. Time to upgrade, actually the most recent version 10.4.1! The same time the SEGGER SystemView V3.12 was released back in April this year. No surprise: with the FreeRTOS changes they don’t work out of the box: but no worries, I have you covered and applied all the needed patches and changes to have them working again together: the latest FreeRTOS v10.4.x with Segger SystemView v3.12:
It is great if vendors provide a starting point for my own projects. A working ‘blinky’ is always a great starter. Convenience always has a price, and with a ‘blinky’ it is that the code size for just ‘toggling a GPIO pin’ is exaggerated. For a device with a tiny amount of RAM and FLASH this can be concerning: will my application ever fit to that device if a ‘blinky’ takes that much? Don’t worry: a blinky (or any other project) can be easily trimmed down.
Binky on NXP LPC845-BRK Board
I use a ‘blinky’ project here just as an example: the trimming tips can apply to any other kind of projects too.
The NXP LPC845-BRK board is a tiny an inexpensive (sub $6) breakout board. The board includes a CMSIS-DAP (LPC11U35) on-board debug probe which can be used as a debug probe to debug any NXP LPC, Kinetis or i.MX RT device 🙂
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
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: