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.

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

This documet is an introduction about TrustZone on the LPC55S6x devices. LPC55S6x MCU platform and general-purpose blocks The LPC55S69 has one 100-MHz Cortex-M33 core with TrustZone, MPU, FPU, and SIMD and another 100-MHz Cortex-M33 without security features enable. Lets remark that the LPC55Sxx family has another LPC55S66 that only implements a single 100-MHz core. There are two coprocessors on core 0, a DSP accelerator called PowerQuad, and a crypto engine called CASPER. The core platform has a multilayer bus matrix that allows simultaneous execution from both cores and parallel access of the other masters to peripherals and memories. The memory on chip includes up to 640 KB of Flash, up to 320 KB of RAM, and 128 KB of ROM. Timers include 5 - 32-bit timers, a SCTimer/PWM, a multi-rate timer, a windowed watchdog timer, Real Time Clock (RTC), and a micro timer. Each core has its own systick timer. Communication interfaces include a USB high-speed with on-chip HS PHY, a USB full-speed that can run crystal-less, two SDIO interfaces to support WIFI and SD cards at the same time, 1 high-speed SPI with up to 50-MHz clock rate, and 8 Flexcomms with support of up to 8 SPI, I2C, UART, or 4 I2S. The analog system includes a 16-channel 16-bit ADC that samples at 1 MSPS, an analog comparator, 16-channel capacitive touch controller, and a temperature sensor. Other modules include a programmable logic unit, a buck DC-DC converter, operating voltage from 1.71 to 3.6 V over a temperature range from -40 to 105 °C. What is TrustZone? In recent years, the Internet of Things (IoT) has become a hot topic for embedded system developers. IoT system products have become more complex, and better solutions are needed to ensure system security. ARM® TrustZone® technology is a System on Chip (SoC) and CPU system-wide approach to security. The TrustZone® for ARMv8-M security extension is optimized for ultra-low power embedded applications. It enables multiple software security domains that restrict access to secure memory and I/O to trusted software only. TrustZone® for ARMv8-M: Preserves low interrupt latencies for both secure and non-secure domains Does not impose code overhead, cycle overhead or the complexity of a virtualization based solution Introduces efficient instructions for calls to the secure domain with minimal overhead TrustZone® is a technology available in Cortex M23 and Cortex M33. TrustZone® provides the means to implement separation and access control to isolate trusted software and resources to reduce the attack surface of critical components. The created trusted firmware can protect trusted operations and is ideal to store and run the critical security services. The code should also protect trusted hardware to augment and fortify the trusted software. This includes the modules for hardware assists for cryptographic accelerators, random number generators, and secure storage. Best practices demand that that this code be small, well-reviewed code with provisions of security services. The LPC55S66 and LPC55S69 have implemented core 0 as a Cortex-M33 with full TEE and TrustZone® support enabled. The LPC55S69 has a second Cortex-M33 (core 1) that does not implement the secure environment with TZ. Isolation is just the foundation. Security is about layers of protection, adding in further hardware and software to create more layers. Features of TrustZone® technology: Allows user to divide memory map into Secure and Non-Secure regions Allows debug to be blocked for Secure code/data when not authenticated CPU includes Security Attribution Unit (SAU) as well as a duplication of NVIC, MPU, SYSTICK, core control registers etc. such that Secure/Non-Secure codes can have access to their own allocated resources Stack management expands from two stack pointers in original Cortex-M (Main Stack Pointer (MSP) and Process Stack Pointer (PSP)) to four, providing the above pair individually to both Secure and Non-Secure Introduces the concept of Secure Gateway opcode to allow secure code to define a strict set of entry points into it from Non-secure code Secure and non-secure memory TrustZone® technology divides the system into two states, safe (S) and non-secure (NS), and can switch between the two states through corresponding commands. The CPU states can be secure privilege, secure non-privilege, privilege (Handler), or non-privilege (Thread). The Secure memory space is further divided into two types: Secure and Non-secure Callable(NSC). Below are the feature/properties of Trustzone memory regions ( S, NS, NSC 😞 Secure (S) - For Secure code/data − Secure data can only be read by secure code − Secure code can only be executed by CPU in secure mode Non-Secure (NS) – For non-Secure code/data − NS Data can be accessed by both secure state and non-secure state CPU − Cannot be executed by Secure code Non-Secure Callable (NSC) − This is a special region for NS code to branch into and execute a Secure Gateway (SG) opcode. Attribution Units Combination of Security SAU and IDAU assign a specific security attribute  (S, NS, or NSC) to a specific address from the CPU0. Device Attribution Unit (DAU) connects to CPU0 via IDAU interface as show the following Figure. Access from CPU0, dependent on its security status and the resultant security attribute set by the IDAU and SAU, is then compared by the secure AHB Controller to a specific checker which marks various access policies for memory and peripherals. All addresses are either secure or non-secure. The SAU inside of the ARMv8-M works in conjunction with the MPUs. There are 8 SAU regions supported by LPC55S69. Secure and non-secure code runs on a single CPU for efficient embedded implementation. A CPU in a non-secure state can only execute from non-secure program memory. A CPU in a non-secure state can access data from both NS memory only. For the secure, trusted code, there is a new secure stack pointer and stack-limit checking. There are separate Memory Protection Units (MPUs) for S and NS regions and private SysTick timers for each state. The secure side can configure the target domain of interrupts. The NXP IDAU (Implementation specific Device Attribution Unit) implementation of ARM TrustZone for core0 involves using address bit 28 to divide the address space into potential secure and non-secure regions. Address bit 28 is not decoded in memory access hardware, so each physical location appears in two places on whatever bus they are located on. Other hardware determines which kinds of accesses (including non-secure callable) are allowed for any address.  The IDAU is a simple design using address bit 28 to allow aliasing of the memories in two locations. If address bit 28 is = 0 the memory is Non-Secure. If address bit 28 = 1 the memory is Secure. The SAU allows 8 memory regions and allow the user to override the IDAU’s fixed Map, to define the non-secure regions. By default, all memory is set to secure. At least one ASU descriptor should be used to make IDAU effective. If either IDAU or SAU marks a region, then that region is secure. NSC area can be defined in NS region of the IDAU. For example a designer could use bit [28] of the address to define if a memory is Secure or Non-secure, resulting in the following example memory map. Simple IDAU, without creating a critical timing path. (CM33 does allows little for IDAU function) Addresses 0x0000_0000 to 0x1FFF_FFFF are NS, Addresses 0x2000_0000 to 0xFFFF_FFFF If Address Bit_28 = 0  Non-Secure If Address Bit_28 = 1  Secure All peripherals and memories are aliased at two locations. The SAU define region numbers for each of the memory regions. The region numbers are 8-bit, and are used by the Test Target(TT) instruction to allow software to determine access permissions and security attribute of objects in memory. The number of regions that are included in the SAU can be configured to be either 0, 4 or 8. Note: When programming the SAU Non-secure regions, you must ensure that Secure data and code is not exposed to Non-secure applications. Security state changes The system boots in secure state and can change security states using branches as summarized in the following Figure. Transitions from secure to non-secure state can be initiated by software through the use of the BXNS and BLXNS instructions that have the Least Significant Bit (LSB) of the target address unset. Note: The M profile architecture does not support the A32 instruction set. This allows the LSB of an address to denote the security state. Transitions from non-secure to secure state can be initiated by software in two ways: A branch to a secure gateway. A branch to the reserved value FNC_RETURN. A secure gateway is an occurrence of the Secure Gateway instruction (SG) in  the Non-Secure Callable (NSC) region. When branching to a secure gateway from non-secure state, the SG instruction switches to the secure state and clears the LSB of the return address in lr. In any other situation the SG instruction does not change the security state or modify the return address. A branch to the reserved value FNC_RETURN causes the hardware to switch to secure state, read an address from the top of the secure stack, and branch to that address. The reserved value FNC_RETURN is written to lr when executing the BLXNS instruction. Security state transitions can be caused by hardware through the handling of interrupts. Those transitions are transparent to software and are ignored in the remainder of this document. The TT instruction The ARMv8-M architecture introduces the Test Target instruction (TT). The TT instruction takes a memory address and returns the configuration of the Memory Protection Unit (MPU) at that address. An optional T flag controls whether the permissions for the privileged or the unprivileged execution mode are returned. When executed in the secure state the result of this instruction is extended to return the Security Attribution Unit (SAU) and Implementation Defined Attribution Unit (IDAU) configurations at the specific address. The MPU is banked between the two security states. The optional A flag makes the TT instruction read the MPU of the non-secure state when the TT instruction is executed from the secure state. The TT instruction is used to check the access permissions that different security states and privilege levels have on memory at a specified address. You can find more useful information about ARM® TrustZone®, in the following links: https://developer.arm.com/ip-products/security-ip/trustzone https://www.nxp.com/docs/en/application-note/AN12278.pdf http://www.keil.com/appnotes/files/apnt_291.pdf  http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf

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‌

  Background LPC55(S)XX and MCX series products support updating firmware (ELF, HEX, BIN or SREC/S19) in ISP mode, including USB, UART, SPI, and I2C  connection interfaces.  There was no official host software tool supporting SPI-ISP and I2C-ISP before, so it was difficult for customers to update firmware files through I2C and SPI in ISP mode. Now NXP has launched MCUXpresso Secure Provisioning Tool(SEC or SPT), a graphical interface tool that makes it easy to connect through the four ISP interfaces. Based on the SEC, this article takes LPCXpresso55S69 as an example to introduce the methods of updating firmware in four modes: USB-ISP, UART-ISP, SPI-ISP and I2C-ISP.   Preparation （1）Software MCUXpresso Secure Provisioning Tool is a graphical user interface tool, which is mainly used for security configuration. When  MCU is in the ISP mode, you can use this tool to connect and communicate, it support all interfaces of  ISP. LPC55(s)xx series include four ISP download interfaces: USB, UART, SPI, and I2C. This article is based on this to introduce. （2）Hardware LPCXpresso55S69-evk development board (chip version is 1B)   Steps Make chip into ISP mode before  using SEC tool connect. When power-on, BOOT ROM determines whether enter the ISP mode, based on the CMPA configuration in bit DEFAULT_ISP_MODE and ISP pin status. As shown in  following tables：     Keep the default value of EFAULT_ISP_MODE to “000”, and enter the ISP mode by pulling down the ISP pin PIO0_5. The first valid probe message on USART, I2C, SPI or USB locks in that interface. On LPCXpresso55S69 development board, connect the ISP interface cable (USB\UART\SPI\I2C), press and hold the ISP button, power on,  it will  enter ISP mode.   3.1 USB HID ISP mode （1）In LPC55(s)xx, HS-USB is default USB-ISP port, LPCxpresso55s69-evk uses P9 port, use USB cable to connect P9 and PC. （2）Press and hold  ISP button, reset board, entered ISP-USB mode. （3）Configure MCUXpresso Secure Provisioning Tool: select USB connection mode, test connection. First, click "File->New Workspace", open the option to create a new workspace, and select the processor model you are using.     Then, click "Target->Connection" to open the connection configuration.   In configuration, select USB interface, click “Test Connection” button, if the result shows " ok", connected successfully.   （4）Select the source file in "Source executable image". This tool can build plaint image, signed image, and encrypted image. You can configure it according to your own requirements. For example, use a plain image file "lpcxpresso55s69_gpio_led_output.hex", this file is a binary file generated from MCUXpresso IDE under the SDK example. Click the "Build image" button, ensure that the compilation was successful.     （5）Download the image file Choose “Write Image” view, in “Image path” select the image generated by the previous step, then click  “Write Image” button.   If download  successfully, the following picture will be displayed:     3.2 UART ISP mode （1）LPC55(s)xx  use UART0 as UART-ISP interface, you can use USB cable to connect P6 of LPCxpresso55s69-evk and PC, or use USB-UART convertor to connect UART0 TX/RX and PC. （2）Enter ISP mode, refer to 3.1. （3）Configure MCUXpresso Secure Provisioning Tool, refer to 3.1, select UART connection mode, and perform connection test.   Step 4 and step 5 are the same as 3.1.   3.3 SPI ISP mode (1) LPC55(s) 2x/6x currently includes two versions, 0A and 1B, which can be checked from the chip mask. The 0A version supports SPI3 and HS_SPI ISP interface, and the 1B version only supports HS_SPI ISP interface. This article uses version 1B for the experiment. Both SPI and I2C use LIBUSB interface, LPC-LINK2 and MCU-LINK pro support this function interface, so as long as there is LPC-LINK2 or MCU-LINK pro, SPI-ISP and SEC tool connection can be realized. Special reminder: LPC-link2 and MCU-LINK pro must be updated to CMSIS-DAP debugging interface, J-link does not support this function. In the LPCxpresso55s69-evk development board, SPI3 is connected to LPC-LINK2 by default, and HS_SPI is not connected, so  an external connection is required, connect SCK, MOSI, MISO, and SSEL1 of HS_SPI to the corresponding positions of LPC-link2. For details, please refer to the lpc55xx manual and the development board schematic. It can also be connected according to the figure below. The connection of the development board is shown in the below picture   (2) Connect the USB cable to the P6 port. (3) Enter ISP mode, refer to 3.1. (4) Configure MCUXpresso Secure Provisioning Tool, refer to 3.1, select the SPI connection mode, and perform a connection test.   Step 5 and step 6 are the same as 3.1.   3.4 I2C ISP mode The I2C-ISP mode is the same as SPI, with the help of the LIBUSB interface, that is, the LPC-link2 on the development board. Special reminder: LPC-link2 and MCU-LINK pro must be updated to CMSIS-DAP debugging interface, J-link does not support this function. (1)  Connect the USB cable to the P6 port. (2)  LPC55(s)6x/2x uses I2C1, and LPCxpresso55s69-evk development board has already connected I2C1 and LPC-LINK2, no need additional connection. (3)  Enter ISP mode, refer to 3.1. (4) Configure the MCUXpresso Secure Provisioning Tool, refer to 3.1, select the I2C connection mode, and perform a connection test.   Step 5 and step 6 are the same as 3.1.   Summary (1) All ISP interfaces (USB/UART/SPI/I2C) are supported by MCUXpresso Secure Provisioning Tool. (2) LPC-link2/MCU-LINK pro must be configured as CMSIS-DAP debug probe. (3) Check the chip version and make sure use the correct SPI port. (4) Make sure that the usb  cable interface is connected correctly and must enter the ISP mode before testing the connection.      

1. Background When an embedded device is being upgraded, due to external factors such as power outage and forced interruption, the new firmware can‘t be written completely into flash, which causes problems when the system is started. Or if the image file is damaged during device is currently running, the system will break down and the device cannot run. To solve these problems, you can use the dual image, which ensures that at least one image file can be started and works properly at any time. If anything goes wrong, the bootloader detects and uses the alternate image file. 2. Principle LPC5536 ROM supports the dual image boot for internal flash, that means, in the flash region, two boot images can be placed there; ROM decides to boot which image based on the image version, boot the one with the newer image version first, if fail, boot the older one. During power-on and startup, the ROM first detects the location and size of the relocated image file in the CMPA, and then detects the version number of the two images. Therefore, when the dual image is used,  mainly need configure the relocation address and version number of the image files. The internal flash boot flow for dual image is as follows:   2.1 Relocating Image File The LPC5536 internal flash supports remapping. When set the remap offset, Internal FLASH memory AHB access will change the access address adding the offset as the below figure shows. For example, when the offset is set to 128K(0x20000), the access to 0x0 will be remapped to 0x20000. Via this IP feature, ROM can implement a dual image boot with two images. The offset and the remap size of the image is set in CMPA region by the user. This is an illustration of two image files stored in internal FLASH. The offset and remap size of the second image is set by the user in the CMPA area to let ROM know the location of the second image.   2.2 Configuring Image Version The image version is the image header offset 0x24; bit 10 shows whether the image contains the image version for not; if bit10 is 0, that means the image has no image version; ROM will take the image version as 0.   3、Implementation 3.1 Configuring CMPA 1) Configure Data Values in the CMPA Use blhost to write the modified bin file to CMPA to configure the image1 offset and remap size. The procedure is as follows: First, open an all “0” cmpa.bin and change the data at 0x3E23C to 0x20000, as shown in the figure below:   Then, modify the remap size. The data at address 0x3E238 is changed to 0x1d800, as shown in the following figure:   Modify and save, rename as cmpa_new.bin, save as \blhost_2.6.7\blhost_2.6.7\bin\win. 2) Download cmpa_new.bin Blhost 2.6.7 is a command-line tool, that use it to program cmpa_new.bin. Check whether the communication between blhost and development board is successfully. Firstly, check the port number for connecting between development board and computer from  device manager.   Secondly, short 3 and 4 of jumper J43 on lpc55s36-evk to enable ISP boot. Thirdly, press the reset key to reset board, input connection test command “blhost-p com12 -- get-property 1” Check whether communication is normal. If connection is successful, the message will be displayed as below:   Program modified bin file into CMPA. Write CMPA by using command “blhost-pcom12 -- write-memory 0x3e200 cmpa_new.bin”as shown below:   Read back CMPA data after writing. To confirm the accuracy of the data, run command “blhost-pcom12 -- read-memory 0x3e200 512” to view the configured CMPA data, as shown in the following figure:   3.2 Setting Dual Image Version To observe experimental effect, Image0 function is the RED light on LPC5536-evk development blinking, Image1 function is BLUDE light blinking. In Image0 project, set version number to 1, in Image1 set version number to 2: Open the project of red light blinking and change the header file to 0x10400 at offset 0x24.   Open the project of blue light blinking and change the header file to 0x20400 at offset 0x24.   3.3 Remap Flash For users, LPC5536JBD100 has a total of 246K internal flash available, so Image0 is assigned to the address range 0x00000-0x1FFFF and Image1 is assigned to the address range 0x20000-0x3D7ff. If using MCUXpresso ID, the Settings are as follows: Right-click Selected Project -> choose Properties ->MCU settings, set the Location (start address) and Size, click  Apply button when finished. The red light blinking project are modified as follows:    The blue light blinking project modified as follows:   Re-compile the project.  3.4 Functional Testing Test application is two lighting projects, namely red light blinking and blue light blinking. The red light blinking is image0, version 1, and the blue light blinking is image1, version 2. Therefore, if test result is blue light blinking, dual image function works successfully.. Download Images: Using GUI Flash Tool in MCUXpresso IDE, download two image files to the development board:   Open, and the following view pops up. Select download File in "File to program", then click run button, image will be downloaded to flash.   When the download is complete, click OK.   Download another image in the same way. Note that "mass erase" cannot be checked when programing the second image. If you use other tools to program, also should disable the same function as "mass erase", avoid erasing the first image file. Test result： After downloading the program and reset, the blue light blinking. Further test: Change the version number of red light blinking project to 3, that is, modify 0x10400 to 0x30400. Then downloading the image file again. The red light blinking. 4、Summary Dual image function increases the security for boot and firmware update of embedded devices. It is necessary to pay attention to the way of setting image offset, remapping size and configuring image version in the CMPA area when using it, and also pay attention to the flash configuration in the two projects.   Attachment is test application project.

