In this document, I will explain how to create a project to use the SPIFI library version 1.03 with the LPC4370. For this we will need the following tools: MCUXpresso IDE 10.2. Link LPC-LINK2 to use it as an evaluation board for the LPC4370. Link External debugger. In my case, I used another LPC-LINK2 board. LPCOpen v2_12 for the LPC4370, this version comes with the installation of MCUXpresso IDE. SPIFI library v1.3. Link Code Example lpcopen_2_12_lpcxpresso_ngx_xplorer_1830_SPIFI_v1.0. Link First, download and install all the tools needed. In your workspace of MCUXpresso we will import (1) three projects of the LPCOpen v2_12 for the LPC4370: periph_blinky, lpc_board_nxp_lpclink2_4370 and lpc_chip_43xx.  The LPCOpen zip file is in the next path of your PC: C:\nxp\MCUXpressoIDE_10.2.1_795\ide\Examples\LPCOpen (2) Extract the files of the zip named lpclibspifi_lpcxpresso_1.03_68 that we downloaded before. The folder that we need is spifilib_m4f. Drag and drop this folder into the Project Explorer on your workspace of the LPC4370, after choosing copy and you should see the spifilib_m4f in your Project Explorer. Once you imported correctly the SPIFI library, select the library (1) on the project explorer window and build it (2). Once you do this you should see that a new folder called Debug appear (3). Now we need to edit the properties of the periph_blinky example to add the library spifilib_m4f to the project. To do this, right click on the project and click properties. Once in the properties window click on C/C++ Build (1) > Settings (2) > Includes (under the section MCU C Compiler) (3). In the includes window click Add… (1) > Workspace (2) > spifilib_m4f (3) > inc (4) > click OK (5) on the window Folder Selection > click OK (6) on the window Add directory path. You should see the following on the include paths. Now, go to the libraries (1) option under the section MCU Linker, on the section Libraries (-I) click Add… (2) finally write the name of the library (spifilib_m4f) (3) and click OK (4). Under the section Library search path (-L) click Add… (1) > Workspace (2) > spifilib_m4f (3) > Debug (4) > OK (5). If you see the same as shown in the below image you are good to go so click Apply and close. To check if you did the below steps correct let’s do the following. On the project periph_blinky in the file systick.c include the file spifilib_api.h and compile the project. If the project compiles without problems it means that you imported correctly the spifi library. If you found problems please stop and repeat all the steps mentioned before. Now that we added successfully the library we can start to migrate the example for the LPC1830 that we download before. First, unzip the file lpcopen_2_12_lpcxpresso_ngx_xplorer_1830_SPIFI_v1.0. Once you unzipped the file go to the following path: spifilib_blinky > example > src. Open the file named Blinky.c and copy all the content of the file. Now go to the file systick.c on your workspace of MCUXpresso within the project periph_blinky, delete all the content of this file and paste what you copied before. Do not compile at this point or you will receive multiple errors! Go back to the path spifilib_blinky > example > src on your PC. Drag and drop the file called spifi_setup.c into the folder src of your project periph_blinky on your Workspace. Open the file that we just copy into our workspace and go to line 46 of the code. Here we are creating a buffer of 64KB that we will use later to write in the SPIFI. The __BSS(RAM3) is to save this buffer in the RAM block three of memory. The problem here is that the block of RAM3 in the LPC4370 is not big enough to store the buffer of 64KB (see below image), so let’s change this for either RAM or RAM2 that are big enough to store the buffer. Now that we added the spifi_setup file let’s go back to the systick.c file and add the external declaration for the function spifiSetUp. At this point, if we compile the project we shouldn’t see any problems, only some warnings because of the functions and variables that we are not using. We are almost done, we are missing the most important thing. With this demo you will be writing, deleting and reading the SPIFI memory, this means that you cannot be executing form the SPIFI flash memory. You need to move to the RAM memory all the functions that are going to make this. This is the reason why in the file systick.c we don’t have any function that interacts directly with the SPIFI, this will make much easier the work of moving all the functions that interact with the SPIFI memory to RAM. The function spifiSetUp is the one that will make all the tests on the SPIFI and it is in the spifi_setup file, so we will need to move this entire file to RAM along with the SPIFI library. We will use three different scripts to move the library and the file spifi_setup to RAM. You can learn more about this in the following community post: https://community.nxp.com/thread/389110. First, right click on the folder of the project > new > folder, the name of the folder must be linkscripts. According to the sections Relocating particular objects into RAM and Relocating particular libraries into RAM of the community post mentioned before we need to create three files in this new folder: main_text.ldt, main_rodata.ldt and main_data.ldt. To do this, right click on the folder linkscripts > new > file. Here is the content that you should have on the three files that we just created. Do not include on the files the text that is in bold, that's just for reference! File main_data.ldt *libspifilib_m4f.a:(.text*) *libspifilib_m4f.a:(.rodata .rodata.* .constdata .constdata.*) *spifi_setup.o(.text*) *spifi_setup.o(.rodata .rodata.* .constdata .constdata.*) . = ALIGN(${text_align}); *(.data*) File main_rodata.ldt *(EXCLUDE_FILE(*libspifilib_m4f.a: *spifi_setup.o) .rodata) *(EXCLUDE_FILE(*libspifilib_m4f.a: *spifi_setup.o) .rodata.*) *(EXCLUDE_FILE(*libspifilib_m4f.a: *spifi_setup.o) .constdata) *(EXCLUDE_FILE(*libspifilib_m4f.a: *spifi_setup.o) .constdata.*) . = ALIGN(${text_align}); File main_text.ldt *(EXCLUDE_FILE(*libspifilib_m4f.a: *spifi_setup.o) .text*) After finishing with the three files you are done with the demo! It’s important to mention that if you want to go inside the function spifiSetUp while debugging you need to set a breakpoint inside the function. While debugging we can see that before calling the function spifiSetUp we are running from the SPIFI flash memory and once we enter to the function we are running from RAM memory. Once we run the demo successfully we should see the following in a terminal and the LED1 will be blinking. Hope this guide is helpful! Best Regards, Victor.

