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

Hi: Since LPC series ADC has sequence function, so implement multi-channel ADC transfer is easy. But use DMA is also meaning, so there are two demos to show how to use such applications 1.lpc_multi-channels_adc_dma_sw_trg Use SW trigger multi channels ADC transfer, but use DMA to transfer result to result array. use don't need to care the channel result register, but fetch data from global data register; 2.lpc_multi-channels_adc_dma_hw_trg for many cases, user need to trigger ADC multi channels transfer periodly, and collect enough data for processing. so this demo use SCT_OUT7 to trigger ADC Sequence A for 6 channels, then after 1024 rounds, generate DMA interrupt to process all 6*1024 data array. all demos are implemented on SDK2.6.0 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2019/05/05/trustzone-with-armv8-m-and-the-nxp-lpc55s69-evk

[中文翻译版] 见附件   原文链接： https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/02/26/lpc55xx-multicore-applications-with-mcuxpresso-ide

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-341477

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版本区别进阶

Hello I have worked on Eclipse for developing applications. I am using NXP's  LPC1769 chip. I have made a documentation on setting up an Eclipse environment.Initially I worked on two basic projects i.e. GPIO toggling and Seven segment display. For running any application ,environment setup is is very important. In this documentation, I have mentioned some links and videos which worked for me. For setting up eclipse environment you need to set up tool chains and paths properly otherwise it will show path errors while compiling any project. Hope it would be helpful!

[中文翻译版] 见附件 原文链接： https://community.nxp.com/docs/DOC-342406

[中文翻译版] 见附件 原文链接： https://community.nxp.com/docs/DOC-343506

In newer version of LPC Boot ROM , checksum is added in location 7 ( offset 0x0000001C in vector table ) of Boot ROM. For some LPC device, for example LPC8N04, older Boot ROM version 0.12 (equipped in Rev B board) doesn’t contain checksum but newer version 0.14( equipped in Rev C board ) adds it. Boot ROM checksum is a criteria for valid user code. Bootloader can jump to user code only when detects checksum value correct. Otherwise, it stays at boot code.   Scenario: User may have this annoying problem: the program runs well if download code to LPC flash with debugger. However power off and on again, the code won’t run any more. If you also experience same in field, you may consider the possibility of Boot ROM checksum failed. This document tells how overcome this problem. 1. calculate checksum value by hand 2. calculate checksum value with Keil elfdwt.exe For detail, see attached article.

Some processors in LPC family have EMC, which enable customer to connect external parallel SRAM, NOR flash, SDRAM, there is application which saves code in serial flash for example SPI flash or IIC flash, copy the code to SDRAM and run code in SDRAM. This is a simple code to demo how to run the code in SDRAM, the Code is developed under the SDRAM example code with SDK package, which initialize SDRAM and write data to SDRAM, read the data from SDRAM, compare whether the writing data and reading data are the same. A simple function void LED_Toggle(void) is used to toggle a LED, the API function is copied to SDRAM with the function void mem2mem(uint16_t *sourceAdd,uint16_t *destinationAdd,uint16_t length), after the function is called, an function pointer is defined and jump to the function pointer. BTW, if user would like to run code in SDRAM, the MPU module for the Cortex-M4 has to be initialized, which enable the code in SDRAM to be fetched and executed. The Demo code is developed under MCUXpresso ver10.3.1 and LPCXpresso546xx board(OM40003). after you Run code, the LED2 can toggle on LPCXpresso546xx board.. I list the main code here. All the project is attached. void mem2mem(uint16_t *sourceAdd,uint16_t *destinationAdd,uint16_t length) {     sourceAdd = (uint16_t *)((uint32_t)sourceAdd & (0xFFFFFFFE));     destinationAdd=(uint16_t *)((uint32_t)destinationAdd & 0xFFFFFFFE);     for(uint16_t i=0; i<length; i++)     {         destinationAdd[i]=sourceAdd[i];     }     __DSB();     __ISB(); } #define SDRAM_BASE_ADDR_CODE 0xa0000001 typedef void (*functionPointer)(void); //The PC value must be an odd value although the code address is an even //value void runCodeInSDRAM(void) {     ((functionPointer)SDRAM_BASE_ADDR_CODE)(); } void LED_Toggle(void) {     while(1)     {         delay_1();         GPIO->NOT[3]|=1<<3;     } } void MPU_Init(void) {     //disable MPU     MPU->CTRL=0x00;     //Region0: default region 0     MPU->RBAR=0x00000010;     MPU->RASR=0x1004003f;     //Region 1:     //set up flash, ROM, SRAM ... as region 1     //# 0x00000000 - 0x3FFFFFFF     MPU->RBAR=0x00000011;     MPU->RASR=0x0306E23b;     //Region 2:     //set up peripheral device     //# 0x40000000 - 0x400FFFFF     MPU->RBAR=0x40000012;     MPU->RASR=0x13050033;     //Region 3:     //set up chip select and device     //# 0x80000000 - 0x9000FFFF     MPU->RBAR=0x80000013;     MPU->RASR=0x1305001f;     //Region 4:     //set up SDRAM     //# # 0xA0000000 - 0xA0FFFFFF     MPU->RBAR=0xa0000014;     MPU->RASR=0x0307002f;     //Region 5:     //set up Cortex-M4 Private Peripheral Bus     //# 0xE0000000 - 0xE00FFFFF     MPU->RBAR=0xe0000015;     MPU->RASR=0x13040027;     //Region 6:     //set up Not used     //# 0xE0000000 - 0xE00FFFFF     MPU->RBAR=0xe0000016;     MPU->RASR=0x00000000;     //Region 7:     //set up stack     //#     MPU->RBAR=0x1000E017;     MPU->RASR=0x10060009;     //enable MPU     MPU->CTRL=0x01; } int main(void) {     uint32_t index;     uint32_t *sdram = (uint32_t *)SDRAM_BASE_ADDR; /* SDRAM start address. */     /* Hardware Initialization */     CLOCK_EnableClock(kCLOCK_InputMux);     /* attach 12 MHz clock to FLEXCOMM0 (debug console) */     CLOCK_AttachClk(BOARD_DEBUG_UART_CLK_ATTACH);     BOARD_InitPins();     BOARD_BootClockFROHF96M();     BOARD_InitDebugConsole();     LEDInit();     //LED_Toggle();     BOARD_InitSDRAM();     MPU_Init();     mem2mem((uint16_t *)LED_Toggle,(uint16_t *)SDRAM_BASE_ADDR_CODE,400);    // LED_Toggle();     runCodeInSDRAM(); }

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.