The ADC of LPC55xx supports scan mode, in scan mode, once ADC triggering (either hardware or software) can convert multiple analog channels. The document gives an example that the CTImer2 module triggers ADC and ADC converts two analog channels for each triggering. The doc introduces the CTimer configuration, ADC triggering control register configuration, and ADC Command buffer chain and ADC result reading , in this way, the CTimer can trigger ADC, the ADC can convert multiple channels. The example and the doc are attached. The Example is developed based on SDK example lpcxpresso55s69_lpcadc_interrupt example, the tools is MCUXprsso IDE ver11.7, the SDK package is SDK_2.x_LPCXpresso55S69 ver2.11.1  

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.  

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

This document was made to explain how to regain control of any LPC EVK on brick mode without using an external debugger. Explore the simple way. In some cases, this method forms well and is the easy way, open your IDE and select your project.   At this point you may have a debugger configuration of your last debug session, so, you have similar icons to the image. Open the tab below and select erase. Depending on your debugger configuration you need to select the same icons below. Note: In some cases will be necessary to put your MCU in ISP. And that’s all, could try if the MCU is out the brick mode.   Introduction First, you need to install these tools on your PC. LPCScrypt [LPCScrypt v2.1.2 | NXP Semiconductors]. J-Link Commander. [J-Link Commander (segger.com)]. To understand this document, we need to know that every EVK [Evaluation Kit] can be divided into 2 parts. The debugger on the board Link2 and the target LPC55sXX. Figure 1. Link2 Green square, LPC55sXX Red square This document will describe two methods that must be done in the order mentioned because we will see how to update the firmware of the debugger to use the same board for a self-recovery, this step is necessary for the tool J-Link Commander to recognize the debugger as a Segger probe, then when the update is done the second step should be to enter ISP mode to do a mass erase of the target to get out of the brick mode. Link2 The Link 2 (LPC4370) debugger on the board probe can be configured to support various development tools and IDEs using a variety of different downloadable firmware images. Available firmware images include: J-Link by Segger. LinkServer. By default, the EVK board has the firmware LinkServer on the LPC4322 (dependent on your board), for this proposal we will see how to change to J-Link On-Board. DFU The EVK needs to be prepared to receive this firmware on the debugger, to do that we need to put the board on DFU [Device Firmware Update]. On the schematic need to find the DFU jumper to put on the board, the image below is an example of different EVKs check Figure 2.   Figure 2. DFU from different boards. Then connect it to the PC. Note: The firmware update is completely reversible. LPCScrypt Once installed on the PC we need to locate these files of the installation. Root example: C:\nxp\LPCScrypt\scripts When you have the board on DFU, connecting the USB Llink2 to the PC and then RUN the Scrypt (program_JLINK) in CMD check Figure 3. Press any key to continue… Figure 3. Flash firmware of J-Link in DFU mode. Successfully done, at this moment the EVK has the firmware of J-Link Segger. Review the Figure 4. Figure 4. The firmware was flashed successfully. Remove the USB cable to remove the DFU jumper with the board unpowered. ISP Brief of ISP (In System Programming) this method is used to recover a part programmed with a corrupted image which is not detectable by ROM. So, to enter this mode the user needs to put a jumper in the ISP header pins, search for this in the schematic, then connect to the PC and check Figure 5.     Figure 5. ISP image examples from different boards. J-LINK Commander Open the software and if the communication is right the message will appear J-Link via USB… OK check Figure 6. Figure 6. The EVK is now communicating to the tool J-Link Commander. Commands To start the communication needs to send the command “connect”. Then the tool shows your last target (if you use it) and use the next command “?” to change the target review Figure 7. Figure 7. Review the target. In the new popup window in the green area, you need to put the name of the target, take care you do not put the debugger check Figure 8. Figure 8. In the green area, you need to put the matricula of the MCU target. Example [LPC55s16 or LPC55s69] depending of your target check Figure 9. Figure 9. If the tool supports the MCU will show below the red square. In the next selections the tool is asking for the interface of communication, the communication of the EVK is SWD, and for that write “S” as SWD. On speed, only click enter without entry. Then this will appear before the connection check Figure 10. Figure 10. The communication is Done. Then use the command “erase” like the Figure 11. Figure 11. The tool indicate the erase is done. Finally disconnect the USB and remove the ISP jumper, then open the IDE and test the blinky led example, or if you wanted you could use the BLHOST. Flashing the MCU using  BLHOST. At this step you could able to use the IDE or use BLHOST. You could install SPSDK if you wanted [Installation Guide — SPSDK documentation]. In ISP mode… blhost -p COMxx  get-property 1 Figure 12. The first command is to check the communication. blhost -p COMxx flash-erase-all Figure 13. Do a mass erase. blhost -p COMxx write-memory 0 C:\root_example\Debug\led_blinky.bin Figure 14. The flashing was done. Remove the ISP jumper and reset your device. Common error LPCScrypt If the message appears “Nothing to boot”, need to be sure the board is connected to the PC with the DFU mode in LINK 2 check Figure 16. Figure 16. The red square is an example of an error communication. J-Link Commander If a similar message appears, “Cannot connect to target”, need to put the target in ISP mode, and return to the first steps with J-Link commander check Figure 18. Figure 18. Show how the communication is not done.