Dear Community User, We recently migrated content from the LPCWare.com forums into this community site. Migrated content can be found in the following two locations: LPCXpresso IDE for content from the LPCXpresso folder on the LPCWare.com forum, and LPC for all other content. All imported content will appear as posted by "LPCWARE" and will have the following message displayed at the top of each thread with the original username and date posted in LPCWare: If you wish to find the content you created in LPCWare you must: 1.-  Open the search box at the top right side of your community near your avatar. 2.- Type in the username you had set up in LPCWare and the results should automatically appear. All responses to postings in the original LPCWare.com forums are also preserved, so if you are looking for a response you or another particular user posted then you should also be able to locate those responses using the same search mechanism. All FAQs have been migrated to the NXP Community site. Several forum postings include references to FAQs and re-directs are in place to take you to their new location from those postings.

A vulnerability (CVE-2022-22819) has been identified on select NXP processors by which a malformed SB2 file header sent to the device as part of an update or recovery boot can be used to create a buffer overflow. The buffer overflow can then be used to launch various exploits. Refer to the attached bulletin for more information.   09/26/2022 - Bulletin updated to include fix datecode information. 11/01/2022 - Bulletin updated with clarification that mixed datecodes are RT600 only.    

The ADC converter for LPC55Sxx is a new IP, it has a lot of new features. The ADC converter clock frequency must be less than 24MHz, the ADC converter sampling rate can reach up to 1MSPS, the ADC converter supports to sample both the single-end analog signal and differential analog signal. It supports software triggering mode and hardware triggering mode, the triggering source can be from internal Timer, external pins, comparator output signal. The ADC converter supports synchronous sampling for only single-ended analog channel, but the analog channel pair are fixed for example CH0A/CH0B and CH1A/CH1B. The ADC of LPC55S6x consist of 16 Trigger Control (TCTRLa) registers, one trigger control register corresponds one hardware trigger source. For example, the TCTRL[0] corresponds trigger source0 GPIO irq_pint[0], the TCTRL[1] corresponds trigger source1 GPIO irq_pint[1]. When the GPIO IRQ_PIN[0] signal edge is detected, the ADC will be trigger to convert the analog channel. Hardware trigger Mapped to 0 GPIO irq_pint[0] 1 GPIO irq_pint[1] 2 State Configurable Timer (SCT) sct0_outputs[4] 3 State Configurable Timer (SCT) sct0_outputs[5] 4 State Configurable Timer (SCT) sct0_outputs[9] 5 State Counter Timer (CTIMER) ct0_mat3_out 6 State Counter Timer (CTIMER) ct1_mat3_out 7 State Counter Timer (CTIMER) ct2_mat3_out 8 State Counter Timer (CTIMER) ct3_mat3_out 9 State Counter Timer (CTIMER) ct4_mat3_out 10 Comparator 11 ARM tx event 12 GPIO BMATCH   The trigger attributes is defined in the corresponding TCTRLaXX register, when the TCTRLaXX[HTEN]=0, software trigger is enabled, hardware trigger is disabled. Setting the SWTRIG[xx] bit will trigger ADC to start conversion. The TCTRLaXX[TCMD] specifies which command buffer is executed.   There are 15 command buffers (CMDa), each consists of  two 32-bit registers (CMDLa:CMDHa), which specifies the ADC channels, resolution, sampling time.. For all the examples, a hardware triggering mode example is developed, the hardware triggering source 7 “State Counter Timer (CTIMER) ct2_mat3_out” is used to trigger ADC, so TCTRL[7] register is initialized, the TCMD bits in TCTRL[7] register is set up as 1, so the CMDH[1]:CMDL[1] are initialized to configure the analog channel, ADC sample resolution… .  

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 To 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

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.

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