Test Elapsed time based on CTimer module   Sometimes, It is required to test the time which an api function takes when the function is executed, for example, some users want to test the flash erasing time and flash programming time. User can use GPIO to set/clear and use scope to test the GPIO timing to measure the time an api function takes, the method is very simple and straightforward but inaccurate. The document describes to configure CTimer as a 32bits  free-running counter, user can read the counter value before and after an api function and compute the counter value difference to get the time the api function takes. The CTimer of LPC54xxx family counts the APB bus clock, the APB bus clock Is driven by 12 MHz FRO, user can use the following code to measure the elapsed time. For example, we test the elaped time of  delayTimer(10000); function, we get the variable tPoint1, tPoint2. The actual time is (tPoint2- tPoint1)*(1/12000000). In the example, the tPoint2=110127, the tPoint1=53, the elapsed time is (110127-53)*(1/12000000)=9.172us. //the souce code focuses on LPC54xxx family uint32_t tPoint1,tPoint2,tPoint3,tDiff; void test(void) {     tPoint1=CTIMER_GetTimerCountValue(CTIMER2);     //simulate elapsed time     delayTimer(10000);     tPoint2=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint2-tPoint1;       //simulate elapsed time     delayTimer(20000);     tPoint3=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint3-tPoint2;      PRINTF("Time instand:tPoint1=%d, tPoint2=%d, tPoint3=%d \r\n",tPoint1,tPoint2,tPoint3); } Snippet of simple source code based on MCUXpresso tools and LPC54618 board developed by XiangJun Rong #include "fsl_ctimer.h" void test(void); void CTimerInit(void); void delayTimer(uint32_t elapsedTimer); uint32_t tPoint1,tPoint2,tPoint3,tDiff; void CTimerInit(void) {     ctimer_config_t config;     ctimer_match_config_t matchConfig;     /*CTimer use APB bus clock as Timer tick, set the APB bus clock as 12MHz internal FRO */      CLOCK_AttachClk(kFRO12M_to_ASYNC_APB);     CTIMER_GetDefaultConfig(&config);       CTIMER_Init(CTIMER2, &config);       matchConfig.enableCounterReset = true;     matchConfig.enableCounterStop = false;     matchConfig.matchValue = 0xFFFFFFFF;     matchConfig.outControl = kCTIMER_Output_NoAction;     matchConfig.outPinInitState = true;     matchConfig.enableInterrupt = false;     CTIMER_SetupMatch(CTIMER2, kCTIMER_Match_3, &matchConfig);     CTIMER_StartTimer(CTIMER2); }   void test(void) {     tPoint1=CTIMER_GetTimerCountValue(CTIMER2);     //simulate elapsed time     delayTimer(10000);     tPoint2=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint2-tPoint1;       //simulate elapsed time     delayTimer(20000);     tPoint3=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint3-tPoint2;      PRINTF("Time instand:tPoint1=%d, tPoint2=%d, tPoint3=%d \r\n",tPoint1,tPoint2,tPoint3); }   void delayTimer(uint32_t elapsedTimer) {     uint32_t i;     for(i=0; i<elapsedTimer; i++)     {         __asm("nop");     } }   int main(void) {    …………………………………………………………………………………………………..     PRINTF("Elapse time test start: \r\n");     CTimerInit();     test();     for(;;) {} ………………………………………… }  

