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.
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.
Throughout this series I’ve been using the LPC55S69 microcontroller from NXP as a platform to investigate the ARM Cortex® M33 core. NXP designed the LPC55S69 with two Cortex M33 cores and so this week I’m investigating these in more detail.
You’ll remember that when ARM launch a processor core it will have a number of optional features. This is shown very clearly on the LPC55S69. The 150 MHz primary core – cpu0 – is a full implementation of Cortex® M33 and includes the optional components FPU, MPU, DSP, ITM and the TrustZone® features.
I’ve always felt that the Fourier Transform (and in particular the embedded implementation Fast Fourier Transform) is the GOAT* of the DSP algorithms. The ability to convert a time-domain signal into a frequency-domain signal is invaluable in applications as diverse as audio processing, medical electrocardiographs (ECGs) and speech recognition.
So this week I’ll show you how to use the Transform engine in the PowerQuad on LPC55S69 to calculate a 512-point FFT. All of the difficult steps are very easily managed and the PowerQuad does all of the very heavy lifting.
Last week I showed you how to use the Coprocessor interface of PowerQuad to calculate (mostly) unary functions. As an example the natural logarithm ln(x) takes just one operand, whilst the floating divide in PowerQuad requires two operands (x1)/(x2). PowerQuad is very efficient accelerating these functions, requiring just 6 clock cycles for the ln(x) and 6 clock cycles for the float (x1)/(x2). In comparison the single-precision floating point unit in Cortex® M4F and M33F requires 13 clock cycles to perform the same float divide.
But there are two ‘sides’ to the PowerQuad:
The Coprocessor interface, using ARMv8-M coprocessor instructions;
The AHB bus interface, where we address PowerQuad as a peripheral.
So this week… operating the PowerQuad as a peripheral. I’ll show you how to use the PowerQuad SDK driver in MCUXpresso in a new project, and use the Matrix Engine in the PowerQuad to solve simultaneous equations.
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):
If you ask your colleagues about ARM Cortex® M33 core, they’ll most likely remember that the ARMv8-M architecture adds the (optional!) TrustZone® security extension. But one, overlooked but significant new feature in ARMv8-M is the new coprocessor interface.
With the LPC55S69 microcontroller, NXP decided to add an extremely powerful DSP Accelerator onto this coprocessor interface, named PowerQuad. In this week’s video series I’m investigating the PowerQuad, and the functions that it provides.
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.
Last week I investigated the In-System Programming feature in the boot ROM of the LPC55S69. Using the command-line program blhost I was able to erase the flash and download simple LED blinky programs. Of course, the functions that erase and program the flash are present in the boot ROM.
Wouldn’t it be great if we could call those program and erase functions from our own software running on the LPC55S69?
Of course, we can. This is the NXP feature In-Application Programming, and this week I’ll show you how to interface to the Flash Driver in the boot ROM from software. Since the program and erase functions are running from ROM, this avoids the normal considerations about using flash for non-volatile storage.
This week I’m back to the normal ‘Tutorial’ format with a look at the In-System Programming feature in the boot ROM of the LPC55S69. I’ll use the NXP-provided command-line program blhost and interface with the ROM to erase the flash and download simple LED blinky programs.
During my research about the TrustZone® security extension over the last weeks I’ve had the HeartBleed exploit from 2014 in my mind. How would TrustZone® help us manage that type of ‘no bounds check’ exploit? Of course, TrustZone® was first widely available when NXP introduced the Cortex® M33 family LPC55S69 in 1Q2019 and wasn’t available back in 2014, but I wanted to put it to the test.
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.
In “Eclipse JTAG Debugging the ESP32 with a SEGGER J-Link” I used a SEGGER J-Link to debug an ESP32 device with JTAG. I looked at using one of the FTDI FT2232HL development boards which are supported by OpenOCD. The FT2232HL is dual high-speed USB to UART/FIFO device, and similar FTDI devices are used on many boards as UART to USB converters. With OpenOCD these devices can be turned into inexpensive JTAG debug probes. This article shows how to use a $10 FTDI board as JTAG interface to program and debug the Espressif ESP32.
You might purchase a Cortex® M33 microcontroller with TrustZone® where the supplier has installed a secure ROM. Or you might be an IOT developer using LPC55S69 in your own application where you have partitioned the code into secure and non-secure partitions. At some point with Cortex® M33 core with the TrustZone® security extension you’ll want to transition from non-secure into the secure world. Or (put more elegantly), you’ll want to call one of the secure functions supported when the Cortex® M33 core is in the Secure state.
That’s the topic for this week’s video.
How will you know what secure functions are available? And what parameters are necessary to call these functions? You’ll be provided with a header file veneer_table.h and a secure object library named project_name_CMSE_lib.o. Together these 2 modules describe everything that you need to know to call a secure function and transition from the Non-Secure to the Secure state.
Last week I wrote about why we need the TrustZone® security extension for ARMv8-M. There are software use-cases where it can be very helpful to partition the software into 2 separate worlds, secure and non-secure. TrustZone® acts as the gatekeeper between these two worlds and manages how the core transitions between the worlds. The ARMv8-M architecture introduces two new States for the core – secure and non-secure. Cortex® M33 core (and M23 core also) is implemented to ARMv8-M standard and of course supports the two new states.