1 Abstract       In the previous time, I have shared one post about the kinetis L series LIN slave basic usage. Now, because the LPC54608 still don’t have any sample code about the LIN, so this post, I will share a simple code about the LPC54608 LIN master usage, and use the LPCXpresso 54608 board associated with the LIN analyzer to test the result.       This document will realize the LIN master and LIN slave communication, LIN master will send the specific publisher frame and the subscriber frame, the LIN slave will detect the master data’s correction, and feedback the according data. 2 LPC54608 LIN master example      Now use the LPCXpresso54608 board as the LIN master, the LIN analyzer tool as the LIN slave, test the LIN send and receive function between the LIN master and LIN slave. 2.1 Hardware requirement      Hardware：LPCXpresso54608，KIT33662LEFEVB，PCAN-USB Pro FD       LIN bus voltage is 12V, but the LPCXpresso54608 board don’t have the on board LIN transceiver, so we need to find the external LIN transceiver, then connect the LPC54608 UART port to the LIN transceiver. About the external LIN transceiver, we use the NXP official LIN driver board KIT33662LEFEVB, this board schematic can be found from this link: https://www.nxp.com/docs/en/user-guide/KT33662UG.pdf          Fig 2-1. LIN transceiver schematic    If you don’t have the KIT33662LEFEVB board, don’t worry, you also can use the TRK-KEA8, just like the kinetis LIN post which I have shared. TRK-KEA8 have the on board transceiver chip. 2.1.1 LPCXpresso5460 and IT33662LEF EVB connections No. LPCXpresso54608 KIT33662LEFEVB note 1 P4_RX J4-2 UART0_RX 2 P4_TX J4-1 UART0_TX 3 P4_GND J5-1 GND 4 JP2_3 J5_2 3.3V power supply   2.1.2 KIT33662LEFEVB 12V power supply and LIN slave connection KIT33662LEFEVB board J2_1: 12V power supply, also connect to LIN analyzer VBAT pin J2_3: 12V ground, also connect to LIN analyzer GND pin J2_2: LIN bus, connect to the LIN analyzer LIN pin   2.1.3 Use TRK-KEA8 on board LIN transceiver       This chapter just for those don’t have KIT33662LEFEVB board, but have the TRK-KEA8 board. 1）LPCXpresso54608 and TRK-KEA8 connections      LPCXpresso54608 need to connect the UART pin to the LIN transceiver, the connections like this: No. LPCXpresso54608 TRK-KEA8 note 1 P4_RX J10-5 UART0_RX 2 P4_TX J10-6 UART0_TX 3 P4_GND J14-1 GND 2） TRK-KEA8  and LIN analyzer connections         LIN bus is the single wire, connect to LIN analyzer LIN pin, GND also need to connect together.        TRK-KEA8 need to use the P1 powered by 12V DC power supply, LIN analyzer also need to connect to the 12V DC.        Because the LPC54608 board is powered by the 3.3V, then also need to power the LPC54608 board with a 3.3V DC power supply. 2.1.4 Physical connections                Fig 2-2. Physcial connections 2.2 Software code       Now, talk about the LIN master send the LIN publisher data and the subscriber ID data, the software code is modified from the SDK_2.3.0_LPCXpresso54608 usart interrupt project, the detail code just as follows: void DEMO_USART_IRQHandler(void) {   if(DEMO_USART->STAT & USART_INTENSET_DELTARXBRKEN_MASK) // detect LIN break      {        DEMO_USART->STAT |= USART_INTENSET_DELTARXBRKEN_MASK;// clear the bit        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 = 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 } /********************************************************************************************/ /*Publisher LIN frame /*13bit break+0x55 sync+0xad(0x2D's protected ID)+0x01+0x02+0x03+0x4C(check sum) //All the above byte is sent by the LIN master /********************************************************************************************/ void Lin_Master_Publisher(void) {     unsigned int i=0; //===============================LIN master send=====================        DEMO_USART->CTL |= USART_CTL_TXBRKEN_MASK;//enable TX break;        while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART))         {             USART_WriteByte(DEMO_USART, 0Xff);//dummy byte, no means             break;  //just send one byte, otherwise, will send 16 bytes         }         for(i=0;i<10000;i++); // delay for the break generation.        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, 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;        DEMO_USART->CTL |= USART_CTL_TXBRKEN_MASK;//enable TX break;        while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART))         {             USART_WriteByte(DEMO_USART, 0Xff);//dummy byte, no means             break;  //just send one byte, otherwise, will send 16 bytes         }         for(i=0;i<10000;i++); // delay for the break generation.       // for(i=0;i<5000;i++);        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, 0XEC);//0XEC             break;  //just send one byte, otherwise, will send 16 bytes         } } /*! * @brief Main function */ int main(void) {     unsigned int i=0;     usart_config_t config;     /* attach 12 MHz clock to FLEXCOMM0 (debug console) */     CLOCK_AttachClk(BOARD_DEBUG_UART_CLK_ATTACH);     BOARD_InitPins();     BOARD_BootClockFROHF48M();     BOARD_InitDebugConsole();     /*      * config.baudRate_Bps = 19200U;      * config.parityMode = kUSART_ParityDisabled;      * config.stopBitCount = kUSART_OneStopBit;      * config.loopback = false;      * config.enableTxFifo = false;      * config.enableRxFifo = false;      */     USART_GetDefaultConfig(&config);     config.baudRate_Bps = BOARD_DEBUG_UART_BAUDRATE;     config.enableTx = true;     config.enableRx = true;     USART_Init(DEMO_USART, &config, DEMO_USART_CLK_FREQ);     /* Enable RX interrupt. */     DEMO_USART->INTENSET |= USART_INTENSET_DELTARXBRKEN_MASK; //USART_INTENSET_STARTEN_MASK |        //enable USART interrupt     cnt=0;            USART_EnableInterrupts(DEMO_USART, kUSART_RxLevelInterruptEnable | kUSART_RxErrorInterruptEnable);     EnableIRQ(DEMO_USART_IRQn);//All ID datas will be received in the interrupt         Lin_Master_Publisher(); //LIN master send publisher ID 0x2D     for(i=0;i<65535;i++);//delay     Lin_Master_Subscribe();//LIN master send subscriber ID 0x2c     while (1)     {     } } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍     In USART_Init function，add the LIN function enable code：     /* setup configuration and enable USART */     base->CFG = USART_CFG_PARITYSEL(config->parityMode) | USART_CFG_STOPLEN(config->stopBitCount) |                 USART_CFG_DATALEN(config->bitCountPerChar) | USART_CFG_LOOP(config->loopback) | USART_CFG_ENABLE_MASK | USART_CFG_LINMODE_MASK;// 3 LPC54608 LIN master test result   Master side define two ID frame： Unconditional ID Protected ID Direction Data checksum 0X2C 0XEC subscriber 0x01,0x02 0x10 0X2D 0XAD Publisher 0x01,0x02,0x03 0x4c   Now, LIN master will send the above two ID frame to the slave, then give the test result about the feedback from the slave and the LIN bus wave. 3.1 LIN slave configuration The LIN baud rate is defined as 9600bps. The following picture is from the LIN analyzer (PEAK LIN tool) software: To get the data from the LIN slave, the master need to send the 0x2C frame at first, then the slave will send back the according data. The master subscriber frame is the slave’s publisher frame; the master publisher frame is the slave’s subscriber. Master send, slave receive. Master receive, then the slave is the send side.       In the slave software side, need to configure the 0X2C ID according data, then press the space key, the slave will wait for the master’s according frame. 3.2 Send 0X2C and 0X2D frame From the slave side, we can find 0X2D is received successfully from the master, 0X2C can send the correct data to the master. 3.2.1 0X2D frame data LIN bus wave and debug result Yellow wave is the LPC54608 UART TX pin wave. Blue wave is the LIN bus wave. From the LIN bus wave, we can find that the LIN master can send out the correct LIN data, and the checksum also correct from the slave received side. 3.2.2 0X2C data LIN bus wave and debug result Yellow wave is the LPC54608 UART TX pin wave. Blue wave is the LIN bus wave. From the wave, we can find that after the LIN master send the 0X2C data, the slave will send back the according data to the master, now check the LPC54608 debug data from IAR: From the received data and the checksum data,  we can find the slave feedback is correct. So, the above modified code can realize the LPC54608 LIN master frame basic send and receive function.  Next time, I will also share a post about the LPC54608 LIN slave code. Wish it helps you!  

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 result 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 + hotfix1 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.  