The MCUXpresso IDE SWO trace function is a special feature which enables user to observe variable update, interrupt entry/exit timing, interrupt event statistic, to print information in SWO ITM Console while the MCU is running. The MCUXpresso IDE SWO trace function is a supplement to the debugger of the MCUXpresso IDE. The main advantage is to display variable, print information, list interrupt entrying/exitting/returing while the MCU is running.  The documentation describes the hardware connection to implement the SWO function, MCUXpresso configuration and source code to implement the function. 

The following document contains a list of documents, questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in LPC or MCUXpresso you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table  FAQ: MCUXpresso Software and Tools  How to create a new LPC project using LPCOpen and MCUXpresso IDE  Introducing MCUXpresso SDK v.2 for LPC54xxx Series  Generating a downloadable MCUXpresso SDK v.2 package  Using the MCUXpresso Pins Tool   MCUXpresso Config Tools is now available!   LPC55xx Multicore Applications with MCUXpresso IDE  LPC information LPC5460x MCU Family Overview  USB with NXP Microcontrollers LWIP memory requirements  LPC800 Four-Part Webinar Series!  The LPC804 Programmable Logic Unit (PLU)   LPC84x Technical Training - Now Available Guides and Examples Flashing and Installing the new firmware and drivers for LPC11U35 debug probes  Enabling debug output  USB FLASH download, programming, and security tool (DFUSec)  DMA Ping-Pong application  Getting start with LPCXpresso54608 &amp; emWin Graphics;  Capacitive Touch example using the LPC845 Breakout Board  OLED Display Application Example using LPC845 Breakout Board and SPI  Mixed-Signal Logic Analyzer &amp; Oscilloscope (Lab Tool) Solution  LPC FAQ How to calculate the value of crystal load capacitors? Can I send a message with X/Y/Z bits in the ID?  What is the difference between error active and error passive? What is the sample point for?  How can I verify the configured CAN bitrate, using an oscilloscope? 

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

LPCXpresso804 board has a on-board debugger developed with LPC11U35. Old batches of the board uses the old firmware for LPC11U35 debugger. The old firmware has some issues such as that when you send a string through the debug COM port the LPC804 only can receive the first byte. The solution is easy. We can download the newest firmware for LPC11U35 and update the firmware for LPC11U35. Download the fimware. The firmware and driver can be download from this link. Update the firmware.(Details can be found in UM11083: User Manual for LPCXpresso804 Board) Hold down the reset button and keep it held down while applying power to the board. Release reset. Using File Explorer (or equivalent on Mac/Linux platforms), look at the available drives on your system. A device called CRP_DISABLED will appear. Delete the firmware.bin file on the CRP_DISABLED drive. Drag and drop the firmware.bin file you downloaded from nxp.com on to the CRP_DISABLED drive. Re-power the board. The board should now enumerate on your system - allow 20-30 seconds for this to complete.

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

