LPC Microcontrollers Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC Microcontrollers Knowledge Base

Discussions

Sort by:
Unboxing video of the low cost OKDO E1 board.    As a quick demo, I hooked up the E1 to a low cost  240x240 Pixel IPS display from buydisplay.com.
View full article
The Economist Intelligence Unit’s (EIU) 2020 IoT Index recently highlighted that 2020 will be the year when the Internet of Things (IoT) officially moves from “proof of concept” to “mass deployment”, with over half of all companies surveyed now undergoing early or extensive deployment of internal or external IoT networks. Read more >> NXP and Arm Pelion Device Management Secure Deployment of IoT Devices from Chip to Cloud | Pelion IoT Blog 
View full article
When we use LPC55Sxx PRINCE feature, we need enable PRINCE sub-region “crypto” by setting SR_ENABLE register. If we “crypto” enable discontinuous sub-regions and erase part of them, we may find we can’t erase/read/write other “crypto” sub-regions any more. This article will discuss how to resolve this phenomenon.           Figure 1         Testing Steps According to LPC55Sxx UM, each PRINCE region has its SR_ENABLEx register. This register enables PRINCE encryption and decryption of data for each sub-region of crypto region 0. Each bit in this field enables a sub-region of crypto region 0 at offset 8kB*n, where n is the bit number.  For example, when we set SR_ENABLE0=0X00000005, PRINCE region 0 sub-region 1 and sub-region 3 are set as encryption region. When read data out from these sub-regions, PRINCE will decrypt the data automatically.   Now we will test discontinuous sub-region erase/read/write. Board: LPC55S16-EVK IDE: Keil MDK v5.29 Step 1: PRINCE initialization: Enable PRINCE region 0 and two discontinuous sub-regions; generate key, IV code; enable crypto. //set SR_ENABLE , SR_ENABLE=0X28000000,enable sub-regions(0x30000-0x32000,0x34000-0x36000) crypto 。 status=PRINCE_SetRegionSREnable(PRINCE( prince_region_t )region0,0X28000000); //select PRINCE crypto for region0 PRINCE_SetRegionBaseAddress ( PRINCE_Type *base, prince_region_t region0, uint32_t 0X0) //generate PRINCE region0 crypto key Status=FFR_KeystoreGetKC(&flashInstance,&keyCode[0],kFFR_KeyTypePrinceRegion0); status=PUF_GetHwKey(PUF,keyCode,sizeof(keyCode),kPUF_KeySlot2, rand()); //generate PRINCE region0 crypto IV_code status=PRINCE_GenNewIV(kPRINCE_Region0,&prince_iv_code[0],true,&flashInstance) //load IV code to PRINCE status=PRINCE_LoadIV(kPRINCE_Region0,&prince_iv_code[0]) //enable PRINCE encryption PRINCE_EncryptEnable(PRINCE)   Step 2: Select two discontinuous sub-regions ( 0x30000-0x32000,0x34000-0x36000). Erase one of them (0x30000-0x32000), then write data to this sub-region. Output: Erasing and Writing are all successful. See Figure 2. //Erase 0x30000-0x32000 sub-region status=PRINCE_FlashEraseWithChecker(&flashInstance,0x30000,0x2000,kFLASH_ApiEraseKey); //Write 0x30000-0x32000 sub-region status=PRINCE_FlashProgramWithChecker(&flashInstance,0x30000,(uint8_t *)prince_iv_code,0x2000);   Step 3: Erase and Write the other sub-region ( 0x34000-0x36000 ) Output: Erasing and Writing are failed. See Figure 2. //Erasing 0x34000-0x36000 sub-region status=PRINCE_FlashEraseWithChecker(&flashInstance,0x34000, 0x2000,kFLASH_ApiEraseKey); //Write 0x34000-0x36000 sub-region status=PRINCE_FlashProgramWithChecker(&flashInstance,0x34000, (uint8_t *)prince_iv_code,0x2000); Error Analysis According to UM11126( 49.16.1 Functional details ) , each crypto region has its own SKEY and IV code. SKEY and IV are used together by the PRINCE when encrypting or decrypting the data in the sub-regions of crypto region. For Instance, For PRINCE region1, each time after we execute erasing operation, new Skey1 and IV1 are generated, thus when executing erase/read/write operation to another sub-region, the old IV1 and new IV1 don’t match, which causes PRINCE can’t decrypt correctly.   Suggestion We suggest user using SR_ENABLE to set continuous crypto sub-regions. When erasing operation is needed, erasing all the crypto sub-regions together, avoid erasing part of the sub-regions. One sub-region size is 8K, make sure the erasing/writing address 8K aligned.   Thanks for the suggestion from johnwu‌
View full article
Abstract This paper discusses our approach to crypto acceleration and asset protection using novel techniques that help bring high levels of security to low-cost microcontrollers with minimal power and area penalty. CASPER, our asymmetric cryptography acceleration engine, aims to optimize crypto algorithm execution (e.g., RSA, ECC). It is built on a hardware-software partitioning scheme where software functions map asymmetric crypto functions to the hardware modules of the accelerator, delivering sufficient flexibility to software routines to enable mapping of new algorithms. Further efficiency is achieved by making use of the co-processor interface on the Arm® Cortex®-M33 core. Important assets such as keys, proprietary and/or licensed application software are protected against side-channel analysis or cloning using SRAM PUF and PRINCE. SRAM PUF technology enables secure storage of root-of-trust keys and user keys by exploiting the deep sub-micron process technology variations. PRINCE is a low-latency lightweight cryptography algorithm implementation in hardware that allows encrypted non-volatile storage and real-time, latency-free decryption of the execution code. Read More >
View full article
View Webinar Recording
View full article
When you are the first time to debug LPC55S69, please read below document and double check your IDE, SDK and EVK version is correct. Usually, we prefer use the latest IDE, SDK and EVK boards. Important updates when using LPCXpresso55S69 Revision A2 boards and 1B silicon  [Problem Description] When you use IAR 8.32 to debug LPC55S69 '1B' silicon, the IDE will remind you " The debugging session could not be started ", like below picture show: The  reason of this failure is that IAR 8.32's LPC55S69 chip configuration files only support revision '0A' silicon, not '1B'. We strongly recommend customer download and use IAR 8.40.2 or latest version. The IAR IDE start support LPC55S68 '1B' silicon from 8.40.2. [Solution] If you have some reasons that must use IAR 8.32, you can download attached zip file. This zip file like a patch, include the IAR LPC55S69 '1B' support files. Un-zip this file and merge the same  files under IAR installed path : IAR\arm\config\flashloader\NXP Then the IAR can support '1B' silicons. [How to identify LPC55(S)6x chip silicon versions] On the top-side marking code, there is '1B'  charactors at the end of mark strings. See below two pictures, the left one is '1B' version chips.                      LPC55(S)6x ver '1B'                                                               LPC55(S)6x ver '0A'                   
View full article
MCUXpresso SDK for LPC55xx uses FLASH API to implement FLASH drivers. Some user may meet issue when executes FLASH program code, for instance: status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8); After execution this code, nothing changed in the destination address, but error code 101 returns: This error code looks new, as it doesn’t commonly exist in other older LPCs. If we check FLASH driver status code from UM, code 101 means FLASH_Alignment Error: Alignment error Ah ha? ! Go back to the definition of FLASH_Program, status_t FLASH_Program(flash_config_t *config, uint32_t start, uint32_t *src, uint32_t lengthInBytes); New user often overlooks the UM description of this API “the required start and the lengthInBytes must be page size aligned”. That’s to say, to execute FLASH_Program function, both start address and the length must be 512 bytes-aligned. So if we modify status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8); To status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 512); FLASH_Program can be successful.   !!NOTE: In old version of SDK2.6.x, the description of FLASH_Program says the start address and length are word-aligned which is not correct. The new SDK2.7.0 has fixed the typo.  Keep in mind: Even you want to program 1 word, the lengInBytes is still 512 aligned, as same as destAdrss! PS. I always recommend my customer to check FLASH driver status code when meet problem with FLASH API. We can find it in UM11126, Chapter 9, FLASH API. I extract here for your quickly browse:   Happy Programming
View full article
[中文翻译版] 见附件   原文链接: https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2019/05/05/trustzone-with-armv8-m-and-the-nxp-lpc55s69-evk
View full article
[中文翻译版] 见附件   原文链接: https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/02/26/lpc55xx-multicore-applications-with-mcuxpresso-ide
View full article
The LPC55S6x family was initial silicon die version was 0A, and this silicon was using on Revision A1 LPCXpresso55S69 boards. Revision 1B silicon has been used on Revision A2 boards. Both versions of silicon support the new, more robust debug session request method, but 1B silicon requires its use. If the correct version of IDE and/or debug probe drivers are not used then debug operation will be affected or non-functional.  When using Revision A2 boards, the current software release versions are required: MCUXpresso IDE Version  11.0.1 or later (11.1 or later recommended) [Note: IDE 11.0.1 may also be used but when using Revision A1 boards a hot fix is required for this release. See  MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix ] Note that you may need to start from a new workspace if transitioning from one developed using a Revision A1 board to a Revision A2 board (or any target system using Revision 1B silicon). IAR Embedded Workbench version 8.40.2 or later Keil uVISION LPC55S6x Device Family Pack (DFP) 12.0.1 or later SEGGER J-Link J-link version 6.54c or later should be used (from the SEGGER download site), and V6.64 or later is recommended. When using J-link with non-SEGGER IDEs (MCUXpresso, IAR, Keil), ensure that you IDE configuration is pointing to the latest J-Link drivers. If using MCUXpresso IDE 11.0.1 the included J-link drivers need to be updated to the latest version to support Revision A1 boards. See Updating a SEGGER J-Link installation on Windows for more information. For more information about silicon revision and tools, please refer to Understanding LPC55S6x Revisions and Tools  Please also note that there are Chinese versions of description regarding board revision, silicon revision and the corresponding tools as shown below: 中文版:LPC55S6x 版本更新及开发工具注意事项 中文版:LPC55S6x 0A 和1B 版本区别进阶
View full article
[中文翻译版] 见附件 原文链接: https://community.nxp.com/docs/DOC-343506
View full article
The documentation discusses how to generate phase-shift PWM signals based on SCTimer/PWM module, the code is developed based on MCUXpresso IDE version 10.3 and LPCXpresso5411x board. The LPC family has SCTimer/PWM module and CTimer modules, both of them can generate PWM signals, but only the SCTimer/PWM module  can generate phase-shift PWM signals. In the code, only the match registers are used to generate events, I/O signals are not used.  The match0 register is set up as (SystemCoreClock/100), which determines the PWM signal frequency. The the match1 register is set up as 0x00, which generate event1. The the match2 register is set up as (SystemCoreClock/100)/2;, which generate event2. The duty cycle is (SystemCoreClock/100)/2-0x00= (SystemCoreClock/100)/2, which is 50% duty cycle, the cycle time is (SystemCoreClock/100). The event1 sets the SCT0_OUT1, event2 clears the SCT0_OUT1, so SCT0_OUT1 has 50% duty cycle. The the match3 register is set up as (SystemCoreClock/100)/4;, which generate even3. The the match4 register is set up as 3*(SystemCoreClock/100)/4, which generate event4. The duty cycle is 3*(SystemCoreClock/100)/4  -  (SystemCoreClock/100)/4= (SystemCoreClock/100)/2, which is 50% duty cycle. The event3 sets the SCT0_OUT2, event4 clears the SCT0_OUT2, so SCT0_OUT2 has 50% duty cycle. The phase shift is (SystemCoreClock/100)/4 - 0x00= (SystemCoreClock/100)/4, which corresponds 90 degree phase shift. PWM initilization code: //The SCT0_OUT1 can output PWM signal with 50 duty cycle from PIO0_8 pin //The SCT_OUT2 can output PWM signal with 50 duty cycle fron PIO0_9 pin //The SCT0_OUT1 and SCT0_OUT2 PWM signal has 90 degree phase shift. void SCT0_PWM(void) {     SYSCON->AHBCLKCTRL[1]|=(1<<2); //SET SCT0 bit     SCT0->CONFIG = (1 << 0) | (1 << 17); // unified 32-bit timer, auto limit     SCT0->SCTMATCHREL[0] = SystemCoreClock/100; // match 0 @ 100 Hz = 10 msec     SCT0->EVENT[0].STATE = 0xFFFFFFFF; // event 0 happens in all states     //set event1     SCT0->SCTMATCHREL[1]=0x00;     SCT0->EVENT[1].STATE = 0xFFFFFFFF; // event 1 happens in all states     SCT0->EVENT[1].CTRL = (1 << 12)|(1<<0); // match 1 condition only     //set event2     SCT0->SCTMATCHREL[2]=(SystemCoreClock/100)/2;     SCT0->EVENT[2].STATE = 0xFFFFFFFF; // event 2 happens in all states     SCT0->EVENT[2].CTRL = (1 << 12)|(2<<0); // match 2 condition only     //set event3     SCT0->SCTMATCHREL[3]=(SystemCoreClock/100)/4;     SCT0->EVENT[3].STATE = 0xFFFFFFFF; // event 3 happens in all states     SCT0->EVENT[3].CTRL = (1 << 12)|(3<<0); // match 3 condition only     //set event4     SCT0->SCTMATCHREL[4]=3*(SystemCoreClock/100)/4;     SCT0->EVENT[4].STATE = 0xFFFFFFFF; // event 4 happens in all states     SCT0->EVENT[4].CTRL = (1 << 12)|(4<<0); // match 4 condition only     //PWM output1 signal     SCT0->OUT[1].SET = (1 << 1); // event 1 will set SCT1_OUT0     SCT0->OUT[1].CLR = (1 << 2); // event 2 will clear SCT1_OUT0     SCT0->RES |= (3 << 2); // output 0 toggles on conflict     //PWM output2 signal     SCT0->OUT[2].SET = (1 << 3); // event 3 will set SCT1_OUT0     SCT0->OUT[2].CLR = (1 << 4); // event 4 will clear SCT1_OUT0     SCT0->RES = (3 << 4); // output 0 toggles on conflict     //PWM start     SCT0->CTRL &= ~(1 << 2); // unhalt by clearing bit 2 of the CTRL } Pin initialization code: //PIO0_8 PIO0_8 FC2_RXD_SDA_MOSI SCT0_OUT1 CTIMER0_MAT3 //PIO0_9 PIO0_9 FC2_TXD_SCL_MISO SCT0_OUT2 CTIMER3_CAP0 - FC3_CTS_SDA_SSEL0 void SCTimerPinInit(void) {     //Enable the     SCTimer clock     SYSCON->AHBCLKCTRL[0]|=(1<<13); //set IOCON bit     //SCTimer pin assignment     IOCON->PIO[0][8]=0x182;     IOCON->PIO[0][9]=0x182;     IOCON->PIO[0][10]=0x182; } Main Code: #include <stdio.h> #include "board.h" #include "peripherals.h" #include "pin_mux.h" #include "clock_config.h" #include "LPC54114_cm4.h" void SCT0_Init(void); void SCTimerPinInit(void); void P1_9_GPIO(void); void SCT0_PWM(void); int main(void) {       /* Init board hardware. */     BOARD_InitBootPins();     BOARD_InitBootClocks();     BOARD_InitBootPeripherals();     printf("Hello World\n");    // SCT0_Init();    // P1_9_GPIO();     SCTimerPinInit();     SCT0_PWM();     /* Force the counter to be placed into memory. */     volatile static int i = 0 ;     /* Enter an infinite loop, just incrementing a counter. */     while(1) {         i++ ;     }     return 0 ; } The Yellow channel is PIO0_8 pin output signal, which is SCT0_OUT1 PWM output signal. The Bule channel is PIO0_9 pin output signal, which is SCT0_OUT2 PWM output signal.
View full article
This documet is an introduction about TrustZone on the LPC55S6x devices. LPC55S6x MCU platform and general-purpose blocks The LPC55S69 has one 100-MHz Cortex-M33 core with TrustZone, MPU, FPU, and SIMD and another 100-MHz Cortex-M33 without security features enable. Lets remark that the LPC55Sxx family has another LPC55S66 that only implements a single 100-MHz core. There are two coprocessors on core 0, a DSP accelerator called PowerQuad, and a crypto engine called CASPER. The core platform has a multilayer bus matrix that allows simultaneous execution from both cores and parallel access of the other masters to peripherals and memories. The memory on chip includes up to 640 KB of Flash, up to 320 KB of RAM, and 128 KB of ROM. Timers include 5 - 32-bit timers, a SCTimer/PWM, a multi-rate timer, a windowed watchdog timer, Real Time Clock (RTC), and a micro timer. Each core has its own systick timer. Communication interfaces include a USB high-speed with on-chip HS PHY, a USB full-speed that can run crystal-less, two SDIO interfaces to support WIFI and SD cards at the same time, 1 high-speed SPI with up to 50-MHz clock rate, and 8 Flexcomms with support of up to 8 SPI, I2C, UART, or 4 I2S. The analog system includes a 16-channel 16-bit ADC that samples at 1 MSPS, an analog comparator, 16-channel capacitive touch controller, and a temperature sensor. Other modules include a programmable logic unit, a buck DC-DC converter, operating voltage from 1.71 to 3.6 V over a temperature range from -40 to 105 °C. What is TrustZone? In recent years, the Internet of Things (IoT) has become a hot topic for embedded system developers. IoT system products have become more complex, and better solutions are needed to ensure system security. ARM® TrustZone® technology is a System on Chip (SoC) and CPU system-wide approach to security. The TrustZone® for ARMv8-M security extension is optimized for ultra-low power embedded applications. It enables multiple software security domains that restrict access to secure memory and I/O to trusted software only. TrustZone® for ARMv8-M: Preserves low interrupt latencies for both secure and non-secure domains Does not impose code overhead, cycle overhead or the complexity of a virtualization based solution Introduces efficient instructions for calls to the secure domain with minimal overhead TrustZone® is a technology available in Cortex M23 and Cortex M33. TrustZone® provides the means to implement separation and access control to isolate trusted software and resources to reduce the attack surface of critical components. The created trusted firmware can protect trusted operations and is ideal to store and run the critical security services. The code should also protect trusted hardware to augment and fortify the trusted software. This includes the modules for hardware assists for cryptographic accelerators, random number generators, and secure storage. Best practices demand that that this code be small, well-reviewed code with provisions of security services. The LPC55S66 and LPC55S69 have implemented core 0 as a Cortex-M33 with full TEE and TrustZone® support enabled. The LPC55S69 has a second Cortex-M33 (core 1) that does not implement the secure environment with TZ. Isolation is just the foundation. Security is about layers of protection, adding in further hardware and software to create more layers. Features of TrustZone® technology: Allows user to divide memory map into Secure and Non-Secure regions Allows debug to be blocked for Secure code/data when not authenticated CPU includes Security Attribution Unit (SAU) as well as a duplication of NVIC, MPU, SYSTICK, core control registers etc. such that Secure/Non-Secure codes can have access to their own allocated resources Stack management expands from two stack pointers in original Cortex-M (Main Stack Pointer (MSP) and Process Stack Pointer (PSP)) to four, providing the above pair individually to both Secure and Non-Secure Introduces the concept of Secure Gateway opcode to allow secure code to define a strict set of entry points into it from Non-secure code Secure and non-secure memory TrustZone® technology divides the system into two states, safe (S) and non-secure (NS), and can switch between the two states through corresponding commands. The CPU states can be secure privilege, secure non-privilege, privilege (Handler), or non-privilege (Thread). The Secure memory space is further divided into two types: Secure and Non-secure Callable(NSC). Below are the feature/properties of Trustzone memory regions ( S, NS, NSC 😞 Secure (S) - For Secure code/data − Secure data can only be read by secure code − Secure code can only be executed by CPU in secure mode Non-Secure (NS) – For non-Secure code/data − NS Data can be accessed by both secure state and non-secure state CPU − Cannot be executed by Secure code Non-Secure Callable (NSC) − This is a special region for NS code to branch into and execute a Secure Gateway (SG) opcode. Attribution Units Combination of Security SAU and IDAU assign a specific security attribute  (S, NS, or NSC) to a specific address from the CPU0. Device Attribution Unit (DAU) connects to CPU0 via IDAU interface as show the following Figure. Access from CPU0, dependent on its security status and the resultant security attribute set by the IDAU and SAU, is then compared by the secure AHB Controller to a specific checker which marks various access policies for memory and peripherals. All addresses are either secure or non-secure. The SAU inside of the ARMv8-M works in conjunction with the MPUs. There are 8 SAU regions supported by LPC55S69. Secure and non-secure code runs on a single CPU for efficient embedded implementation. A CPU in a non-secure state can only execute from non-secure program memory. A CPU in a non-secure state can access data from both NS memory only. For the secure, trusted code, there is a new secure stack pointer and stack-limit checking. There are separate Memory Protection Units (MPUs) for S and NS regions and private SysTick timers for each state. The secure side can configure the target domain of interrupts. The NXP IDAU (Implementation specific Device Attribution Unit) implementation of ARM TrustZone for core0 involves using address bit 28 to divide the address space into potential secure and non-secure regions. Address bit 28 is not decoded in memory access hardware, so each physical location appears in two places on whatever bus they are located on. Other hardware determines which kinds of accesses (including non-secure callable) are allowed for any address.  The IDAU is a simple design using address bit 28 to allow aliasing of the memories in two locations. If address bit 28 is = 0 the memory is Non-Secure. If address bit 28 = 1 the memory is Secure. The SAU allows 8 memory regions and allow the user to override the IDAU’s fixed Map, to define the non-secure regions. By default, all memory is set to secure. At least one ASU descriptor should be used to make IDAU effective. If either IDAU or SAU marks a region, then that region is secure. NSC area can be defined in NS region of the IDAU. For example a designer could use bit [28] of the address to define if a memory is Secure or Non-secure, resulting in the following example memory map. Simple IDAU, without creating a critical timing path. (CM33 does allows little for IDAU function) Addresses 0x0000_0000 to 0x1FFF_FFFF are NS, Addresses 0x2000_0000 to 0xFFFF_FFFF If Address Bit_28 = 0  Non-Secure If Address Bit_28 = 1  Secure All peripherals and memories are aliased at two locations. The SAU define region numbers for each of the memory regions. The region numbers are 8-bit, and are used by the Test Target(TT) instruction to allow software to determine access permissions and security attribute of objects in memory. The number of regions that are included in the SAU can be configured to be either 0, 4 or 8. Note: When programming the SAU Non-secure regions, you must ensure that Secure data and code is not exposed to Non-secure applications. Security state changes The system boots in secure state and can change security states using branches as summarized in the following Figure. Transitions from secure to non-secure state can be initiated by software through the use of the BXNS and BLXNS instructions that have the Least Significant Bit (LSB) of the target address unset. Note: The M profile architecture does not support the A32 instruction set. This allows the LSB of an address to denote the security state. Transitions from non-secure to secure state can be initiated by software in two ways: A branch to a secure gateway. A branch to the reserved value FNC_RETURN. A secure gateway is an occurrence of the Secure Gateway instruction (SG) in  the Non-Secure Callable (NSC) region. When branching to a secure gateway from non-secure state, the SG instruction switches to the secure state and clears the LSB of the return address in lr. In any other situation the SG instruction does not change the security state or modify the return address. A branch to the reserved value FNC_RETURN causes the hardware to switch to secure state, read an address from the top of the secure stack, and branch to that address. The reserved value FNC_RETURN is written to lr when executing the BLXNS instruction. Security state transitions can be caused by hardware through the handling of interrupts. Those transitions are transparent to software and are ignored in the remainder of this document. The TT instruction The ARMv8-M architecture introduces the Test Target instruction (TT). The TT instruction takes a memory address and returns the configuration of the Memory Protection Unit (MPU) at that address. An optional T flag controls whether the permissions for the privileged or the unprivileged execution mode are returned. When executed in the secure state the result of this instruction is extended to return the Security Attribution Unit (SAU) and Implementation Defined Attribution Unit (IDAU) configurations at the specific address. The MPU is banked between the two security states. The optional A flag makes the TT instruction read the MPU of the non-secure state when the TT instruction is executed from the secure state. The TT instruction is used to check the access permissions that different security states and privilege levels have on memory at a specified address. You can find more useful information about ARM® TrustZone® , in the following links: https://developer.arm.com/ip-products/security-ip/trustzone https://www.nxp.com/docs/en/application-note/AN12278.pdf http://www.keil.com/appnotes/files/apnt_291.pdf  http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf
View full article
This document introduces how to debug TrustZone project on MCUXpresso IDE.   Use the latest version of MCUXpresso IDE v10.3.1. Project is from SDK_2.5.0_LPCXpresso55S69. Board is LPCXpresso55s69, use the LinkServer debug probe(on board debugger).   Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project. The secure project is stored in SDK_2.5.0_LPCXpresso55S69\boards\lpcxpresso55s69\trustzone_examples\ <application_name> \ cm33_core0 \ <application_name> _s directory. The non-secure project is stored in SDK_2.5.0_LPCXpresso55S69\boards\lpcxpresso55s69\ trustzone_examples\ <application_name> \ cm33_core0 \ <application_name> _ns directory. The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project. In this document, we use “hello_world” as example, this project contains both “hello_world_s” and “hello_world_ns” projects. Unlike Keil or IAR IDE, MCUXpresso IDE can’t debug jump directly from secure project to no-secure project, so we need add the no-secure executable file to secure project debug configuration manually(For this version of MCUXpresso IDE v10.3.1, we need do this step, while for  the later new versions, maybe they support jump directly from secure project to no-secure project ). Steps outline: Import “hello_world_s” and “hello_world_ns” project. Build “hello_world_s” and “hello_world_ns”, without any error. Erase flash. Program no-secure project “ hello_world_ns ”. Kill active debug. Add the location of file “lpcxpresso55s69_hello_world_ns.axf” to Debugger commands of “hello_world_s” project, and download “hello_world_s” project. After finish download, it stop at “hello_world_s” project, set a breakpoint at “ hello_world_ns ” project: Debug project Detailed steps please refer to DOC in attachment. Hope it helps, BR Alice
View full article