LPC4300 10-bit ADC module Introduction        LPC4300 Series microcontrollers combine the high performance and flexibility of an asymmetric dual-core architecture (ARM Cortex-M4F and Cortex-M0 coprocessor) with multiple high-speed connectivity options, advanced timers, analog, and optional security features to secure code and data communications. DSP capabilities enable all LPC43xx families to support complex algorithms in data-intensive application. Flash and Flashless options support large, flexible internal and external memory configurations.         LPC4370/LPC43S70 products provide 12-bit high-speed ADC module with up to 80MSamples/s. This document does not test 12-bit high-speed ADC performance. LPC43xx/LPC43Sxx series products provide two 10-bit SAR ADC module with below features: *   Measurement range 0 to 3.3 V *   10-bit conversion time = 2.45 us (up to 400K Samples/s) *   Burst conversion mode for single or multiple inputs *   Support hardware/software trigger *   Support Interrupt/DMA mode Test hardware platform introduction         This test hardware platform uses Keil MCB4357 evaluation board (OM13040), which enables customer to create and test working programs based on the LPC4300 family of Dual Core ARM Cortex™-M4/M0 devices. Keil MCB4357 with below features:  204 MHz LPC4357 device with ARM Cortex-M4 processor and Cortex-M0 coprocessor 136 KB On-Chip SRAM 1 MB dual bank On-Chip Flash On-Board Memory: 16 MB NOR Flash, 4 MB Quad-SPI Flash, 16 MB SDRAM & 16 KB EEPROM (I²C) Color QVGA TFT LCD with touchscreen High-speed USB 2.0 Host/Device/OTG interface (USB host + Micro USB Device/OTG connectors) Full-speed USB 2.0 Host/Device interface (USB host + micro USB Device connectors) MicroSD Card Interface Analog Voltage Control for ACD Input Audio CODEC with Line-In/Out and Microphone/headphone connector + Speaker Debug Interface Connectors 20-pin JTAG (0.1 inch) 10-pin Cortex debug (0.05 inch) 20-pin Cortex debug + ETM Trace (0.05 inch connector Test software introduction       This test software uses LPCOpen software ADC demo, the software version is V2.20.       ADC demo default path is:       ..\lpcopen_2_19_keil_iar_keil_mcb_4357\applications\lpc18xx_43xx\iar\keil_mcb_4357\periph_example.eww      LPCOpen software [periph_example.eww] project provides LPC4357 most modules driver application demos. The ADC demo need precompile MCB4357 board support package (lib_lpc_board_keil_mcb_4357) and LPC43xx chip driver (lib_lpc_chip_43xx). MCB4357 board support package provides MCB4357 board related pins configuration, clock configuration, on-board external memory configuration, Ethernet PHY driver configuration and board hardware resource configuration; LPC43xx chip driver provides LPC43xx modules driver API function.       ADC demo provides three modes to get ADC conversion value: polling mode, interrupt mode and DMA mode. The demo config 10-bit ADC module with 400K Samples/s and ARM Cortex-M4 core clock frequency with 204MHz. The test uses Timer0 module as time-base and counter reference clock is same with ARM Cortex-M4 core clock frequency (204MHz).       Timer0 initialization code comments: ADC module initialization code comments: ADC polling mode code comments: ADC interrupt mode code comments: ADC DMA mode code comments: Test result     The test will use TIMER0 counter to calculate each test item time interval.      The test includes below test items:      Single/no burst: ADC convert one time with burst mode disabled      100K/no burst: ADC convert 100K times with burst mode disabled      Single/burst: ADC convert one time with burst mode enabled      100K/burst: ADC convert 100K times with burst mode enabled

This 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!

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. 

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

        In recent years of MCU technology evolving, booting from the external flash seems to become more and more popular, actually, LPC already has employed this technology for many years.         NXP's recently released the LPC540xx family which continues the trend of high-performance flash-less MCU.         The developers may be a bit confused with the external FLASH which is used for storing the program, as they are used to directly using the internal FLASH for programming and debugging the chip. But, don't worry, let me introduce it in the following sections. LPC54018's three ways of loading program        In general, RAM stores data, however, RAM can also store programs. In previous projects, we occasionally move some key functions in RAM in order to improve the execution speed of these programs. The current implementation is to put all the programs in RAM more thoroughly. Based on this idea, you can directly use the debugger to load the executable image into the on-chip RAM and this method is called RAM TARGET.       After downloading the executable program image file to the external flash, when the bootloader loads the complete image to on-chip RAM to run, the method is called the Plain Load Image method.             Actually, both of these above ideas are routine, chip designers have also created a "super-capability" that allows the chip to directly execute external FLASH programs (Execute In Place, XIP). With this 'superpower', no matter whether the program boot from the external FLASH or the internal FLASH, there is no difference in operating performance.       The RAM TARGET method mentioned above is only suitable for debugging the application. Once the chip is powered off or reset, the downloaded program in the RAM will disappear. Meanwhile, the size of the RAM also give some restrictions for debugging.        In the Plain Load and XIP modes, the executable image file is stored in the external flash. After MCU is powered, the bootloader which is resided in ROM copies the first 512 bytes from the image (vector components and image header) into internal SRAMX at location 0x0000 0000 to validate the vector table and image header to confirm the booting mode. And the program will not be lost after power-off or reset. Fig1 illustrates the boot process of LPC54018. Fig1 LPC54018 boot process flow Experiment show         Board: LPCXpresso54018 board (OM40003) Fig1 LPCXpresso54018 board       Demo code: Hello world (From the SDK), modifying the hello world code in below way, which points out the load program way and date time. PRINTF("hello world. XXXXXXXX \r\n");    PRINTF("hello world, %s, %s.\r\n", __DATE__, __TIME__);‍‍‍‍‍‍‍‍‍‍‍‍ Experiment 1: RAM Target         Demo code: Hello world (From the SDK), modifying the hello world code in below way. PRINTF("hello world. RAM Target \r\n"); PRINTF("hello world, %s, %s.\r\n", __DATE__, __TIME__);‍‍‍‍‍‍‍‍‍‍      Note: Setting the Reset: Core when debugging the demo Fig2 Setting the Reset: Core Running testing: As the Fig3 illustrates, it would print the below message when debugging the demo, however, after reset, it would run the plain load image which is programmed before, as the RAM lost the hello world demo. Fig3 RAM Target runing testing Experiment 2: Plain Load Image        Demo code: Hello world (From the SDK), modifying the hello world code in below way. PRINTF("hello world. PLAIN LOAD IMAGE \r\n"); PRINTF("hello world, %s, %s.\r\n", __DATE__, __TIME__);‍‍‍‍‍‍‍‍‍‍‍‍‍      Download image to external flash:        1. Build the demo to generate a bin file.           This plainload example linked the vector table to 0x00000000, but program to external flash 0x10000000.        2. Program the bin file to external on board flash via SEGGER J-FLASH Lite(V6.22 or higher):             a. Open SEGGER J-FLASH Lite, select device LPC54018.             b. Click the 'Erase Chip' to erase the extrenal flash.(if can not success, press SW4 button and reset the board, and try to erase again)                 Note: if can not success( press SW4 and reset the board, and try to erase again) Fig4 Erase the external flash              c. Select the bin data file, set the '.bin/Erase Start' address to 0x10000000, then click 'Program Device' Fig5 Program the external flash Running testing: Fig6 illustrates the result of  running the plain load image. Fig6 Plain load image runing testing Experiment 3: XIP Image        Demo code: Hello world qspi_xip (From the SDK), modifying the code in below way. PRINTF("hello world. PLAIN LOAD IMAGE \r\n"); PRINTF("hello world, %s, %s.\r\n", __DATE__, __TIME__);‍‍‍‍‍‍‍‍‍‍‍‍‍‍      Download image to external flash:        1. Build the demo to generate a bin file.        2. Program the bin file to external on board flash via SEGGER J-FLASH Lite(V6.22 or higher):            a. Open SEGGER J-FLASH Lite, select device LPC54018.            b. Click the 'Erase Chip' to erase the extrenal flash.(if can not success, press SW4 button and reset the board, and try to erase again)            Note: if can not success( press SW4 and reset the board, and try to erase again) Fig7 Erase the external flash           c. Select the bin data file, set the '.bin/Erase Start' address to 0x10000000, then click 'Program Device' Fig8 Program the external flash      Running testing:      Fig9 illustrates the result of  running the plain load image. Fig9 XIP image runing testing  

This article is about how to use MCUXpresso Config Tool to create a USB project from start. The method is the same to all MCUXpresso Config Tool supported MCUs Demo: Creating USB composite HID mouse + keyboard project. Prequisities: LPCXpresso55S69-EVK MCUXPresso IDE 11.1.1 SDK package for LPCXpresso55S69 ,SDK_2.7.1_LPCXpresso55S69. The SDK has to be imported into MCUXPresso IDE (in Installed SDKs). Step by step guide is attached. Enjoy it :-).

