Investigating ARM Cortex® M33 core with TrustZone® – In-Application Programming Tutorial

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.

The LPC55S69 contains a pointer table to the ROM APIs at base address 0x130010f0. This is in the boot ROM memory space, and is simply a set of function pointers. The ROM table contains a pointer to the runBootloader function, meaning that we can start the bootloader from our application code. Above this in memory are a version string, a copyright string, a pointer to the flashDriver structure, and pointers to the USB, low power and Crypto drivers. Note that I believe that the documentation is not quite up-to-date since it does not show the copyright string pointer that is present in the SDK implementation of the ROM Drivers.

We are considering the flashDriver today. The flashDriver pointer from the ROM API pointer table re-directs to another structure, of type flash_driver-interface_t. It’s another pointer table and exposes the flash driver ROM functions – flash_init, flash_erase, flash_program etc.

Fortunately, NXP have implemented function wrappers for all of the necessary functions, and these are provided to us in the SDK flash driver fsl_iap.c and fsl_iap.h. It is highlighted in the example project lpcxpresso55s69_flashiap1from the SDK where an area of flash – at base address 0x9DE00 – is erased and programmed.

The flash driver implements a function – flash_get_property – and we can pass parameters into the function to learn details about the flash architecture on the device.

We can see that the FlashPageSize is 0x200 bytes. The total flash size is 640kbytes, but the last 8kbytes are not useable and so the example project computes the last available page in flash and uses this for the flash example. That is where the address 0x9DE00 comes from.

The example project simply test-drives the Flash driver functions to erase and program the page at 0x9DE00.

The video tutorial is hosted here and you can watch the other videos in the embeddedpro® YouTube channel here. For your convenience the video is embedded in this blog:

I’m not 100% certain what I’ll share with you next week, but I’m thinking I’ll blog about the hardware DSP accelerator PowerQuad. Let’s see what the week brings. Let me know if you have other suggestions, and don’t forget to let me know how you get along with the In-Application Programming feature on NXP’s LPC5569.

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.