LPC Microcontrollers Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC Microcontrollers Knowledge Base

Discussions

Sort by:
INTRODUCTION The goal of this example is to demonstrate basic LIN communication between two devices where one active as Master another as Slave. In this case, the two devices used are LPC55S16 EVK's. LIN master will send a specific publisher frame and a subscriber frame, the LIN slave will detect the master data and feedback the data accordingly. This article will mainly focus on the software side, for hardware please refer https://community.nxp.com/t5/LPC-Microcontrollers-Knowledge/LPC54608-LIN-master-basic-usage-sharing/ta-p/1118103. LIN MASTER EXAMPLE LIN master sends the LIN publisher data and the subscriber ID data, the software code is modified from the SDK_2.8.2_LPCXpresso55S16 usart_interrupt_rb_transfer project, the detailed code is as follows: /* USART callback */ void FLEXCOMM3_IRQHandler() { if(DEMO_USART->STAT & USART_STAT_RXBRK_MASK) // detect LIN break { Lin_BKflag = 1; cnt = 0; state = RECV_DATA; DisableLinBreak; } if((kUSART_RxFifoNotEmptyFlag | kUSART_RxError) & USART_GetStatusFlags(DEMO_USART)) { USART_ClearStatusFlags(DEMO_USART,kUSART_TxError | kUSART_RxError); rxbuff[cnt] = USART_ReadByte(DEMO_USART);; switch(state) { case RECV_SYN: if(0x55 == rxbuff[cnt]) { state = RECV_PID; } else { state = IDLE; DisableLinBreak; } break; case RECV_PID: if(0xAD == rxbuff[cnt]) { state = SEND_DATA; } else if(0XEC == rxbuff[cnt]) { state = RECV_DATA; } else { state = IDLE; DisableLinBreak; } break; case RECV_DATA: Sub_rxbuff[recdatacnt++]= rxbuff[cnt]; if(recdatacnt >= 3) // 2 Bytes data + 1 Bytes checksum { recdatacnt=0; state = RECV_SYN; EnableLinBreak; } break; case SEND_DATA: recdatacnt++; if(recdatacnt >= 4) // 2 Bytes data + 1 Bytes checksum { recdatacnt=0; state = RECV_SYN; EnableLinBreak; } break; default:break; } cnt++; } /* Add for ARM errata 838869, affects Cortex-M4, Cortex-M4F Store immediate overlapping exception return operation might vector to incorrect interrupt */ #if defined __CORTEX_M && (__CORTEX_M == 4U) __DSB(); #endif } void Lin_Master_Publisher(void) { unsigned int i=0; unsigned char ch =0xa0;//dummy byte //===============================LIN master send===================== DEMO_USART->CTL |= USART_CTL_TXBRKEN_MASK;//enable TX break; while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteBlocking(DEMO_USART,&ch,1);//dummy data break; //just send one byte, otherwise, will send 16 bytes } DEMO_USART->CTL &= ~(USART_CTL_TXBRKEN_MASK); //disable TX break // Send the sync byte 0x55. while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X55); break; //just send one byte, otherwise, will send 16 bytes } //protected ID while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0Xad); break; //just send one byte, otherwise, will send 16 bytes } //Data1 while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X01); break; //just send one byte, otherwise, will send 16 bytes } //Data2 while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X02); break; //just send one byte, otherwise, will send 16 bytes } //Data3 while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X03); break; //just send one byte, otherwise, will send 16 bytes } // checksum byte while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X4c);//0X4c break; //just send one byte, otherwise, will send 16 bytes } } void Lin_Master_Subscribe(void) { unsigned int i=0; unsigned char ch=0xf0;//dummy byte DEMO_USART->CTL |= USART_CTL_TXBRKEN_MASK;//enable TX break; while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteBlocking(DEMO_USART,&ch,1); break; //just send one byte, otherwise, will send 16 bytes } DEMO_USART->CTL &= ~(USART_CTL_TXBRKEN_MASK); //disable TX break // Send the syncy byte 0x55. while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X55); break; //just send one byte, otherwise, will send 16 bytes } //protected ID while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X3C); break; //just send one byte, otherwise, will send 16 bytes } state = RECV_DATA; } The main task here was to generate and detect the LIN break field. If one look closely, to generate the LIN break field in publisher and subscriber frame, we first set the Tx break and then send a dummy byte and then disable the Tx break. The function used to send the dummy byte is USART_WriteBlocking whereas USART_WriteByte is used to send data other than dummy byte. This is because if we use USART_WriteByte during dummy byte then it was not a continuous low as in the other case. I still need to find the reason for this, will update here once done.   LIN SLAVE EXAMPLE LIN Slave receives the LIN publisher data and the subscriber ID data from Master and respond back id required, the software code is modified from the SDK_2.8.2_LPCXpresso55S16 usart_interrupt_rb_transfer project, the detailed code is as follows: void FLEXCOMM3_IRQHandler() { if(DEMO_USART->STAT & USART_STAT_RXBRK_MASK) // detect LIN break { Lin_BKflag = 1; cnt = 0; state = RECV_SYN; DisableLinBreak; } if((kUSART_RxFifoNotEmptyFlag | kUSART_RxError) & USART_GetStatusFlags(DEMO_USART)) { USART_ClearStatusFlags(DEMO_USART,kUSART_TxError | kUSART_RxError); rxbuff[cnt] = USART_ReadByte(DEMO_USART);; switch(state) { case RECV_SYN: if(0x55 == rxbuff[cnt]) { state = RECV_PID; } else { state = IDLE; DisableLinBreak; } break; case RECV_PID: if(0xAD == rxbuff[cnt]) { state = RECV_DATA; } else if(0X3C == rxbuff[cnt]) { state = SEND_DATA; senddata(); } else { state = IDLE; DisableLinBreak; } break; case RECV_DATA: recdatacnt++; if(recdatacnt >= 4) // 3 Bytes data + 1 Bytes checksum { recdatacnt=0; state = RECV_SYN; EnableLinBreak; } break; default:break; } cnt++; } /* Add for ARM errata 838869, affects Cortex-M4, Cortex-M4F Store immediate overlapping exception return operation might vector to incorrect interrupt */ #if defined __CORTEX_M && (__CORTEX_M == 4U) __DSB(); #endif } void senddata(void) { { while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X01); break; //just send one byte, otherwise, will send 16 bytes } while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X02); break; //just send one byte, otherwise, will send 16 bytes } while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X10);// 0X10 correct 0Xaa wrong break; //just send one byte, otherwise, will send 16 bytes } recdatacnt=0; state = RECV_SYN; EnableLinBreak; } } In the next revison, I will update the CRO traces of the LIN frames also. Attaching herewith the codes of the Master and Slave. I hope it helps!!
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
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
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
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
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
For LPC55(S)1x/2x/6x users, please update your fsl_power_lib to SDK2.8.2. The previous SDK(2.6.x and 2.7.x)'s power library have two known function bugs,  1. FRO trim value can not be recovery correctly after wakeup from deep-sleep / power-down / deep power-down.    -- this means the 12MHz FRO frequency is different for after boot-process(11.99 MHz for example) and wakeup from low-power modes(11.89MHz for example).     -- The reason is the FRO trim value not recovery after wakeup.  2. Cap-bank value can not be set correctly by use power lib capbank trim API.    -- This is a software bug which fixed in SDK2.8.2 already. Just replacement the power_lib library file should be workable for most of customers. the API should be compatible. Thank you! Magicoe
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
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
https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2020/06/15/lpc55s69-powerquad-part-1-a-great-solution-for-the-industrial-iot-and-smart-metering 
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
Unboxing video of the low cost OKDO E1 board.    As a quick demo, I hooked up the E1 to a low cost  240x240 Pixel IPS display from buydisplay.com.
View full article
The Economist Intelligence Unit’s (EIU) 2020 IoT Index recently highlighted that 2020 will be the year when the Internet of Things (IoT) officially moves from “proof of concept” to “mass deployment”, with over half of all companies surveyed now undergoing early or extensive deployment of internal or external IoT networks. Read more >> NXP and Arm Pelion Device Management Secure Deployment of IoT Devices from Chip to Cloud | Pelion IoT Blog 
View full article
When we use LPC55Sxx PRINCE feature, we need enable PRINCE sub-region “crypto” by setting SR_ENABLE register. If we “crypto” enable discontinuous sub-regions and erase part of them, we may find we can’t erase/read/write other “crypto” sub-regions any more. This article will discuss how to resolve this phenomenon.           Figure 1         Testing Steps According to LPC55Sxx UM, each PRINCE region has its SR_ENABLEx register. This register enables PRINCE encryption and decryption of data for each sub-region of crypto region 0. Each bit in this field enables a sub-region of crypto region 0 at offset 8kB*n, where n is the bit number.  For example, when we set SR_ENABLE0=0X00000005, PRINCE region 0 sub-region 1 and sub-region 3 are set as encryption region. When read data out from these sub-regions, PRINCE will decrypt the data automatically.   Now we will test discontinuous sub-region erase/read/write. Board: LPC55S16-EVK IDE: Keil MDK v5.29 Step 1: PRINCE initialization: Enable PRINCE region 0 and two discontinuous sub-regions; generate key, IV code; enable crypto. //set SR_ENABLE , SR_ENABLE=0X28000000,enable sub-regions(0x30000-0x32000,0x34000-0x36000) crypto 。 status=PRINCE_SetRegionSREnable(PRINCE( prince_region_t )region0,0X28000000); //select PRINCE crypto for region0 PRINCE_SetRegionBaseAddress ( PRINCE_Type *base, prince_region_t region0, uint32_t 0X0) //generate PRINCE region0 crypto key Status=FFR_KeystoreGetKC(&flashInstance,&keyCode[0],kFFR_KeyTypePrinceRegion0); status=PUF_GetHwKey(PUF,keyCode,sizeof(keyCode),kPUF_KeySlot2, rand()); //generate PRINCE region0 crypto IV_code status=PRINCE_GenNewIV(kPRINCE_Region0,&prince_iv_code[0],true,&flashInstance) //load IV code to PRINCE status=PRINCE_LoadIV(kPRINCE_Region0,&prince_iv_code[0]) //enable PRINCE encryption PRINCE_EncryptEnable(PRINCE)   Step 2: Select two discontinuous sub-regions ( 0x30000-0x32000,0x34000-0x36000). Erase one of them (0x30000-0x32000), then write data to this sub-region. Output: Erasing and Writing are all successful. See Figure 2. //Erase 0x30000-0x32000 sub-region status=PRINCE_FlashEraseWithChecker(&flashInstance,0x30000,0x2000,kFLASH_ApiEraseKey); //Write 0x30000-0x32000 sub-region status=PRINCE_FlashProgramWithChecker(&flashInstance,0x30000,(uint8_t *)prince_iv_code,0x2000);   Step 3: Erase and Write the other sub-region ( 0x34000-0x36000 ) Output: Erasing and Writing are failed. See Figure 2. //Erasing 0x34000-0x36000 sub-region status=PRINCE_FlashEraseWithChecker(&flashInstance,0x34000, 0x2000,kFLASH_ApiEraseKey); //Write 0x34000-0x36000 sub-region status=PRINCE_FlashProgramWithChecker(&flashInstance,0x34000, (uint8_t *)prince_iv_code,0x2000); Error Analysis According to UM11126( 49.16.1 Functional details ) , each crypto region has its own SKEY and IV code. SKEY and IV are used together by the PRINCE when encrypting or decrypting the data in the sub-regions of crypto region. For Instance, For PRINCE region1, each time after we execute erasing operation, new Skey1 and IV1 are generated, thus when executing erase/read/write operation to another sub-region, the old IV1 and new IV1 don’t match, which causes PRINCE can’t decrypt correctly.   Suggestion We suggest user using SR_ENABLE to set continuous crypto sub-regions. When erasing operation is needed, erasing all the crypto sub-regions together, avoid erasing part of the sub-regions. One sub-region size is 8K, make sure the erasing/writing address 8K aligned.   Thanks for the suggestion from johnwu‌
View full article
Abstract This paper discusses our approach to crypto acceleration and asset protection using novel techniques that help bring high levels of security to low-cost microcontrollers with minimal power and area penalty. CASPER, our asymmetric cryptography acceleration engine, aims to optimize crypto algorithm execution (e.g., RSA, ECC). It is built on a hardware-software partitioning scheme where software functions map asymmetric crypto functions to the hardware modules of the accelerator, delivering sufficient flexibility to software routines to enable mapping of new algorithms. Further efficiency is achieved by making use of the co-processor interface on the Arm® Cortex®-M33 core. Important assets such as keys, proprietary and/or licensed application software are protected against side-channel analysis or cloning using SRAM PUF and PRINCE. SRAM PUF technology enables secure storage of root-of-trust keys and user keys by exploiting the deep sub-micron process technology variations. PRINCE is a low-latency lightweight cryptography algorithm implementation in hardware that allows encrypted non-volatile storage and real-time, latency-free decryption of the execution code. Read More >
View full article
View Webinar Recording
View full article
When you are the first time to debug LPC55S69, please read below document and double check your IDE, SDK and EVK version is correct. Usually, we prefer use the latest IDE, SDK and EVK boards. Important updates when using LPCXpresso55S69 Revision A2 boards and 1B silicon  [Problem Description] When you use IAR 8.32 to debug LPC55S69 '1B' silicon, the IDE will remind you " The debugging session could not be started ", like below picture show: The  reason of this failure is that IAR 8.32's LPC55S69 chip configuration files only support revision '0A' silicon, not '1B'. We strongly recommend customer download and use IAR 8.40.2 or latest version. The IAR IDE start support LPC55S68 '1B' silicon from 8.40.2. [Solution] If you have some reasons that must use IAR 8.32, you can download attached zip file. This zip file like a patch, include the IAR LPC55S69 '1B' support files. Un-zip this file and merge the same  files under IAR installed path : IAR\arm\config\flashloader\NXP Then the IAR can support '1B' silicons. [How to identify LPC55(S)6x chip silicon versions] On the top-side marking code, there is '1B'  charactors at the end of mark strings. See below two pictures, the left one is '1B' version chips.                      LPC55(S)6x ver '1B'                                                               LPC55(S)6x ver '0A'                   
View full article