Do you want to know more about one of our hottest products in the LPC800 series portfolio? Take a look at this technical presentation featuring the LPC84x MCU family. Based on the Arm Cortex-M0+ core, the LPC84x Family of MCUs is a low-cost, 32-bit MCU operating at frequencies of up to 30 MHz. The LPC84x MCU family supports of up to 64 KB of flash memory and 16 KB of SRAM. In addition, to make things easier, the LPC800 series McUs are supported by our free example code bundles and now, they're also supported by the MCUXpresso Software Develpment Kit (SDK).  Fig 1. LPC84x MCU Family Block Diagram

In some early LPC products, such as LPC11xx, LPC17xx, LPC18xx, LPC40xx, LPC43xx, LPC8xx, etc, CRP is used to utilize code protection. CRP has three different security levels: Figure 1 shows the security levels of CRP1, CRP2, and CRP3. Figure 1 The LPC55 series (LPC55(S)0x, 1x,2x, and 6x) uses Secure boot and Protected Flash Region (PFR) configuration instead of CRP for security protection. The part number with S (eg. LPC55S) supports Secure boot, for instance, LPC55S28 and LPC55S06. However, non-S series products, such as LPC5506, LPC5528,  can only utilize code protection by configuring FPR related fields. CRP2 is the most commonly used protection level. With CRP2, SWD access is blocked, so users can not read, write, or erase Flash via SWD or ISP. In addition, users cannot erase part of Flash to modify existing code. Once in CRP2 mode, Flash can only be recovered by Mass Erase Flash, which effectively prevents attacker from reading and modifying the Flash code. Unfortunately, the LPC5500 device such as LPC55(S)0x, 1x,2x,6x doesn't have exactly the same functional mechanism as the CRP2, which is questioned by many users. However, if we need to achieve the same functionality as CRP2, we can configure CMPA to disable ISP and SWD debugging port. 1.   Disable ISP Customer Manufacturing/Factory Configuration Area (CMPA) is part of the PFR, Configure BOOT_CFG to select whether the ISP mode is enabled. Table 1 shows the field table starting with 9E40 word address in CMPA. ISP control domains have been marked in red (as shown in Table 1). Table 2 shows the mode selection of ISP domains, 111 is ISP disabled. If the ISP mode is disabled, set BOOT_CFG to 0b1110000. Word Address（HEX） Byte Address Field Description 6 5 4 3 2 1 0 9E40 9E400 BOOT_CFG Default ISP mode 0 0 0 0 9E404 SPI_FLASH_CFG 0 0 0 0 0 0 0 9E408 USB_ID USB Vendor ID 9E40C SDIO_CFG 0 0 0 0 0 0 0 9E41 9E410 CC_SOCU_PIN ISP_CMD_EN MCM33_DBGEN 0 0 0 0 0 9E414 CC_SOCU_DFLT ISP_CMD_EN MCM33_DBGEN TAPEN SPIDEN SPNIDEN DBGEN NIDEN Table 1 Default ISP mode Bit 【6：4】 Auto ISP 000 USB_HID_MSC 001 UART ISP 010 SPI Slave ISP 011 I2C slave ISP 100 Disable ISP 111 Table 2 2.   Disable SWD The DCFG_CC_SOCU is a configuration that specifies debug access restrictions per debug domain. These access restrictions are also referred as constraint attributes in this section. The debug subsystem is sub-divided into multiple debug domains to allow finer access control. Figure 2 shows debug domains and their corresponding control bit position in DCFG_CC_SOCU. Logically, DCFG_CC_SOCU has two components: SOCU_PIN and SOCU_DFLT. The SOCU_PIN and SOCU_DFLT registers are used together to define SWD debug access for the module. Which is logically composed of two components: SOCU_PIN: A bitmask that specifies which debug domains are predetermined by device configuration. SOCU_DFLT: Provides the final access level for those bits that the SOCU_PIN field indicated are predetermined by device configuration. In another words, set the corresponding bit of SOCU_PIN and SOCU_DFLT register to 1 at the same time to enable the module. This module is disabled by setting the corresponding bits of the SOCU_PIN and SOCU_DFLT registers to 0 simultaneously. See Figure 2. Figure 2 Note that the default value of CC_SOCU_PIN and CC_SOCU_DFLT in LPC55 PFR are all zeros. Therefore, in this case, although SOCU_PIN and SOCU_DFLT are both 0, the bit reverse rule is not met (Figure 3 below). Therefore, all debugging permissions are enabled by default when CC_SOCU_PIN and CC_SOCU_DFLT are all 0. Figure 3 Note: the distinction between CC_SOCU_PIN(CC_SOCU_DFLT) and SOCU_PIN(SOCU_DFLT). The former with CC_ includes the reverse bit of the latter. For example, if SOCU_PIN and SOCU_DFLT are set to all zeros and the reverse bit is set to 1, all SWD modules are disabled. Figure 4 3. Implementation The following uses LPC5506 as an example to configure the CMPA field: 3.1  Disable ISP and SWD Figure 5 Keep the default CMPA values except for the two highlighted in red in Figure 5. 1) Set BOOT_CFG to 0x70 to disable ISP. 2) Set all SOCU_PIN and SOCU_DFLT to 0, and set all reverse bits to 1. That is, disable all debug accessing subdomains. 3.2 Enable ISP and SWD Figure 6 Keep the default CMPA values except for the two highlighted in red in Figure 6. 1) Set BOOT_CFG to 0x00 to enable Auto ISP. 2) Restore the default values of DCFG_CC_SOCU, that is, CC_SOCU_PIN and CC_SOCU_DFLT to all zeros. in this case, all debug permissions are restored (turned on) because the rule of bit reversal is not met (see Part 2 of this article). 3.3 Code Implementation Enable or disable the SWD and ISP functions by serial command (1 or 0). Figure 7 The demo code is attached. This routine has been tested on the LPCXpresso55S06 development board. NOTE：     As system security requirements and the attack surface evolves, it is important for customers to understand the types of attacks (especially advanced physical attacks) which NXP does not claim to protect against, or strongly mitigate, so that appropriate mitigation can be taken by the customer at the system level if necessary.  

