Right before Christmas 2019, NXP has released a new version of the MCUXpresso IDE, the version 11.1.0. This gave me time to explore it over the Christmas/New-Year break and evaluate it for the next university semester. There are several new features which will make my labs using it easier, so I plan to get the course material updated for it.
When using an RTOS like FreeRTOS, sooner or later you have to ask the question: how much time is spent in each task? The Eclipse based MCUXpresso IDE has a nice view showing exactly this kind of information:
FreeRTOS Runtime Information
For FreeRTOS (or that Task List view) to show that very useful information, the developer has to provide a helping hand so the RTOS can collect this information. This article shows how this can be done on an ARM Cortex-M.
For this last blog in the series Investigating ARM Cortex® M33 core I decided to explore the expansion features of the LPC55S69-EVK. This board has three expansion ports (PMOD, Arduino Duo, Mikroe click) and I picked the Mikroe expansion port. Why? Only because I had good experience with these boards with the Hexiwear project.
And because I have been doing some work this month with AWS IOT I wanted to get my LPC55S69-EVK onto my office WiFi network for the Christmas holidays. I know that the MCUXpresso SDK for lpcxpresso55s69 version 2.6.3 has a built-in WiFi example named qca_demo, and so that is what I am investigating today.
That WiFi example supports three WiFi shield boards, and I picked the Mikroe WiFi 10 click board. It’s part number MIKROE-3432 and available from all of the usual catalogue distributors.
In last week’s blog I explained that the LPC55S69 microcontroller from NXP has two Cortex® M33 cores, named core0 and core1. There was a lot of theory, and so this week I put it all into practice and show you how to debug 2 cores with MCUXpresso IDE.
I really love clocks. I think this is I am living here in Switzerland. Beside of that: clock projects are just fun :-). After I have completed a single clock using stepper motors (see “DIY Stepper Motor Clock with NXP LPC845-BRK“), I wanted to build a special one which is able to show up to four different time zones: Below an example with London (UK), New York (USA), Beijing (China) and Lucerne (Switzerland):
The NXP LPC55S69-EVK is a versatile board. In this article I show how it can be used with Adafruit TFT LCD boards, both with resistive and capacitive touch. For the software I’m using the open source LittlevGL GUI.
When we are learning about TrustZone® it does not take long to recognise that it is the security attributes for memory that define memory regions to be Secure, Non-Secure or Non-Secure Callable. This week’s video shows how the Cortex® M33 core with TrustZone® extension can test the security attributes for every read, write and execute from memory (without impacting performance). And how the security attributes are set with the Trusted Execution Environment configuration tool inside MCUXpresso IDE.
Bootloaders are a fine thing: With this I can load any applications I like. Power comes with some complexity, and a bootloader alone is a complex thing already. But this applies to the application part too: I need to link the application to a certain offset in the memory space so it can be loaded by the bootloader, plus the application typically needs to add some extra information to be used by the bootloader. This article describes how to build a bootloader application with Eclipse (MCUXpresso IDE) using the MCUXpresso SDK.
Stack overflows are probably the number 1 enemy of embedded applications: a call to a a printf() monster likely will use too much stack space, resulting in overwritten memory and crashing applications. But stack memory is limited and expensive on these devices, so you don’t want to spend too much space for it. But for sure not to little too. Or bad things will happen.
The Eclipse based MCUXpresso IDE has a ‘Heap and Stack Usage’ view which can be used to monitor the stack usage and shows that a stack overflow happened:
Heap and Stack Usage
But this is using the help of the debugger: how to catch stack overflows at runtime without the need of a debugger? There is an option in the GNU gcc compiler to help with this kind of situation, even if it was not originally intended for something different. Continue reading →
When Espressif released in 2014 their first WiFi ESP8266 transceiver, they took over at least the hobby market with their inexpensive wireless devices. Yet again, the successor ESP32 device is used in many projects. Rightfully there are many other industrial Wi-Fi solutions, but Espressif opened up the door for Wi-Fi in many low cost projects. Many projects use the ESP devices in an Arduino environment which basically means decent debugging except using printf() style which is … hmmm … better than nothing.
What is maybe not known to many ESP32 users: there *is* actually a way to use JTAG with the ESP32 devices :-). It requires some extra tools and setup, but with I have a decent Eclipse based way to debug the code. And this is what this article is about: how to use a SEGGER J-Link with Eclipse and OpenOCD for JTAG debugging the ESP32.
Well let’s face it, modern microcontrollers are complicated. The User Manual for the LPC55S69 has 1148 pages (Rev 1.3) and that does not include any of the electrical characteristics – see the Datasheet (129 pages) nor does it include the details around the core or instruction set (see ARM documentation) . So there is a lot of technical information to read, and don’t get me started on the pin multiplexing… Well actually, do get me started on the pin multiplexing because that is my focus this week.
This week I turned my attention to writing a very simple example project in MCUXpresso IDE to run on the ARM Cortex® M33 core inside the LPC55S69. As in previous weeks I am again using the LPC55S69-EVK from NXP. My plan is to use this board every week but I have learned recently a few details about a new ultra-low-cost board. It’s going to be AMAZING and I’ll share more details with you when I can.
This is the second of my 17-part video tutorial series investigating the ARM Cortex® M33 core with TrustZone® security extension. My preferred platform for this investigation is the LPC55S69 from NXP, and of course it is necessary to have a development board and IDE. So I’m using the LPC55S69-EVK with NXP’s MCUXpresso IDE and the MCUXpresso Software Development Kit (SDK).
This week the video is really low on theory, but high on practical, step-by-step information to get started with these tools. Maybe you are similar to me, and make the same mistake every time?? I get the self-assembly furniture home from the store, or open the box containing the new development board and just get started. At some point it doesn’t work properly and that’s the time I must read the supporting information.
Well, with this video I show you beginning-to-end in just over 10 minutes, and you won’t need to refer to any other material.
The Espressif ESP32 devices are getting everywhere: they are inexpensive, readily available and Espressif IDF environment and build system actually is pretty good and working well for me including Eclipse (see “Building and Flashing ESP32 Applications with Eclipse“). The default way to program an ESP32 is to a) enter UART bootloader by pressing some push buttons and b) flash the application with ESP-IDF using a USB cable.
That works fine if the ESP32 is directly connected to the host PC. But in my case it is is behind an NXP Kinetis K22FX512 ARM Cortex-M4F microcontroller and not directly accessible by the host PC. So I had to find a way how to allow boot loading the ESP32 through the ARM Cortex-M which is the topic of this article.
The new semester is approaching in a very fast way, and so is the new lecture and lab module ‘Advanced Distributed Systems’ at the Lucerne University. For that module we are going to build a new ‘Sumo’ style robot with WLAN capabilities using the ESP32 chip. It will be a new robot PCB, and below is the current robot (based on NXP K22FX512) with the WLAN module connected to it:
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.