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
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
At the time of the latest update to this article, the latest silicon revision of the LPC55S6x is revision 1B. Since Nov,2019, all the LPCXpresso55S69 EVK boards marked as Revision A2 or A3 are equipped with revision 1B silicon. Initial production boards that have 0A silicon installed are marked Revision A1.                                     NXP introduced its new debug session request functionality on silicon revision 1B. For some IDE versions, the method of initiating a debug session is designed for current 1B silicon revisions and will r esult in an endless loop when used on older revision 0A parts due to the older revision not implementing some aspects of the handshake protocol. The protocol for this debug connection method, including handling of both 0A and later silicon revisions correctly, is included in the latest LPC55S6x/S2x/2x User Manual, section Debug session protocol.   IDE Considerations MCUXpresso IDE MCUXpresso IDE v11.0.1, incorrectly only supports silicon revision 1B debug session requests and cannot silicon to revision 0A parts in some situations. When connecting LPCXpresso55S69 Revision A1 board, you may have connection error like this: NXP released an MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix1 for this issue. Please follow the steps to fix the issue below if you have to use IDE v11.0.1 with silicon revision 0A; however it is recommended to update to the latest version of the IDE instead of taking this approach: https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/10/30/mcuxpresso-ide-v1101-lpc55xx-debug-hotfix IAR According to our test: IAR Embedded Workbench for ARM v8.42 and later can support both silicon revision 1B and 0A production without issue, which can be downloaded from https://www.iar.com/iar-embedded-workbench/tools-for-arm/arm-cortex-m-edition/ Note: The IAR 8.50.5 changed the CMSIS-DAP debug support for trustzone feature. There is known debug issue with the combination of IAR 8.50.5+SDK2.8.0. Thus our recommendation is:         Use IAR 8.50.5 with SDK2.8.0       Use IAR 8.40.2 with SDK 2.7.1   Keil MDK Both Keil MDK v5.28 and v5.29+ latest LPC55S69 pack v12.01 can support silicon revision 1B without problem but cannot support silicon revision 0A. LPC55S69 Revision 0A vs. 1B differences summary Silicon Revision 0A production 1B production Board Revision A1 A2 Deliver Date Before Nov,2019 After Nov,2019 Debug Access handshake Supported but not required. Handshake signaling partially supported Required Secure Boot Revision SB2.0 SB2.1 Maximum CPU Frequency 100MHz 150MHz IDE revision required 1.      MCUXpresso IDE v11.0.0 and older 2.      MCUXpresso IDE v11.0.1 + hotfix 1 3.      MCUXpresso IDE 11.1 and later MCUXpresso IDE v11.0.0 and newer SDK version SDK2.5 and newer are supported; SDK2.6.3 and newer are recommended SDK2.6.3 and newer     LPC55S69 Defect Fix: 0A vs. 1B 0A Production 1B Production Defect : For PRINCE encrypted region, partial erase cannot be performed Fixed Defect : For PUF based key provisioning, a reset must be performed Fixed Defect : Unprotected sub regions in PRINCE defined regions cannot be used. Fixed Defect : Last page of image is erased when simultaneously programming the signed image and CFPA region Fixed Defect : PHY does not auto-power down in suspend mode Fixed For more detail, see Errata sheet LPC55S6x which can be downloaded  from NXP web site.   Pre-production Silicon: Note that NO BOARDS WERE EVER SOLD THROUGH DISTRIBUTION WITH PRE-PRODUCTION SILICON. In case you have board marked with Revision 1, 2 ,A, or A1 board with 1B silicon, contact NXP to ask for production replacement.   Get Silicon Revision: The silicon revision info is marked on the chip and board revision is marked on the board silkscreen. For silicon revision marking information, please consult LPC55S6x Data Sheet section 4. Marking . Below is an example of silicon revision marking information where revision is highlighted in red: The user application can also get the silicon revision through chip revision ID and number: SYSCON->DIEID:     The English and Chinese version documents are attached.  
View full article
Recently I have several customers experience HardFault error when perform AHB FLASH memory read on LPC55S69. If a FLASH sector has never been programed after mass erase, performing AHB reads of the FLASH memory contents will cause a hardware fault if an unrecoverable error is detected. Why? LPC55Sxx parts are delivered from the factory mass erased with ECC unset. When MCUXpresso IDE connects a chip via LinkServer, it will firstly erase the sectors that will be used for the image being programed, then program the code with a correct ECC set. The sectors beyond the end of the image will be left unchanged, which keep in “erased” states without ECC set on them.   When LPC55Sxx executes FLASH read code ( for example, mytemp = *( uint32_t *)0x4000 ) through AHB bus, it checks FLASH ECC while AHB read. No issue to read programed sectors because ECC has already set. But, read unprogrammed sectors with invalid ECC values leads to fail to read and go to HardFault_Handler as below: If performing AHB reads of the flash memory contents AFTER a sector erase, we will have the same HardFault issue. Solutions There are two solutions to fix the error. 1. Read FLASH Content after Programing the FLASH Sector Unlike mass erasing, programing FLASH updates the related ECC value. Thus with a successful ECC check, read AHB can be realizable by below code. volatile uint32_t mytemp ; …… mytemp = * ( uint32_t * ) 0x1000 ; //read memory content 0x1000 to mytemp‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ NOTE: 0x1000 MUST be a “programed” address. If the unused FLASH sector is in “erased” state, in order to read it, we need manually program it before AHB read. FLASH programming demo code can be referred in flashiap demo under MCUXpresso SDK package. See function FLASH_Program. 2. Read FLASH Content Using FLASH Controller Command Read operations using FLASH controller commands (See UM11126 Section “Command listing (CMD)” ) will not cause hard fault. This is the UM recommended method of read FLASH content. Note: Flash operations (erase, blank check, program) and reading a single word can only be performed for CPU frequencies of up to 100 MHz. These operations cannot be performed for frequencies above 100 MHz. So far I haven’t found a FLASH read demo code. Please follow below steps to create your demos. Environment: IDE: MCUXpresso IDE v11.1.0 SDK MCUXpresso SDK v2.7.0 Steps: See attached document. Thanks for the suggestion from  Alex Yang  and andybeeson‌
View full article
Unboxing of the Mini-Monkey.    This was a demonstration of how you can use a low cost 2-layer PCB process with the LP55S69 in the 0.5mm pitch VFBGA98 package.    We used Macrofab for the prototypes and the results were fabulous. Blog articles on the Mini-Monkey: https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2020/03/13/mini-monkey-part-1-how-to-design-with-the-lpc55s69-in-the-vfbga98-package https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2020/03/29/mini-monkey-part-2-using-mcuxpresso-to-accelerate-the-pcb-design-process https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2020/04/19/lpc55s69-mini-monkey-build-update-off-to-fabrication
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
Introduction Amazon Web Services (AWS) is the world’s most comprehensive and broadly adopted cloud platform, offering over 165 fully-featured services from data centers globally. Millions of customers —including the fastest-growing startups, largest enterprises, and leading government agencies—trust AWS to power their infrastructure, become more agile, and lower costs.This document will take you step-by-step in a simple approach to adding peripherals to your AWS IOT and Alexa skills project. This is in continuation of the demo established in the following link, it is important to have this completed before continuing with this guide: Connecting the LPC55S69 to Amazon Web Services  Prerequisites - LPC55S69-EVK - Mikroe WiFi 10 Click - AWS Account - Alexa Developer Account - MCUXpresso IDE 11.2 - LPC55S69 SDK 2.8.0 Modifying "AWS_REMOTE_CONTROL_WIFI" In this example I will be adding a single-ended ADC peripheral. 1. First, create a separate .c and .h files in my source folder to keep it organized.  2. Initialize your peripheral. This includes your global variables, pins, clocks, interrupt handlers and other necessary peripheral configurations yours may have.  In my new_peripherals.c file, I add the following 2.1 Definitions: 2.2 Global variables: 2.3 Interrupt handler: 2.4 Initialization function: 2.5 Read ADC Function: 3.  Create header file with the two functions that will be used to enable the ADC, make sure to include the "fsl_lpadc"drivers. 4.  Add the ADC pin with pin configuration tool.  4.1 In this example I use PIO0_23 for the ADC0 Channel 0, 5. Add ADC_Init function to the main. 6. Now let's go ahead and modify "remote_control.c". Here we need to build the JSON text that we want updating our Thing's shadow with the ADC value, add the read function, add the variable in the initial shadow document and the keyword for our DeltaJSON. 6.1 First create global variables for the actual state of the ADC interaction and the parsed state. 6.2 Add external function which will read the ADC value. 6.3 Shadows use   JSON shadow documents   to store and retrieve data. A shadow’s document contains a state property that describes these aspects of the device’s state: desired: Apps specify the desired states of device properties by updating the desired object. reported: Devices report their current state in the reported object. delta: AWS IoT reports differences between the desired and the reported state in the delta object. 6.4 I've added the initial ADC state with a hard-coded 0, so that I can verify my Thing's shadow is initialized with the new information. 6.5 In the "void processShadowDeltaJSON(char *json, uint32_t jsonLength)" function, we need to add the condition for the change in state of the ADC. This will helps us identify when the action to read the ADC is requested. 6.6 Finally in the "prvShadowMainTask" function, we will create the action based on the above request. We can add some PRINTFs so that we know that the action is requested and processed properly through the serial console. As you may see I only want to update the ADC value when it is requested. Meaning the value of the ADC's state or parsed state is important. We will clear it to zero after we read the ADC and only update the value when it is 1. As opposed to the LEDState and parsedLEDState, where the value is important since it points to which color LED will be on/off. That's it you can build and run the project! Now we can add the Alexa Skill and the functionality in the AWS Lambda. MODIFYING AWS LAMBDA Since the lambda will be the connection between our LPCXpresso board and the Alexa Skill, we need to add the handler for  our new ADC requests. 1.  In this example we add the third request type which is the ADC event and the name of the callback function we will use.  2. The callback function "manage_ADC_request" will contain the attributes for reading and updating the shadow, this will consequently cause the change in delta shadow so our LPC55S69 will read the ADC pin. In addition, the utterances sent to the Alexa skill as well as how we want Alexa to respond will also be defined here.  As you may observe our function builds the JSON payload to update the shadow with a "1" when it is called and ignores the led and accelerometer values. We delay for 2.5 seconds to allow the LPC to read and write the ADC value in the necessary field and send the updated shadow. Then the Lambda will read the shadow and create the return message.  With this we construct the answer for Alexa. MODIFYING ALEXA SKILLS 1.  First create a custom 'intent'. Here is the general definition of what the utterances will be to request an action from the AWS Thing.    1.1 The name needs to match the name used for the event in the Lambda. In this example it is ADC_INTENT 2. Before we create the utterances, let's create the slot types. This is the list of all the words possible that may come to mind that a user might say to request a reading from the ADC.  2.1 The name of the slot type is not crucial, however please note it as we will need it later.  2.2 Add slot values. You can add as many as you think are necessary. For recommendations on custom slot values please check, best practices for sample utterances. 2.3 Go back to the general view of the ADC_INTENT, scroll down and we will add how the slot will be included in the utterances. In this example I use adc_name, however the name here is also not crucial. Select the slot type list we created earlier. 2.4 Now scroll back up and lets begin adding the sample utterances. This can be any command that you believe a user can say to invoke this action. You do not need to include the wake word here. In brackets add the name of your intent slot, in this case it is {adc_name}. That's it! You can save and rebuild the model. You are now ready to test it. You can do so through the 'Test' tab on the developer's console. In addition if you have an Alexa device or the SLN-ALEXA-IOT, you can test it by speaking with Alexa directly. In your LPCXpresso55S69 you can connect the 3.3V or the 0V to the ADC pin so you can see how the value is returned every request. 
View full article
This document describes the different source clocks and the main modules that manage which clock source is used to derive the system clocks that exists on  LPC’s devices. It’s important to know the different clock sources available on our devices, modifying the default clock configuration may have different purposes since increasing the processor performance, achieving specific baud rates for serial communications, power saving, or simply getting a known base reference for a clock timer. The hardware used for this document is the following: LPC: LPCXpresso55S69 Keep in mind that the described hardware and management clock modules in this document are a general overview of the different platforms and the devices listed above are used as a reference example, some terms and hardware modules functionality may vary between devices of the same platform. For more detailed information about the device hardware modules, please refer to your specific device Reference Manual. LPC platforms The System Control Block (SYSCON) facilitates the clock generation in the LPC platforms, many clocking variations are possible and the maximum clock frequency for an LPC55S6x platform is @150MHz. For example, the LPC55S69 device supports 2 external and 3 internal clock sources. ·     External Clock Sources    Crystal oscillator with an operating frequency of 1 MHz to 32   MHz.    RTC Crystal oscillator with 32.768 kHz operating frequency.   ·    Internal Clock Sources Internal Free Running Oscillator (FRO).   This oscillator provides a selectable 96 MHz output, and a 12 MHz output (divided down from the selected higher frequency) that can be used as a system clock. These 96MHz and 12MHz output frequencies come from a Free Running Oscillator of 192MHz. The 12MHz output provides the default clock at reset and provides a clean system clock shortly after the supply pins reach operating voltage. Note that the 96MHz clock can only be used for a USB device and is not reliable for USB host timing requirements of the data signaling rate.   32 kHz Internal Free Running Oscillator FRO. The FRO is trimmed to +/- 2% accuracy over the entire voltage and temperature range. This FRO can be enabled in several power-down modes such as Deep-Sleep mode, Power-Down mode, and Deep power-down mode, also is used as a clock source for the 32-bit Real-time clock (RTC).   Internal low power oscillator (FRO 1 MHz). The accuracy of this clock is limited to +/- 15% over temperature, voltage, and silicon processing variations after trimming made during assembly. This FRO can be enabled in Deep-Sleep mode, used as a clock source for the PLL0 & PLL1, and for the WWDT(Windowed Watchdog Timer). The LPC55S69 can achieve up to 150MHz but the clock sources are slower than the final System Clock frequency (@150MHz), inside the SYSCON block two Phase Loop Locked (PLL0 & PLL1) allow CPU operation up to the maximum CPU rate without the need for a high-frequency external clock. These PLLs can run from the Internal FRO @12 MHz, the external oscillator, internal FRO @1 MHz, or the 32.768 kHz RTC oscillator. These multiple source clocks fit with the required PLL frequency thanks to the wide input frequency range of 2kHz to 150   MHz.   The PLLs can be enabled or disabled by software. The following diagram shows a high-level description of the possible internal and external clock sources, the interaction with the SYSCON block, and the PLL modules.     Figure   1 . General SYSCON diagram   SYSCON manages the clock sources that will be used for the main clock, system clock, and peripherals. A clock source is selected and depending on the application to develop the PLL modules are used and configured to perform the desired clock frequency. Also, the SYSCON module has several clock multiplexors for each peripheral of the board   i.e ( Systick ,   FullSpeed -USB,   CTimer ), so each peripheral can select its source clock regardless of the clock source selection of other peripherals. For example, the following figure shows these described multiplexers and all the possible clock sources that can be used at the specific module.   Figure  2 . Source clock selection for peripherals   For more detailed information, refer to “Chapter 4. System Control (SYSCON)” from the   LPC55S6x User Manual.  Example:   Enabling/Disabling PLLs The Clock tools available in MCUXpresso IDE, allows you to understand and configure the clock source for the peripherals in the platform. The following diagram shows the default PLL mode configured @150MHz, the yellow path shows all the internal modules involved in the clock configuration. Figure  3 . Default PLL mode @150MHz at Reset of LPC55S69   For example, you can use the Clock tools to configure the clock source of the PLL to use the   clk_in   coming from the internal 32MHz crystal oscillator, the PLL is configured in bypass mode, therefore the PLL gets inactive resulting in power saving. Figure  4 . Bypass of the PLL For more detailed information about PLL configuration, refer to “Chapter 4.6.6. PLL0 and PLL1 functional description” from the   LPC55S6x User Manual.  Example:   The next steps describe how to select a clock source for a specific peripheral using Clock Tools. 1.1   Configure clock for specific peripheral T o configure a peripheral as shown in figure 17, Clock Tools is also useful to configure the clock source for the desired peripheral. For example, using the CTimer0 the available clock sources are the following: Main Clock PLL0 Clock FRO 96MHz Clock   FRO 1MHz Clock MCLK Clock   Oscillator 32KHz Clock No Clock(Inactive)                   Figure 5. CTimer0 Clock Source Selector Select CTIMERCLKSEL0 multiplexor and then switch to one of the mentioned clock sources, for example, the   main_clk (Main Clock @150MHz) the clock multiplexor gets active and the yellow path is highlighted as shown in the following image.     Figure  6 . CTimer0, Main Clock attached 1.2   Export clock configuration to the project After you complete the clock configuration, the Clock Tool will update the source code in   clock_config.c   and   clock_config.h , including all the clock functional groups that we created with the tool. This will include   the clock source for specific peripherals. In the previous example, we configured the CTimer0 to use the   main_clk ; this is translated to the following instruction in source code: “ CLOCK_AttachClk (kMAIN_CLK_to_CTIMER0);” inside the “BOARD_BootClockPLL150M();” function.                         Figure  7 . API called from   clock_config.c   file Note. Remember that before configuring any internal register of a peripheral, its clock source needs to be attached, otherwise, a hard fault occurs. References LPC55S6x/LPC55S2x/LPC552x User Manual Also visit RT's System Clocks Kinetis System Clocks
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
T his article introduces how to create a custom board MCUXpresso SDK and how to use it, mainly includes three parts: Part1: Generating a Board Support Configuration (.mex) Part2: Create a Custom Board SDK Using the Board SDK Wizard Part3. Using the Custom SDK to Create a New Project   Requirements: MCUXpresso IDE v11.1.1, MCUXpresso SDK for LPC845, LPC845-BRK board. This method works for all NXP mcu which support by MCUXpresso SDK. About detail steps, please refer to attachment. Thanks!
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
Introducing the LPC550x/S0x family of MCUs The LPC550x/S0x is an extension of the LPC5500 MCU series based on the Arm® Cortex®-M33 technology, featuring up to 256kB of Flash memory and 96kB of on chip RAM. There are up to 8 Flexcomm (choice of any 8 serial –I2C/UART/SPI) and one dedicated 50MHz SPI, and CAN FD(CAN 2.0 for LPC550x). The dual 16-bit ADC can do two independent conversions simultaneously at 2MSPS, there are up to 10 ADC input channels. The comparator has 5 input pins and an external reference voltage.   LPC55S0x MCUs have the Arm TrustZone® technology support and are powered with a security acceleration engine (CASPER) and Secure ROM to provide the support for RSA base authentication. The on chip Physical Unclonable Function (PUF) uses a dedicated SRAM for silicon fingerprint instead of storing the Root key, which means there is no way to read the root key without powering the device up. It also features a True Random Number Generator (TRNG), AES encryption/decryption engine, 128 bit unique device serial number for identification (UUID) and Secure GPIO.   Powering the System Operating at up to 96MHz, the active power consumption of the LPC550x is only 32uA/MHz. The on chip flash is optimized for low power hence it does not perform well in pure Flash and CPU benchmark like the EEMBC Coremark. However in practice, most applications have relatively slow peripherals like I2C, UART, being the bottleneck.  The MCU’s low power consumption performance means that a lot of power is being saved for the system. In addition, high power efficiency enables the LPC550x devices to run much cooler than most 32-bit MCUs. The on-chip DC-DC gives >85% power conversion efficiency, result in very little energy loss as heat inside the chip. In fact LPC5500 MCU series has <2 deg C self-heating when operating at the max frequency. The highly accurate (+/-2% at full temp range, +/-1% from 0 to 85 deg C) on chip Free Running Oscillator (FRO) provides the 96MHz without the need of addition PLL or external crystal for running UART, reducing power consumption. The simple power modes:  Sleep, deep-sleep with RAM retention, power-down with RAM retention and CPU retention, and deep power-down with RAM retention; Provide user the choice on what to keep alive when going into low power mode. In addition, LPC550x/S0x MCUs can be woken-up from configurable peripherals interrupts like the 32kHz RTC, resulting in more power savings.   Powering the Future The LPC550x/S0x family provide a powerful 32-bit MCU with 256kB Flash, low power (active and leakage) at a price point the current existing Cortex-M33 base MCU in the market cannot meet.   Let the LPC550x/S0x power your next product! Learn more about this family at www.nxp.com/LPC550x. Here's the picture of the LPC55S06 EVK board    
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
Summary A software vulnerability CVE-2021-40154 has been identified in the USB enumeration packet handler, which could leak memory contents if a malformed enumeration request packet is sent to the device. This may occur if the device is configured in the in-system programming (ISP) or serial downloader protocol (SDP) mode or if unpatched USB example code is used in an application.   Mitigations Mitigations have been applied to: The boot ROM in the latest silicon revisions of i.MX RT 500 and 600 and LPC55XX parts USB examples in the MCUXpresso SDK 2.10 release and later For other devices, the ISP/SDP mode and/or the USB communication mode can be disabled.   Affected product list:                 NXP Device     Impacted Silicon Revisions LPC55S6x, LPC55S2x, LPC552x                      0A, 1B LPC55S1x, LPC551x    0A i.MX RT600                                       A0, B0 i.MX RT500                                         B1, B2 i.MX RT1010/20/50/60 i.MX RT1160/70 All K8x/KL8x K27/K28 K32L3/ K32W032 / K32LA/K32LB  KL27/KL28/KL43                                    All   The vulnerability also affects all MCUXpresso SDK USB device stack examples prior to 2.10.x release.  If the NXP device does not support USB or does not utilize the USB example code prior to version 2.10.x  in the application, then those would not be impacted. Additional Information Security bulletins with more details are available. For additional questions or support please contact your local NXP representative or submit a ticket at https://support.nxp.com/ Acknowledgments NXP PSIRT would also like to thank Sulthan Alaudeen Noor Mohamed from Digital14 – xen1thLabs, Hardware Labs for the responsible disclosure. _____________________________________________________________________________ Please note this information is preliminary and subject to change. To the best of NXP's knowledge, the information contained herein is accurate and reliable as of the date of publication; however, NXP does not assume any liability for the accuracy and completeness of the information.   Information in this document is provided solely to enable system and software implementers to use NXP products. There are no express or implied copyright licenses granted hereunder to design or fabricate any integrated circuits based on the information in this document. NXP reserves the right to make changes without further notice to any products herein. NXP makes no warranty, representation, or guarantee regarding the suitability of its products for any particular purpose, nor does NXP assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. “Typical” parameters that may be provided in NXP data sheets and/or specifications can and do vary in different applications, and actual performance may vary over time. All operating parameters, including “typicals,” must be validated for each customer application by customerʼs technical experts. NXP does not convey any license under its patent rights nor the rights of others. NXP sells products pursuant to standard terms and conditions of sale, which can be found at the following address: nxp.com/SalesTermsandConditions. While NXP has implemented advanced security features, all products may be subject to unidentified vulnerabilities. Customers are responsible for the design and operation of their applications and products to reduce the effect of these vulnerabilities on customer's applications and products, and NXP accepts no liability for any vulnerability that is discovered. Customers should implement appropriate design and operating safeguards to minimize the risks associated with their applications and products.
View full article
Previously, I wrote two articles about LPC55xx AHB read ( How to fix AHB Read HardFault Error ) and LPC55xx FLASH alignment ( Why FLASH Program cannot Success?  ). In this article, we will go on investigating LPC55xx erased memory state. For most of NXP MCU, the erased FLASH state is 0xFF. Writing action is to change 1 to 0. However for LPC55, when we perform mass erase or section erase, we see the related memory turns to all 0 in MCUXpresso IDE debugger Memory view. This all-0-erased-status confuses many LPC55 beginners. Is this real memory state? The answer is yes, IDE debugger display is correct. LPC55xx FLASH uses 0x00 as erased value, which is opposite to most of the other FLASH devices which use 0xFF as erased value) There is no way to verify the erased FLASH state with code in runtime. NXP enhanced LPC55xx FLASH with ECC added. This means that there is now a functional block between the read entity (for example the CPU) and the FLASH itself. When erasing, both the erased FLASH and its ECC are set as 0. The reading can’t be successful if the erased memory and its ECC don’t match. Thus we can’t read memory in erased state. AHB read hardfault error is produced if do so.  Because of ECC mechanism, you can't read FLASH until you have written to it. see   How to fix AHB Read HardFault Error The User's Manual mentions the reading and writing operation in UM11126 chapter 5.7.13: When writing, parity is automatically computed and stored alongside user data. When reading, data and parity are used to reconstruct correct data, even in the case of a 1-bit error. When reading an erased location, an uncorrectable error is flagged. Use the “blank check” command to test for successful erase. The LinkServer debug in MCUXpresso IDE takes some precautions to avoid this problem while programming the FLASH before starting a debug session. That’s the reason we can see erased memory state in debugger memory view window, Admittedly, this is something not really pre-eminent in the documentation. The only reference we could spot is in UM11126. See below: “ The selected pages are checked for the erased condition (all 0 including parity)”   Thanks for the valuable comment from Radu Theodor Lazarescu.
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
For the CM33 of LPC55S6x family, the trust zone module is integrated, the memory space and peripherals are classified as security and non-security space. In order to generate interrupt in non-security mode, the NVIC module including the NVIC_ITNSx register must be initialized in security mode so that interrupt module can generate interrupt in non-security mode. The example demos that MRT0 module generates interrupt in non-security mode, the NVIC module is initialized at security mode, MRT0 is initialized at non-security mode. The project is based on MCUXpresso IDE ver11.1 tools, LPC55S69-EVK board and SDK_2.x_LPCXpresso55S69 SDK package version 2.7.1.
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
Symptoms Many LPC55 users experienced connection failure when using ISP USB0 for firmware update. In practice, we don’t suggest user updating firmware via ISP USB0 for LPC55(S)6x/ 2x,LPC55(S)1x/0x parts. Diagnosis LPC55 USB0 is Full Speed USB port. The default setting of CMPA turns off the USB0 port. Some users may reconfigure CMPA to enable ISP USB0 in order to use ISP USB0 BOOT, but this is not recommended in practice. LPC55 ISP USB0 uses internal FRO as clock source. According to LPC55 data sheet, the FRO accuracy is only +-2%, while the FS USB data rate tolerance specification is +-2500ppm(+-0.25%). Obviously, the LPC55 FRO spec can’t meet the USB0 clock accuracy requirement. See below extraction from NXP manuals. Fig 1. The accuracy of FRO ( Extracted from LPC55S69 Datasheet )   Fig 2. The accuracy requirement of USB FS( Extracted from TN00063 )   Some users may wonder why USB0 can use internal FRO as clock source in the user application?  Whenever internal clock source FRO is used as USB0 clock source, we must calibrate FRO in source code for communication. That’s to say, trim FRO to an accurate frequency. We can see FRO trim in many MCUXPressoSDK USB demos. When using FRO as the USB0 clock source, in order to ensure the USB0 clock accuracy, we must use the USB0 SOF frame synchronization to calibrate the FRO in order to ensure the accuracy of FS USB clock source (reference design of TN00063, TN00063-LPC5500 Crystal-less USB Solution). Unfortunately, the BOOT ROM of LPC55 does not support USB SOF calibrating FRO. As a result, even if we enable ISP USB0, the FRO clock drift can still cause USB0 communication failure under non-room temperature conditions. Solution Since ISP USB0 is not recommended for firmware update, the user manual no longer announces the enablement bit of ISP USB0 in CMPA. If you need to use USB0 for firmware update, we recommend using ISP USB1 (High Speed USB), because USB1 uses accurate external clock source which can ensure the ISP USB1 working stable. In addition, the communication protocol of ISPUSB complies with BLHOST specification. For details, see:  blhost User's Guide - NXP  
View full article