Continuously reducing the power consumption of integrated circuits is a constant topic in the development of integrated circuits. Reduced power consumption helps save power, extend standby time and reduce product heat, etc. Needless to say, low power consumption has become one of the important factors to measure product performance.   We usually recommend customers to refer MCUXpresso SDK power_mode_switch_lpc demo as low power design reference code. With this demo, customers can use serial terminal to control MCU to enter four low power consumption modes：Sleep mode，Deep Sleep mode，Power Down mode and deep power down mode. Meanwhile, user can also choose a variety of wake-up methods to wake up MCU through UART command.   However, when customers take use of power_mode_switch_lpc demo to measure lower power static characteristics, they find discrepancies with data sheet. Take example with LPCXpresso845MAX board. In power down mode, the demo board current reaches to around 100uA in debug mode. But data sheet states the typical current value is 1.5uA, no more than 10uA (see the Table below). Where is the problem? The purpose of the power_mode_switch_lpc demo is to demonstrate several low power modes and multiple wake-up methods to customers. We can’t get similar low power current value with default demo board as spec shows, but let's walk through a step-by-step demonstration and modify the routine to get the data sheet values.   LAB ENVIRONMENT: Demo Board: LPCXpresso845MAX SDK: SDK_2.11.0_LPCXpresso845MAX Demo Code: power_mode_switch_lpc IDE：MCUXpresso IDE v11.5.0   STEP: 1. Download power_mode_switch_lpc to LPC845 development board and run it. The serial port selects low power mode, press (SW2 button) to wake up. The program runs into power down mode, with debugger connected, the measured Idd is 99.5uA To enter low power mode, the following code is used: POWER_EnterPowerDown(DEMO_ACTIVE_IN_DEEPSLEEP); In order to wake up, parameter DEMO_ACTIVE_IN_DEEPSLEEP is configured with PDSLEEPCFG. BOD and watchdog oscillator power domains are turned on. All these setting results in potential current loss, causing power supply current higher than expectation.   2. In this step, we will remove wakeup initialization code // DEMO_InitWkt(); Replace this line of code //POWER_EnterPowerDown(DEMO_ACTIVE_IN_DEEPSLEEP); //enter power down mode with BOD and watchdog osc with POWER_EnterPowerDown(0); //power down BOD and watchdog osc   The modification is to turn off BOD power domain and watchdog clock in power down mode, compile and download the code again and enter the power down mode. At this time, the measured Idd is 57.3uA   In this way, Idd is significantly reduced. However, 57.3uA is still far from the typical value of 1.5uA stated in the data sheet. This is due to MCU debug power domain is turned on by IDE debugger, which leads to extra current consumption.  3. Thus we disconnect debugger and let the development board work in stand-alone mode (power off and re-power on). After power on, LPC is in power down mode. At this time, the measured Idd is 1.4uA. This is quite similar as the current value in datasheet. Consider GPIO configuration: The spec data shown in datasheet are tested under a dedicated test board with almost no external peripheral devices, and unused pins are basically in a floating state. For custom board or  LPCXpresso804 EVK. Some of its IO pins have external pull-up resistors and LEDs. If the GPIO is configured to output low power, the small light will be lit, resulting in additional power consumption. So we configure all pins as pull-up inputs for low power measurement.   Consider package: The test is based on LPCXpresso845MAX equipped LPC845 64pin package. It also applies to LPC845 48pin package. 33 package doesn't have VDDA pin. Due to VDD and VDDA pin design are not exactly the same as other package, for instance, 33pin low power consumption in power down mode is slightly higher than 64/48pin, but no more than 10uA as our spec in DS. Summary: Low power current parameters of the data sheet are measured with all MCU oscillators and analog domains off. Besides, reasonable configuration of GPIO can further reduce MCU power consumption. Before entering the low power consumption mode, it is recommended to set the unused GPIO as a pull-up input according to the actual situation (It can also be set to output low when the pin is floating). In applications with high requirements for low power consumption, users need to carefully optimize the code design to obtain the best low power consumption design.