The documentation discusses how to generate phase-shift PWM signals based on SCTimer/PWM module, the code is developed based on MCUXpresso IDE version 10.3 and LPCXpresso5411x board. The LPC family has SCTimer/PWM module and CTimer modules, both of them can generate PWM signals, but only the SCTimer/PWM module  can generate phase-shift PWM signals. In the code, only the match registers are used to generate events, I/O signals are not used.  The match0 register is set up as (SystemCoreClock/100), which determines the PWM signal frequency. The the match1 register is set up as 0x00, which generate event1. The the match2 register is set up as (SystemCoreClock/100)/2;, which generate event2. The duty cycle is (SystemCoreClock/100)/2-0x00= (SystemCoreClock/100)/2, which is 50% duty cycle, the cycle time is (SystemCoreClock/100). The event1 sets the SCT0_OUT1, event2 clears the SCT0_OUT1, so SCT0_OUT1 has 50% duty cycle. The the match3 register is set up as (SystemCoreClock/100)/4;, which generate even3. The the match4 register is set up as 3*(SystemCoreClock/100)/4, which generate event4. The duty cycle is 3*(SystemCoreClock/100)/4  -  (SystemCoreClock/100)/4= (SystemCoreClock/100)/2, which is 50% duty cycle. The event3 sets the SCT0_OUT2, event4 clears the SCT0_OUT2, so SCT0_OUT2 has 50% duty cycle. The phase shift is (SystemCoreClock/100)/4 - 0x00= (SystemCoreClock/100)/4, which corresponds 90 degree phase shift. PWM initilization code: //The SCT0_OUT1 can output PWM signal with 50 duty cycle from PIO0_8 pin //The SCT_OUT2 can output PWM signal with 50 duty cycle fron PIO0_9 pin //The SCT0_OUT1 and SCT0_OUT2 PWM signal has 90 degree phase shift. void SCT0_PWM(void) {     SYSCON->AHBCLKCTRL[1]|=(1<<2); //SET SCT0 bit     SCT0->CONFIG = (1 << 0) | (1 << 17); // unified 32-bit timer, auto limit     SCT0->SCTMATCHREL[0] = SystemCoreClock/100; // match 0 @ 100 Hz = 10 msec     SCT0->EVENT[0].STATE = 0xFFFFFFFF; // event 0 happens in all states     //set event1     SCT0->SCTMATCHREL[1]=0x00;     SCT0->EVENT[1].STATE = 0xFFFFFFFF; // event 1 happens in all states     SCT0->EVENT[1].CTRL = (1 << 12)|(1<<0); // match 1 condition only     //set event2     SCT0->SCTMATCHREL[2]=(SystemCoreClock/100)/2;     SCT0->EVENT[2].STATE = 0xFFFFFFFF; // event 2 happens in all states     SCT0->EVENT[2].CTRL = (1 << 12)|(2<<0); // match 2 condition only     //set event3     SCT0->SCTMATCHREL[3]=(SystemCoreClock/100)/4;     SCT0->EVENT[3].STATE = 0xFFFFFFFF; // event 3 happens in all states     SCT0->EVENT[3].CTRL = (1 << 12)|(3<<0); // match 3 condition only     //set event4     SCT0->SCTMATCHREL[4]=3*(SystemCoreClock/100)/4;     SCT0->EVENT[4].STATE = 0xFFFFFFFF; // event 4 happens in all states     SCT0->EVENT[4].CTRL = (1 << 12)|(4<<0); // match 4 condition only     //PWM output1 signal     SCT0->OUT[1].SET = (1 << 1); // event 1 will set SCT1_OUT0     SCT0->OUT[1].CLR = (1 << 2); // event 2 will clear SCT1_OUT0     SCT0->RES |= (3 << 2); // output 0 toggles on conflict     //PWM output2 signal     SCT0->OUT[2].SET = (1 << 3); // event 3 will set SCT1_OUT0     SCT0->OUT[2].CLR = (1 << 4); // event 4 will clear SCT1_OUT0     SCT0->RES = (3 << 4); // output 0 toggles on conflict     //PWM start     SCT0->CTRL &= ~(1 << 2); // unhalt by clearing bit 2 of the CTRL } Pin initialization code: //PIO0_8 PIO0_8 FC2_RXD_SDA_MOSI SCT0_OUT1 CTIMER0_MAT3 //PIO0_9 PIO0_9 FC2_TXD_SCL_MISO SCT0_OUT2 CTIMER3_CAP0 - FC3_CTS_SDA_SSEL0 void SCTimerPinInit(void) {     //Enable the     SCTimer clock     SYSCON->AHBCLKCTRL[0]|=(1<<13); //set IOCON bit     //SCTimer pin assignment     IOCON->PIO[0][8]=0x182;     IOCON->PIO[0][9]=0x182;     IOCON->PIO[0][10]=0x182; } Main Code: #include <stdio.h> #include "board.h" #include "peripherals.h" #include "pin_mux.h" #include "clock_config.h" #include "LPC54114_cm4.h" void SCT0_Init(void); void SCTimerPinInit(void); void P1_9_GPIO(void); void SCT0_PWM(void); int main(void) {       /* Init board hardware. */     BOARD_InitBootPins();     BOARD_InitBootClocks();     BOARD_InitBootPeripherals();     printf("Hello World\n");    // SCT0_Init();    // P1_9_GPIO();     SCTimerPinInit();     SCT0_PWM();     /* Force the counter to be placed into memory. */     volatile static int i = 0 ;     /* Enter an infinite loop, just incrementing a counter. */     while(1) {         i++ ;     }     return 0 ; } The Yellow channel is PIO0_8 pin output signal, which is SCT0_OUT1 PWM output signal. The Bule channel is PIO0_9 pin output signal, which is SCT0_OUT2 PWM output signal.

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. 