This is a quick introduction that shows how to interface the LPC845 Breakout Board with an OLED display based on the popular SSD1306 controller, using SDK drivers for SPI. With this application, you can print a text string or draw a bitmap image.   SPI Protocol The Serial Peripheral Interface (SPI) protocol is asynchronous serial data standard, primarily used to allow a microprocessor to communicate with other microprocessors or ICs such as memories, liquid crystal diodes (LCD), analog-to-digital converter subsystems, etc.   The SPI is a very simple synchronous serial data, master/slave protocol based on four lines:       • Clock line (SCLK)       • Serial output (MOSI)       • Serial input (MISO)       • Slave select (SS)   Adafruit Monochrome OLED Graphical Display This display is made of 128x64 individual white OLED pixels, each one is turned on or off by the controller chip. Because the display makes its own light, no backlight is required. This reduces the power required to run the OLED and is why the display has such high contrast; we really like this miniature display for its crispness!     OLED Display Example NXP provides an example package for the LPC845 Breakout that includes projects to use the principal's peripherals that the board include: ADC, I2C, PWM, USART, Captouch, and SPI   What we need: LPC845 Breakout Board MCUXpresso IDE V10.3.0 SDK_2.5.0_LPC845 NXP example package OLED Display from Adafruit (also available via NXP distributors) LCD assistant software to convert bitmaps Micro USB cable   Once downloaded, we import the library project into the workspace using the ''Import project(s) from file system... from the Quickstart panel in MCUXpresso IDE: Figure 1. Import Projects.   Then browse the examples packages archive file: Figure 2. Select Example Package.   Press next, and see that are a selection of projects to import, in this case, only keep select the LPC845_BoB_OLED how it looks in the picture below: Figure 3. Select the OLED Project.   Press finish and the project example shows up in the workspace: Figure 4. OLED Project in workspace. Create Bitmaps Bitmap (BMP) is an image file format that can be used to create and store computer graphics. A bitmap file displays a small dots in a pattern that, when viewed from afar, creates an overall image. A bitmap image is a grid made of rows and columns where a specific cell is given a value that fills it in or leaves it blank, thus creating an image out of the data. First, you have to create the image using any kind of graphics software such a paint, Photoshop, etc and save the picture as Monochrome Bitmap (bmp), make sure that the image size match whit the OLED size.       Figure 5. Save picture as Bitmap.   Now inside the LCD software assistant, this program will help us to convert an image from Bitmap to data array, we have to load the image by click on file >> load image, and select the appropriate size.   Figure 6. LCD Assistant    To import the array go to file >> save the output, choose the place where are going to save. Then inside the example, go to fsl_Font5x7.h and paste the array.   Figure 7. Data Array.      *Note: Inside the example, the array for the NXP logo is already there, if you want another image, delete this array and pas the new.   Connections Now, with the project already in the workspace, it is time to set up the connection between the LPC845 Breakout board and the OLED Display. The table below shows which LPC845 Breakout pin are routed each line of the SPI interface and the pins for reset and Data/Command select.   Table 1. Connections.   You can check the Datasheet of the board, of bases on the picture below to see where the pin are, note that GND and 3.3V also needed for the OLED display: Figure 8. LPC845 Breakout to OLED Connection.   Debug. Now, with the demo in the workspace and the connections done, connect a micro USB cable from connector CN2 to a host computer and debug the application.   Figure 9. Run example

This is a quick introduction that shows how to interface a popular GPS module to the LPC845 Breakout Board using the UART drivers from the MCUXpresso SDK. This example reads and parses GPS data from the module when the user button is pressed and outputs the information to a host computer console via the board's VCOM interface.    UART Protocol The UART function uses two TPU channels to provide a 2-wire (TxD and RxD) asynchronous serial interface. One TPU channel is configured to function as the serial transmitter (TxD), and another TPU channel is configured to function as a serial receiver (RxD).    Adafruit Flora Wearable GPS The module used for this example is built around the MTK3339 chipset, a no-nonsense, high-quality GPS module that can track up to 22 satellites on 66 channels, has an excellent high-sensitivity receiver. It can do up to 10 location updates a second for high speed, high sensitivity logging or tracking. Power usage is very low, only 20 mA during navigation. Adafruit took this module and mounted it on one of their super-compact Flora boards, which are very easy to connect up to the LPC845 Breakout:     Figure 1. Flora Wearable GPS.   GPS Module Example NXP provides example packages that include projects to use the principal's peripherals that the board include: ADC, I2C, PWM, USART, Captouch, and SPI.   What we need: LPC845 Breakout Board MCUXpresso IDE V10.3.0 SDK_2.5.0_LPC845 NXP example packages Adafruit Flora Wearable GPS Micro USB cable   Once downloaded, we import the library project into the workspace using the ''Import project(s) from file system... from the Quickstart panel in MCUXpresso IDE:     Figure 2. Import projects   Then browse the examples packages archive file:     Figure 3. Select Example package.   Press next, and see that are a selection of projects to import, in this case, only keep select the LPC845_BoB_GPS how it looks in the picture below:     Figure 4. Select GPS project   Connections Now, with the project already in the workspace is time to set up the connection between the LPC845 Breakout board and the GPS module, as shown in the table below:     Table 1. LPC845 to GPS module.   The Flora module has the signals clearly printed on their silkscreen which really helps .     Figure 5. LPC845 Breakout Board to GPS module connections.   Once the connections are made, its time to build and run the example code, use the build and debug button inside the IDE. Now open a terminal program and connect to the COM port the board enumerated as. Configure the terminal with these settings:  115200 baud rate.   No parity.  8 data bits  1 stop bit   Place the GPS module outside. Once the GPS has located the satellite data, the red LED on the GPS will stop blinking. If you see the LED blinking once a second, it does not yet have a fix! It can take many minutes to get a fix if the module sees any satellites immediately. Once it has a fix, press the user button (K1) to display the GPS data in the serial monitor, which includes the current date and time in UTC. It will also give you your latitude, longitude and approximate altitude with the Serial monitor. Figure 6. GPS Print Out.