The article introduces the RSA theory, how to get the RSA parameter, how to encrypt/decrypt with the RSA algorithms. RSA is an asymmetric cryptographic algorithm and widely used in encryption/decryption application and signature application. It completes encryption and decryption operations by encrypting the message with the public key and decrypting with the private key. In order to support security requirements, it is also used in many places in the LPC55 series, such as: -  RSA digitally signs the application code with the private key, and verifies the authenticity of the code through RSA signature verification in secure boot. This is implemented in LPC55 secure boot. For the LPC family, the mbedtls library is used to implement the RSA algorithms with software.

经常有客户在使用LPC55S69的过程中遇到读 Flash进入异常HardFault中断的现象。如果在Flash Mass Erase之后从未对Flash扇区进行过写操作，直接用指针通过AHB读Flash地址会导致程序跳入HardFault 中断而无法继续正常运行。 原因    刚出厂的LPC55Sxx FLASH处于全零的全擦除状态，没有设置ECC。当芯片通过LinkServer 和MCUXpresso IDE建立连接时，先擦除要下载代码用到的扇区，再把代码下载到对应位置，并对相应存储区的ECC值同时进行更新。代码以外的区域仍然是无ECC设置的擦除状态。 当LPC55Sxx 通过AHB总线直接读取Flash内存区域时（例如，mytemp = *(uint32_t*)0x4000）要对Flash ECC进行校验。这一指令对于读有效代码区是没有问题的， 因为这一区域的ECC在下载代码时早已设置好。但是一旦读取没有代码的扇区，由于没有检测到正确的ECC，导致Flash读取失败，并跳转到下图中的HardFault_Handler()异常中断：   我们在Sector Erase后通过AHB读取Flash内存内容，也会遇到同样的HardFault异常跳转，出问题的原因都是一样的。 解决方法 针对这一问题我们有如下两种解决方法： 先执行Flash写操作，再读取Flash 与Flash 擦除操作不同，执行Flash写操作后对应的ECC值也同步更新。这样，ECC校验通过后，通过下面的代码就可以对Flash直接进行AHB读取。 volatile uint32_t mytemp; …… mytemp = *(uint32_t*)0x1000;//read memory content 0x1000 to mytemp 请注意：0x1000必须是一个已经写过的地址。 如果Flash的某个扇区处于被擦除的状态，我们只需要在通过AHB总线读取内存区域之前对该区域执行写操作，这样ECC校验位更新正确后，就可以正常读Flash。 Flash的写操作可以参考MCUXpresso SDK自带的flashiap例程，函数FLASH_Program。   使用Flash控制指令读取Flash区内容 使用Flash控制指令进行读操作不会导致硬件错误（请参阅UM11126 “Command listing (CMD)”章节）。这是用户手册中推荐的读Flash正确打开方式。 请注意：CPU只有在频率低于100MHz时，才能进行Flash操作（读，写，擦除，校验，等等），当CPU频率超过100MHz时是不能实现上述操作的。 目前，官方没有提供上用控制指令读取Flash内容的例程，因此需要您根据下面步骤创建自己的读Flash程序。 开发环境： IDE: MCUXpresso IDE v11.1.0 SDK MCUXpresso SDK v2.7.0 步骤： 在MCUXpresso IDE中导入一个基础例程，如led_blinky 在下图所述选项中添加iap组件   选择iap1,点击OK   点击完OK之后，fsl_iap_ffr.h, fsl_iap.c, fsl_iap.h文件将自动添加到工程中   在source文件夹中添加附件中的memory.h和memory.c文件   4) 使用Flash 控制指令时，需要在源文件中添加memory.h, fsl_iap.h   5) 调用memory初始化和memory读取函数   6）调试，单步执行（step over）到memory_read()，查看结果