Recently I found some customers have a bit of problem when porting project from one MCU to another, so this article using simple steps demonstrates how to change MCU with MCUXpresso. There is also a video demonstrated the detail steps in attachment. Pay attention, as MCUXpresso User Guide says: All projects are associated with a particular MCU at creation time. The target MCU determines the project memory layout, startup code, LinkServer flash driver, libraries, supporting sources,launch configuration options etc. etc. so changing a project’s associated MCU should not be undertaken unless you have a total grasp of the consequence of this change. Therefore rather than changing a project’s associated MCU, it is strongly recommended that instead a new project is generated for the desired MCU and this new project is edited as required. However, on occasion it may be expedient to reset a project’s MCU (and associated SDK) and this can be achieved as follows. For example, changing lpc55s69 to lpc55s06, we need install SDKs for lpc55s69 and lpc55s06 before all the below steps. 1 - Change MCU & Package 1.1 – Change MCU Right click “MCU” under Project tree, choose “Edit MCU” Uncheck ”Preserve memory configuration”(it is checked by default)->choose LPC55S06->there is a warning, choose Yes. We can see the Memory details changed to lpc55s06, then click ”Apply and close”. 1.2 – Change Package 2 - Change Compiler Definitions In Properties view->Settings->MCU Compiler ->Preprocessor, change the definition for CPU from LPC55S69JBD100 to LPC55S06JBD64 as below: 3 – Change/add SDK driver for LPC55s06 Selected project, then click ”Manage SDK components”, choose the drivers our application used, for example, clock, power, usart. Click “OK”, then click “Yes” to update. Delete LPC55S69 device related files: Add “system_LPC55S06.c” and “system_LPC55S06.h” files: 4 - Change startup file. Delete LPC55s69 startup files, add “startup_lpc55s06.c”, we can find the startup file in any SDK demo. 5 - Change board related files. Refer to our own new board, change files under “board” folder, for example pins, uart number, here directly copy from SDK demo for LPCxpresso55s06 board. 6 - Test the project  function with new board Build project until no compile error, download and run it, result as below.        

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!

This document introduces how to debug TrustZone project on MCUXpresso IDE.   Use the latest version of MCUXpresso IDE v10.3.1. Project is from SDK_2.5.0_LPCXpresso55S69. Board is LPCXpresso55s69, use the LinkServer debug probe(on board debugger).   Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project. The secure project is stored in SDK_2.5.0_LPCXpresso55S69\boards\lpcxpresso55s69\trustzone_examples\<application_name>\ cm33_core0 \<application_name>_s directory. The non-secure project is stored in SDK_2.5.0_LPCXpresso55S69\boards\lpcxpresso55s69\ trustzone_examples\<application_name>\ cm33_core0 \<application_name>_ns directory. The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project. In this document, we use “hello_world” as example, this project contains both “hello_world_s” and “hello_world_ns” projects. Unlike Keil or IAR IDE, MCUXpresso IDE can’t debug jump directly from secure project to no-secure project, so we need add the no-secure executable file to secure project debug configuration manually(For this version of MCUXpresso IDE v10.3.1, we need do this step, while for  the later new versions, maybe they support jump directly from secure project to no-secure project ). Steps outline: Import “hello_world_s” and “hello_world_ns” project. Build “hello_world_s” and “hello_world_ns”, without any error. Erase flash. Program no-secure project “hello_world_ns ”. Kill active debug. Add the location of file “lpcxpresso55s69_hello_world_ns.axf” to Debugger commands of “hello_world_s” project, and download “hello_world_s” project. After finish download, it stop at “hello_world_s” project, set a breakpoint at “hello_world_ns” project: Debug project Detailed steps please refer to DOC in attachment. Hope it helps, BR Alice

1. General Jointly developed by NXP and Embedded Artists, the MCU-Link Pro is a fully featured debug probe that can be used with MCUXpresso IDE and 3rd party IDEs that support CMSIS-DAP and/or J-Link protocols. MCU-Link Pro is based on NXP’s MCU-Link architecture, found in the MCU-Link low cost debug probe and on board evaluation boards, and runs the same firmware as all these implementations. In addition to SWD debug, SWO profiling and a USB to UART bridge features (VCOM) found in the base MCU-Link, the Pro model adds a J-Link LITE firmware option, energy measurement, analog signal monitor, USB to SPI and I2C bridging capability and an on-board LPC804 for peripheral emulation. MCU-Link Pro is based on the dual Arm® Cortex-M33® core LPC55S69 microcontroller, and features a high speed USB interface, providing high performance debug at low cost. The USB bridging feature is supported by the free LIBUSBSIO host library from NXP. MCU-Link Pro is compatible with Windows 10, MacOS and Linux. The product comes with the necessary firmware installed, with free utilities provided to enable future firmware updates from NXP to be installed. MCU-Link Pro kit provides all parts that need to be used. Kit Contains MCU-Link Pro debug probe 10 pin to 10 pin Cortex debug cable 10 pin to 20 pin Cortex debug cable Digital port / analog input adapter cable Spare jumpers 2. MCU-Link Pro Overview MCU-Link Pro has complete functions. This article mainly introduces the usage and precautions of several basic functions, including SWD debugging, UART (VCOM) and energy measurement. The following figure is the reference diagram of MCU Link Pro, covering all functions, and the highlighted part is the function used in this article.   2.1 SWD debug As a debugger, the most basic function of MCU Link Pro is debugging, and now commonly used is SWD debug. When you get the development board, you can see that there are three SWD interfaces on it. Only J7 is the SWD interface to debug target board. It is on the opposite side of the USB interface to facilitate the connection and debugging of the target board. The other two interfaces J3 and J11 are SWD interfaces of LPC55s69 and LPC804 respectively. Another important function of this debugger is that it can supply power to the target board. The use method is to connect J6 with jumper, and 1.8V and 3.3V power supply can be selected through J5. The specific connection is shown in the figure below: - Connect the SWD interface of J7 and target board with debug line. - J6 connecting jumper cap (supplying power to target board).  The USB cable connects J1 and the computer, so you can debug with MCUXpresso IDE or other IDEs. CMSIS-DAP and J-Link debugging protocols are supported. For how to update the debugger firmware, please refer to:https://www.nxp.com/document/guide/getting-started-with-the-mcu-link-pro:GS-MCU-LINK-PRO   2.2 UART (VCOM) Usage In the development and debug stage, users often need to print information through the serial port. Using MCU Link Pro, without additional hardware, directly connect the TX and Rx of target UART with the Rx / TX of UART of MCU Link Pro. Through the VCOM function, you can print information from the USB port to the serial port assistant at the PC end. The specific connection is shown in the figure below: - J19-8 (purple line) connects UART TX of target board - J19-9 (gray line) connects the UART RX of the target board - J19-1 (GND) connect GND of target board - J14 disconnected - J6 plug in the jumper cap (supply power to the target board)   2.3 Energy measurement The MCU Link Pro board contains a circuit that can measure the current or voltage of the target board, and it can be calibrated automatically every time it is powered on without manual intervention. There are two maximum measurement ranges for energy measurement. If the data is higher than the maximum range, the measurement result is inaccurate. The two maximum measurement ranges are as follows, which need to be configured with J16, J17 and J18.   Energy measurement needs to be used with MCUXpresso IDE, and the results are displayed in the IDE interface. Use J9 port on the board. The specific connection is shown in the figure below: - J9-1 connects the power supply end of the target board. - J9-3 connects the chip ends of the target board. - J9-2 connects the GND of the target board For details on how to use the MCU Xpress IDE interface, please refer to：<MCUXpresso_IDE_Energy_Measurement.pdf> 3. Test result The test results are as follows:          

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; } }  Attaching herewith the codes of the Master and Slave. I hope it helps!!

Symptoms Many LPC55 users experienced connection failure when using ISP USB0 for firmware update. In practice, we don’t suggest user updating firmware via ISP USB0 for LPC55(S)6x/ 2x,LPC55(S)1x/0x parts. Diagnosis LPC55 USB0 is Full Speed USB port. The default setting of CMPA turns off the USB0 port. Some users may reconfigure CMPA to enable ISP USB0 in order to use ISP USB0 BOOT, but this is not recommended in practice. LPC55 ISP USB0 uses internal FRO as clock source. According to LPC55 data sheet, the FRO accuracy is only +-2%, while the FS USB data rate tolerance specification is +-2500ppm(+-0.25%). Obviously, the LPC55 FRO spec can’t meet the USB0 clock accuracy requirement. See below extraction from NXP manuals. Fig 1. The accuracy of FRO ( Extracted from LPC55S69 Datasheet )   Fig 2. The accuracy requirement of USB FS( Extracted from TN00063 )  Some users may wonder why USB0 can use internal FRO as clock source in the user application?  Whenever internal clock source FRO is used as USB0 clock source, we must calibrate FRO in source code for communication. That’s to say, trim FRO to an accurate frequency. We can see FRO trim in many MCUXPressoSDK USB demos. When using FRO as the USB0 clock source, in order to ensure the USB0 clock accuracy, we must use the USB0 SOF frame synchronization to calibrate the FRO in order to ensure the accuracy of FS USB clock source (reference design of TN00063, TN00063-LPC5500 Crystal-less USB Solution). Unfortunately, the BOOT ROM of LPC55 does not support USB SOF calibrating FRO. As a result, even if we enable ISP USB0, the FRO clock drift can still cause USB0 communication failure under non-room temperature conditions. Solution Since ISP USB0 is not recommended for firmware update, the user manual no longer announces the enablement bit of ISP USB0 in CMPA. If you need to use USB0 for firmware update, we recommend using ISP USB1 (High Speed USB), because USB1 uses accurate external clock source which can ensure the ISP USB1 working stable. In addition, the communication protocol of ISPUSB complies with BLHOST specification. For details, see:  blhost User's Guide - NXP  

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.