LPC Microcontrollers Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC Microcontrollers Knowledge Base

Discussions

Sort by:
1    introduction The doc demonstrates how to use MRT(Multi-rate Timer) module to implement the delay function, the delay time is programmable. The MRT has a One-shot stall mode, with the mode, while the MRT channel counter counts down, the core stalls until the MRT channel counter reaches to zero. After the MRT channel counter reaches to zero, the MRT channel becomes idle, the core continues to work.   2 delay function description Sometimes, it is expected that there is a programmable delay between two instructions, for example Instruction 1 Delay Instruction 2 In general, the delay function can be implemented by forcing the core to execute __asm(“NOP”) instructions This code is like: Void delay(uint32_t interval) {        Uint32_t counter;        Counter=ConvertTimeToCounter(interval);        For(uint32_t i=0; i<counter); i++)        {        __asm(“nop”)        } }   The macro convertTimeToCounter is used to convert a time to a number of loop   1.   MRT feature The MRT module of LPC family provides a unique feature called One-shot stall mode, because the test is based on LPC55S69-EVK board, so I referred to the section 27.5.3 One-shot stall mode in UM11126.pdf. The MRT does not have external pad.   One-shot stall mode: Bus stall mode can be used when a short delay is need between two software controlled events, or when a delay is expected before software can continue. Since in this mode there are no bus transactions while the MRT is counting down, the CPU core stalls, consumes a minimum amount of power during that time until the MRT counter reaches to zero. Therefore the One-shot stall mode of MRT can make core stall during the MRT counting down process, the delay function can be implemented.   3 MRT clock source and delay time For the LPC55S69, the clock source of MRT module is the AHB Bus clock, which is the same as the core clock. For the LPC55S69 example, there is the code to set up the core clock void BOARD_InitBootClocks(void) {     BOARD_BootClockPLL150M(); } So the  MRT clock frequency is 150MHz.       The delay time is a time, but the MRT is a counter, so the delay time must be converted to the counter value. The counter value is dependent on the MRT clock frequency. The MRT clock source is AHB bus clock, or the core clock. The LPC55S69 core clock frequency is 150Mhz, so we can define #define MRT_CLOCK_FREQUENCY 150MHz If the required delay time is delay_time variable in second unit, the required MRT counter value is   MRT counter value=delay_time/(MRT clock cycle time)=delay_time* MRT_CLOCK_FREQUENCY.   For example, assume the required delay_time is 1mS or 1*10**(-3)  Second, the corresponding counter value is 1*(10**-3)*150*(10**6)=150 000   The MRT delay time restriction. The MRT counter register is 24 bits, the maximum counter value is 2**24= 16,777,216, the maximum delay time is 16777216/(150*10**6)=0.111848 S or 111 mS.     3 source code description MRT delay function source code is based on SDK package SDK_2_11_1_LPCXpresso55S69.zip, the tools is MCUXpresso IDE v11.5.0. The example is run on LPC55S69-EVK The example uses MRT to delay 100mS(0.1 Second), after the delay, a LED is toggled The MRT counter value is 0.1S*150*(10**6)=15 000 000   For the mrt_init() api function, it initializes the MRT and set the MRT channel0 in OneShotStall mode. Once the core executes the line MRT_StartTimer(MRT0, kMRT_Channel_0, 15000000); the MRT channel0 counter will count down from 15000000, during the counting process the Cortex-M33 will stall. After the counter reach to ZERO, the core finishes the stalling mode and continues to execute the next line, the MRT channel0 counter will be in idle mode.       /**  * @file    LPC55S69_Project_mrt_stall.c  * @brief   Application entry point.  */ #include <stdio.h> #include "board.h" #include "peripherals.h" #include "pin_mux.h" #include "clock_config.h" #include "LPC55S69_cm33_core0.h" #include "fsl_debug_console.h" #include "fsl_mrt.h" #include "fsl_iocon.h"   /* TODO: insert other include files here. */ #define BOARD_LED_PORT BOARD_LED_BLUE_GPIO_PORT #define BOARD_LED_PIN  BOARD_LED_BLUE_GPIO_PIN /* TODO: insert other definitions and declarations here. */ void mrt_init(void); /*  * @brief   Application entry point.  */ int main(void) {       /* Init board hardware. */     BOARD_InitBootPins();     BOARD_InitBootClocks();     BOARD_InitBootPeripherals(); #ifndef BOARD_INIT_DEBUG_CONSOLE_PERIPHERAL     /* Init FSL debug console. */     BOARD_InitDebugConsole(); #endif     mrt_init();     PRINTF("Hello World\n");     for(;;)     {     MRT_StartTimer(MRT0, kMRT_Channel_0, 15000000);     GPIO_PortToggle(GPIO, BOARD_LED_PORT, 1u << BOARD_LED_PIN);     __asm("nop");       }     /* Force the counter to be placed into memory. */     volatile static int i = 0 ;     /* Enter an infinite loop, just incrementing a counter. */     while(1) {         i++ ;         /* 'Dummy' NOP to allow source level single stepping of             tight while() loop */         __asm volatile ("nop");     }     return 0 ; }   uint32_t mrt_clock; mrt_config_t mrtConfig; void mrt_init(void) {           /* mrtConfig.enableMultiTask = false; */         MRT_GetDefaultConfig(&mrtConfig);           /* Init mrt module */         MRT_Init(MRT0, &mrtConfig);           /* Setup Channel 0 to be repeated */         MRT_SetupChannelMode(MRT0, kMRT_Channel_0, kMRT_OneShotStallMode);           //MRT_StartTimer(MRT0, kMRT_Channel_0,  15000000);   }       }                                                                                                              When the above code is running, user can see the blue LED toggles on the LPC55S69-EVK board. Connecting the PIO1_4 pin signal ( the pin 5 of P18 connector) on LPC55S69-EVK, the PIO1_4 signal toggling frequency is 5Hz, the cycle time is 200mS, so the delay is 100mS.      
View full article
Introducing the LPC550x/S0x family of MCUs The LPC550x/S0x is an extension of the LPC5500 MCU series based on the Arm® Cortex®-M33 technology, featuring up to 256kB of Flash memory and 96kB of on chip RAM. There are up to 8 Flexcomm (choice of any 8 serial –I2C/UART/SPI) and one dedicated 50MHz SPI, and CAN FD(CAN 2.0 for LPC550x). The dual 16-bit ADC can do two independent conversions simultaneously at 2MSPS, there are up to 10 ADC input channels. The comparator has 5 input pins and an external reference voltage.   LPC55S0x MCUs have the Arm TrustZone® technology support and are powered with a security acceleration engine (CASPER) and Secure ROM to provide the support for RSA base authentication. The on chip Physical Unclonable Function (PUF) uses a dedicated SRAM for silicon fingerprint instead of storing the Root key, which means there is no way to read the root key without powering the device up. It also features a True Random Number Generator (TRNG), AES encryption/decryption engine, 128 bit unique device serial number for identification (UUID) and Secure GPIO.   Powering the System Operating at up to 96MHz, the active power consumption of the LPC550x is only 32uA/MHz. The on chip flash is optimized for low power hence it does not perform well in pure Flash and CPU benchmark like the EEMBC Coremark. However in practice, most applications have relatively slow peripherals like I2C, UART, being the bottleneck.  The MCU’s low power consumption performance means that a lot of power is being saved for the system. In addition, high power efficiency enables the LPC550x devices to run much cooler than most 32-bit MCUs. The on-chip DC-DC gives >85% power conversion efficiency, result in very little energy loss as heat inside the chip. In fact LPC5500 MCU series has <2 deg C self-heating when operating at the max frequency. The highly accurate (+/-2% at full temp range, +/-1% from 0 to 85 deg C) on chip Free Running Oscillator (FRO) provides the 96MHz without the need of addition PLL or external crystal for running UART, reducing power consumption. The simple power modes:  Sleep, deep-sleep with RAM retention, power-down with RAM retention and CPU retention, and deep power-down with RAM retention; Provide user the choice on what to keep alive when going into low power mode. In addition, LPC550x/S0x MCUs can be woken-up from configurable peripherals interrupts like the 32kHz RTC, resulting in more power savings.   Powering the Future The LPC550x/S0x family provide a powerful 32-bit MCU with 256kB Flash, low power (active and leakage) at a price point the current existing Cortex-M33 base MCU in the market cannot meet.   Let the LPC550x/S0x power your next product! Learn more about this family at www.nxp.com/LPC550x. Here's the picture of the LPC55S06 EVK board    
View full article
The LPC55S6x family was initial silicon die version was 0A, and this silicon was using on Revision A1 LPCXpresso55S69 boards. Revision 1B silicon has been used on Revision A2 boards. Both versions of silicon support the new, more robust debug session request method, but 1B silicon requires its use. If the correct version of IDE and/or debug probe drivers are not used then debug operation will be affected or non-functional.  When using Revision A2 boards, the current software release versions are required: MCUXpresso IDE Version  11.0.1 or later (11.1 or later recommended) [Note: IDE 11.0.1 may also be used but when using Revision A1 boards a hot fix is required for this release. See  MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix ] Note that you may need to start from a new workspace if transitioning from one developed using a Revision A1 board to a Revision A2 board (or any target system using Revision 1B silicon). IAR Embedded Workbench version 8.40.2 or later Keil uVISION LPC55S6x Device Family Pack (DFP) 12.0.1 or later SEGGER J-Link J-link version 6.54c or later should be used (from the SEGGER download site), and V6.64 or later is recommended. When using J-link with non-SEGGER IDEs (MCUXpresso, IAR, Keil), ensure that you IDE configuration is pointing to the latest J-Link drivers. If using MCUXpresso IDE 11.0.1 the included J-link drivers need to be updated to the latest version to support Revision A1 boards. See Updating a SEGGER J-Link installation on Windows for more information. For more information about silicon revision and tools, please refer to Understanding LPC55S6x Revisions and Tools  Please also note that there are Chinese versions of description regarding board revision, silicon revision and the corresponding tools as shown below: 中文版:LPC55S6x 版本更新及开发工具注意事项 中文版:LPC55S6x 0A和1B版本区别进阶
View full article
For the CM33 of LPC55S6x family, the trust zone module is integrated, the memory space and peripherals are classified as security and non-security space. In order to generate interrupt in non-security mode, the NVIC module including the NVIC_ITNSx register must be initialized in security mode so that interrupt module can generate interrupt in non-security mode. The example demos that MRT0 module generates interrupt in non-security mode, the NVIC module is initialized at security mode, MRT0 is initialized at non-security mode. The project is based on MCUXpresso IDE ver11.1 tools, LPC55S69-EVK board and SDK_2.x_LPCXpresso55S69 SDK package version 2.11.1.
View full article
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.  
View full article
经常有客户在使用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(),查看结果  
View full article
  需求: 客户需要对Image文件做出完整性检测,利用IDE固有功能添加这类信息简便且可靠,以往有类似的link提到了这些配置,对于LPC55系列,需要做一些更新。 CRC Checksum Generation with MCUXpresso IDE - NXP Community Solution 基于MCUX环境 下载 SRecord http://srecord.sourceforge.net/ srec_cat.exe是下载后我们主要使用的工具,通过为其添加一个系统变量名,将SRecord目录加入系统路径     重启MCUX IDE之后可以在工程配置中看到该变量:       创建一个脚本文件crc_add.txt,放在debug目录下,用于填充app后的flash空余位置为0xFF, 并后续生成CRC32值并放置0x00037FFC位置。最终生成的srec文件为包含所有内容的image。           # srec_cat command file to add the CRC and produce application file to be flashed # Usage: srec_cat @filename #first: create CRC checksum lpcxpresso55s06_hello_world_image_length_MCUX.srec # input file #-fill 0xFF 0x00000000 0x00038000 # fill blank code area with 0xff from 0x00000000 to 0x00038000 (0x00038000是把LPC55S06的末尾地址稍往前提,实际因为0x0003D7FF) -fill 0xFF 0x00000000 0x00037FFC #填充0-0x37FFC区间的未用地址为0xff -crop 0x00000000 0x00037FFC # just keep code area for CRC calculation below , 保留这段区间的内容,排除除此范围内的其他数据 #-CRC16_Big_Endian 0x00037FFE -CCITT # calculate big endian CCITT CRC16 at given address., 为以上空间数据计算CRC16,并放置在0x00037FFE地址,2字节 -CRC32_Little_Endian 0x00037FFC -CCITT #CRC32 -crop 0x00037FFC 0x00038000 # keep the CRC itself #second: add application file lpcxpresso55s06_hello_world_image_length_MCUX.srec # input file -fill 0xFF 0x00000000 0x00037FFC # fill code area with 0xff -crop 0x00000000 0x00037FFC #-crop 0x10000000 0x10000170 0x10000172 0x10010000 #keep all except CRC #finally, produce the output file -Output # produce output lpcxpresso55s06_hello_world_image_length_MCUX_crc.srec      创建一个crc_file_convert.txt文件,也放在debug目录下,用于将上一步生成的最终image的srec文件转换为bin文件,用于生成或者比对 # srec_cat command file to add the CRC and produce application file to be flashed # Usage: srec_cat @filename #third: create bin file lpcxpresso55s06_hello_world_image_length_MCUX_crc.srec -o lpcxpresso55s06_hello_world_image_length_MCUX_crc.bin -binary 在IDE的Post build栏目添加如下命令:     arm-none-eabi-size "${BuildArtifactFileName}"   默认自带的统计image size功能 arm-none-eabi-objcopy -v -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin"    将image转成bin文件,用于后续使用和比对 arm-none-eabi-objcopy -v -O srec "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.srec" & srec_cat.exe @CRC_add.txt 填充image,计算CRC32,整合成新的srec image srec_cat.exe @CRC_file_convert.txt  将上一步得到的srec image转化为bin文件,用于后续使用和比对   《hello_world_image_length_MCUX》例程会自行统计应用程序的CRC32值,并于IDE产生的CRC32值做比对   这里需要注意的是,由于MCUX IDE是借助于外部工具来填充flash和计算CRC32,所以默认IDE调试和下载选择afx文件并不包含这些信息。当校验程序开始运行,会发生: 读写未写入的flash,对于LPC55系列会发生hardfault CRC32值并不存在 所以测试这个程序需要单独下载包含所有的srec文件或者bin文件,而不是默认的afx文件。      
View full article
1.     Problem description When we debug a new designed LPC55 custom board through SWD, if IDE throws out error messages such as connection failure or no available device being found, normally we must check below two points: Whether the debug circuit design is correct.(https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/Design-Considerations-for-Debug/m-p/469565#M44) Whether LPC55 power supply system is correct. Regarding to the second point of power supply system, we received many feedback from customers that even they read UM for times they still can’t well-understand LPC55xx DCDC power supply system. Therefore we prepare this article to analyze LPC55xx power supply circuit and introduce detection method. 2.     Problem Analysis The difference of power supply circuit between LPC55xx series and other LPCs is that LPC55xx uses DCDC circuit inside to provide core voltage. It lowers the input 1.8V-3.6V voltage to around 1.1V to supply LPC55xx internal system. The DCDC converter is efficient and reduces the internal power consumption. The disadvantage is that it generates a certain ripple. LPC55xx power supply circuit is as follows: In order to analyze, We divide LPC55xx power supply circuit into 4 regions and will introduce them one by one according to the different functions.   1)  Input voltage: In this part, VBAT_PMU provides input voltage to RTC and internal analog components. VBAT_DCDC provides input voltage to internal DCDC circuit. 2)  A set of filter capacitors: To filter out the burrs and glitch at the voltage input. 3)  DCDC circuit: Work with LPC55xx internal DCDC circuit together to generate 1.1V output voltage. 4)  VDD_PMU: Provides the 1.1V output voltage of the DCDC circuit to the LPC55xx core. Note: The design of region 3 is to work with the internal DCDC converter. The inductance L1 of 4μ7H and the capacitance C1 of 22μF are calculated by LPC55xx internal circuit. When designing, we must strictly follow the parameters recommended in the manual, otherwise DCDC circuit can’t work normally. 3.     DCDC Circuit Detection LPC55xx power supply system current direction is shown in the diagram below. See arrow in red. In order to ensure the normal operation of the DCDC circuit, the following two detection points are recommended. 1)  Detection point 1: External 1.8 to 3.6V voltage input, normally it’s 3.3V. 2)  Detection point 2: Output of the DCDC converter. If the DCDC works normally, we can get 1.1V voltage output here. The output voltage supplies power to the core components such as the central processing unit through the VDD_PMU. If DCDC convert input is correct but output wrong, we suggest checking inductor L1 and the capacitor C1 and related solder issue. If the voltage of two detection points are correct, the power supply circuit problem can be ruled out. 4.     summary: For custom designed LPC55xx board, if SWD design is correct and power supply system works well, IDE can connect, download and debug target without issue.  
View full article
MCUXpresso SDK for LPC55xx uses FLASH API to implement FLASH drivers. Some user may meet issue when executes FLASH program code, for instance: status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8); After execution this code, nothing changed in the destination address, but error code 101 returns: This error code looks new, as it doesn’t commonly exist in other older LPCs. If we check FLASH driver status code from UM, code 101 means FLASH_Alignment Error: Alignment error Ah ha? ! Go back to the definition of FLASH_Program, status_t FLASH_Program(flash_config_t *config, uint32_t start, uint32_t *src, uint32_t lengthInBytes); New user often overlooks the UM description of this API “the required start and the lengthInBytes must be page size aligned”. That’s to say, to execute FLASH_Program function, both start address and the length must be 512 bytes-aligned. So if we modify status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8); To status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 512); FLASH_Program can be successful.   !!NOTE: In old version of SDK2.6.x, the description of FLASH_Program says the start address and length are word-aligned which is not correct. The new SDK2.7.0 has fixed the typo.  Keep in mind: Even you want to program 1 word, the lengInBytes is still 512 aligned, as same as destAdrss! PS. I always recommend my customer to check FLASH driver status code when meet problem with FLASH API. We can find it in UM11126, Chapter 9, FLASH API. I extract here for your quickly browse:   Happy Programming
View full article
The power measurement board includes eight measurement channels which support for eight programmable gain amplifiers(LTC6915) and two ADC converters(AD7175). The measurement board measures the voltage drop across sampling resistor, and send to the ADC after the voltage drop is processed by amplifier and make it available via SPI. Microcontroller LPC55S69 collects the data from the measurement circuit and send it to the host computer via USB VCOM port. The MCU can control the gain value of programmable gain amplifiers by SPI when different power circuit are measured. The host computer connects to the power measurement board through the USB virtual serial port, the MCU initializes and configures the measurement unit by SPI, and starts to measure the inside current and monitor the voltage. MCU adjust the gain parameter and then transmit current and voltage data to MCU by SPI, then MCU transmits the data to the host computer for processing and display through the virtual serial port. The voltage drop of the measured circuit to be measured is firstly amplified by the programmable amplifier LTC6915, and MCU monitor the state which whether the data is abnormal at the same time. R0 is the sampling resistor, LTC6915 is a selectable programmable amplifier, the gain can be set to 14 kinds, PGA gain parameter is adjusted when the current changes. ADC7175 is the 24-bit high-precision ADC, which is more advantageous in the application of small current measurement. When the MCU switches the low power mode to the normal mode, and the LTC6915 will reduce the gain value by SPI. The power measurement board provides easy connection method by two-wires cable. For example, the MIMXRT1180EVK and MIMXRT1020EVK are connected with power measurement board. The USB virtual COM is used for data transfer, and display by PMT(power management tool) or other PC GUI, the measurement power data include current, voltage and power. There are more detailed descriptions in the attachment.
View full article
Contents 1. Introduction 1 2. USB Demo based on MCUXpresso SDK 1     2.1 Update USB device demo: USB0->USB1 2     2.2 Update USB host demo: USB0->USB1 2     2.3 Update USB ROM demo: USB0-> USB1 3 3. USB Demo based on LPCOpen 3 4. Notes and Recap 4  1.     Introduction Most of LPC devices integrate USB module. NXP LPC currently integrates full-speed USB (FS, Full Speed, 12Mbps) and high-speed (HS, High Speed, 480Mbps) USB. Specifically, for the LPC series: - Some LPCs such as LPC55xx and LPC54xxx integrate both HS USB and FS USB. Usually USB0 is FS USB and USB1 is HS USB. - Some LPCs such as LPC43xx and LPC18xx integrate two HS USBs, so USB0 and USB1 are both HS USBs. The two most well-known NXP software packages for LPC series are MCUXpresso SDK and LPCOpen. MCUXpresso SDK is mainly for LPC products launched in recent years, while LPCOpen is used for earlier LPC derivatives. The USB demos included in these two packages run on USB0 by default. Most of NXP USB demos are for USB0 by default. This article is to introduce how to switch a USB0 demo to USB1 demo based on different software packages. 2.     USB Demo based on MCUXpresso SDK (e.g. LPC54XXX, LPC55XX) The MCUXpresso SDK USB demo codes are categorized as: - USB as Device: e.g. usb_device_cdc_vcom, usb_device_hid_generic, etc. - USB as Host: e.g. usb_host_hid_mouse, usb_host_msd_fatfs, etc. - USB demo based on USB ROM API: e.g. usb_rom_device_audio,usb_rom_device_cdc, etc. 2.1  Update USB device demo: USB0->USB1 Taking usb_device_cdc_vcom demo as an example. To switch to USB1, simply change the corresponding code in usb_device_config.h file as follows. /*! @brief LPC USB IP3511 FS instance count*/ #define USB_DEVICE_CONFIG_LPCIP3511FS (0U) /*! @brief LPC USB IP3511 HS instance count*/ #define USB_DEVICE_CONFIG_LPCIP3511HS (1U) After the change, recompile the program to run. The program was updated to USB1 device demo. 2.2   Update USB host demo: USB0->USB1 Taking usb_host_hid_mouse demo code as an example, to switch to USB1, modify the macro definition in usb_host_config.h as follows: #defineUSB_HOST_CONFIG_KHCI (0U) #defineUSB_HOST_CONFIG_EHCI (0U) #define USB_HOST_CONFIG_OHCI (0U) #define USB_HOST_CONFIG_IP3516HS (1U)   The program is recompiled and run. The program was updated to USB1 host demo. 2.3  Update USB ROM demo: USB0-> USB1 ( e.g. LPC54XXX Series) USB ROM demo calls the USB ROM API, there is no way to switch the default USB0 to USB1 by modifying macro definitions. In order to update code to USB1 demo, the recommended steps are as below: -USB HS DEVICE and USB PHY clock configuration -Change to use USB HS ISR -Locate the related buffer into USB RAM. -Set the USB ROM handle to be HS If user has difficulties in revising the code by self, user can apply demo code from NXP LPC online support team by creating a private case. 3.     USB Demo based on LPCOpen (e.g. LPC43XX, LPC18XX) Some legacy LPCs run on LPCOpen, such as LPC43xx series, LPC18xx series. Their USB0 and USB1 are both high-speed. The default USB demo is for USB0 as well. To switch to USB1, we can uncomment #define USE_USB1 and comment #define USE_USB0 in app_usbd_cfg.h. // #define USE_USB0  #define USE_USB1 Taking usbd_rom_cdc_uart demo as an example:   Recompile and run, the program is updated to USB1 demo. 4.     Notes and Recap The focus of this article is on software modification of converting USB0 to USB1 on NXP SW package. Regarding the hardware, customer needs to check the specific demo board user guide. For example, when we use HS USB, it may be necessary to provide an external power supply, and the jumper also needs to be adjusted to build a well hardware environment for HS USB operation. I will not dwell on them here. This article summarizes methods of switching USB0 to USB1 for several commonly used LPC series on MCUXpresso SDK and LPCOpen package. customers who need USB1 demo code can find the corresponding modification methods in this article for their own software and chips. Official routines are only used for demo board demos and chip learning. If for commercial usage, user needs to learn USB in depth and be responsible for own application.  
View full article
Recently, customers reported that the number of PWM generated by SCTimer module was inconsistent between LPC55s06 user manual and data sheet. There are many kinds of PWM generation formats, so the maximum number of PWM generated by SCTimer is also different. I think the user manual and data sheet are not very clear, so this paper makes a specific analysis. It mainly depends on SCTimer resources, such as the number of events and output channels. For all LPC series, the mechanism of SCTimer generating PWM is the same. Therefore, this paper takes LPC55s6 as an example. LPC55s06 user manual: The SCTimer/PWM supports: – Eight inputs. – Ten outputs. – Sixteen match/capture registers. – Sixteen events. – Thirty two states. According to the different control modes of generating PWM wave, this paper is divided into single-edge PWM control, dual-edge PWM control and center-aligned PWM control. 1. Single-edge PWM control The figure below shows two single-edge control PWM waves with different duty cycles and the same PWM cycle length.   It can be seen from the above figure that the two PWM waves require three events: when the counter reaches 41, 65 and 100 respectively. Because of the same PWM cycle length, all PWM outputs need only one period event. Summary: The cycle length of all PWM waves are the same, so only one period event is required. The duty cycles of each PWM are different, and each PWM requires an event. The SCTimer of LPC55s06 has 16 events, one is used as PWM period event, and there are 15 left. Theoretically, 15 channels of PWM can be generated. However, LPC55s06 has only 10 outputs, so it can generate up to 10 single-edge control PWM waves. 2. Dual-edge PWM control The figure below shows three Dual-edge control PWM waves with different duty cycles and the same PWM cycle length.   It can be seen from the above figure that the three PWM waves require seven events: when the counter reaches 1, 27, 41, 53, 65, 78, 100.  Summary: PWM cycle length control needs one event, and each PWM duty cycle needs two events to trigger. The SCTimer of LPC55s06 has 16 events, one as PWM frequency event, and the remaining 15, so it can generate up to 7 dual-edge control PWM waves. 3. Center-aligned PWM control Center-aligned PWM control is a special case of dual-edge PWM control. The figure below shows two center-aligned PWM waves with different duty cycles and the same PWM duty length.   It can be seen from the above figure that the two center-aligned PWM waves need three events in total, which are the PWM cycle length and the duty cycle trigger of the two PWM waves. Because the left and right are symmetrical, only one event is needed to control the duty cycle of one PWM. Summary: All PWM have the same cycle length, so an event is required. The duty cycle of each PWM circuit is different, but the left and right are symmetrical, and an event trigger is required for each circuit. The SCTimer of LPC55s06 has 16 events, one is used as PWM cycle length, and there are 15 left. Theoretically, 15 channels of PWM can be generated, but LPC55s06 has only 10 outputs, so it can generate up to 10 channels of unilateral control PWM wave. Summary:   Maximum number of PWM generated by LPC55s6 SCTimer: Single-edge PWM control: 10 Dual-edge PWM control: 7 Center-aligned control: 10   The number of SCTimer events and output channels is different with different chips, but the analysis method is the same. Customers can analyze whether the SCTimer in a certain chip meets the requirements.
View full article
The Economist Intelligence Unit’s (EIU) 2020 IoT Index recently highlighted that 2020 will be the year when the Internet of Things (IoT) officially moves from “proof of concept” to “mass deployment”, with over half of all companies surveyed now undergoing early or extensive deployment of internal or external IoT networks. Read more >> NXP and Arm Pelion Device Management Secure Deployment of IoT Devices from Chip to Cloud | Pelion IoT Blog 
View full article
The document describes how to use DMA triggering mode to transfer data between memory and peripheral. In detail, the CTimer0_match0 is configured to generate matching event with programmable period, the CTimer0 matching event triggers DMA, the DMA transfer data between a variable in memory and GPIO Toggling register(the GPIO is connected to a LED), so user can see the LED toggling. The DMA Ping-Pong modes are used, so user can observe different LED toggles. The Example code is developed on SDK package, run on LPC55S69-EVK, the tools is MCUXpresso ver11.5.  
View full article
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.
View full article
[解决方案] IAR版本8.32无法调试’1B’版本的LPC55S69芯片   当您是第一次调试LPC55S69时,请阅读以下文档,并仔细检查您的IDE,SDK和EVK版本是否正确。 通常,我们推荐用最新的IDE,SDK和EVK板。 使用LPCXpresso55S69修订版A2板和1B芯片时的重要更新 [问题描述] 当您使用IAR 8.32调试LPC55S69'1B'芯片时,IDE会提醒您“调试会话无法启动”,如下图所示:   失败的原因是IAR 8.32的LPC55S69芯片配置文件仅支持0A 版本的芯片,而不支持'1B'。 我们强烈建议客户下载并使用IAR 8.40.2或最新版本。 IAR IDE从8.40.2开始支持LPC55S68'1B'芯片。 [解决方法] 如果出于某些原因必须使用IAR 8.32,则可以下载附加的zip文件。 该zip文件像补丁一样,包含IAR LPC55S69'1B'支持文件。   解压缩该文件并在IAR安装路径下合并相同的文件:IAR \ arm \ config \ flashloader \ NXP   这样之后IAR就可以支持“ 1B”芯片 [如何识别LPC55(S)6x芯片版本] 在顶部标记代码上,标记字符串的末尾有“ 1B”字符。 参见下面的两张图片,左边一张是“ 1B”版本芯片。   LPC55(S)6x ver '1B'                               LPC55(S)6x ver '0A'              标签: 0a  1b  8.32  8.40  iar  lpc55(s)69  patch
View full article
Symptoms Some users cannot access MCU peripherals normally by add peripheral initialization code to MCUXpresso SDK TrusZone demo. For example, when add Flash operation code in the security world, the program code jumps to HardFault_Handler after running to function FLASH_INIT(), and the execution of Flash erase and Flash program operations fails also, as follows: Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Diagnosis As shown in figure 2 and figure 3, when the program code runs to code return VERSION_FLASH_API_TREE->flash_init(config), it automatically jumps to HardFault_Handler. VERSION_FLASH_API_TREE is located in the 0x1301fe00 address of the boot rom, the flash erase api is located in address 0x1300413bU, and the flash program api is located in address 0x1300419dU (the corresponding program code is shown in figure 6). All above addresses are not security privilege. Figure 6        From the 7.5.3.1.2 TrustZone preset data chapter in user manual, after enabling the TrustZone configuration, users must configure the security level of the entire ROM address space to security priority (S-Priv) in order to ensure that the ROM area can be accessed normally by the security area code. Figure 7 Solution Below is the steps of how to resolve this issue. The demo is based on MCUXpresso SDK demo hello_world_s. Step 1: firstly we use the TEE tool integrated with MCUXpresso IDE to configure the security level of the Boot ROM address area, as shown in Figure 8, double-click the Boot-ROM area in the Memory attribution map window, and configure the sector’s security level in the corresponding Security access configuration window on the left. Figure 8 Step 2: Second, when operating Flash or other peripherals in the security area, users must configure the security level of correlative peripherals to the security priority(S-Priv).        When operating flash in the SDK TrustZone demo, the MCU uses two slave peripherals, so users must configure their security level to S-Priv. Figure 9 Please Note: From the usermanual, when operating flash, the system clock frequency cannot exceed 100MHZ. When using the function of FLASH_Program(), because the s_buffer is 512-byte aligned, the BUFFER_LEN is equal to 512/N.   The above configuration of the security level can be configured through the TEE tool integrated the MCUXpresso IDE. After completing configuration, click Update Code to automatically update the relevant code in the tzm_config.c file, as shown in Figure 10. Figure 10 The updated code is shown in Figure 11 below. It is obvious that the security level settings of boot rom memory and peripheral (FLASH, SYSCTRL) have changed. If you do not use the TEE tool, you can also manually modify tzm_config.c to configure the same security options. Figure 11 Third-party tools users: Because many users are accustomed to using third-party development tools such as Keil or IAR, but these IDEs do not integrate the TEE tool, users need to check the configuration requirements of related registers in user manual when modifying the security level of related areas and peripherals in TrusZone, and update the associated code in the tzm_config.c file (similar to Figure 11) to complete the related configuration. In addition, NXP released the MCUXpresso Config Tools, which integrates MCU-related configuration functions. Users can download and install this tool to perform configurations and update codes. The download link is as follows: https://www.nxp.com/design/software/development-software/mcuxpresso-software-and tools/mcuxpresso-config-tools-pins-clocks-peripherals:MCUXpresso-Config-Tools   Introduction of MCUXpresso Config Tools After the tool is installed, open the configuration tool, select Create a new configuration based on an SDK example or hello world project, click Next, as shown in Figure 12: Figure 12   In Start Development window, follow below steps to generate project. As shown in Figure 13. Figure 13 After the tzm_config.c file is updated, copy or import it to the corresponding folder of KEIL or IAR third-party development tools, and it can be used normally.          
View full article
For LPC55(S)1x/2x/6x users, please update your fsl_power_lib to SDK2.8.2. The previous SDK(2.6.x and 2.7.x)'s power library have two known function bugs,  1. FRO trim value can not be recovery correctly after wakeup from deep-sleep / power-down / deep power-down.    -- this means the 12MHz FRO frequency is different for after boot-process(11.99 MHz for example) and wakeup from low-power modes(11.89MHz for example).     -- The reason is the FRO trim value not recovery after wakeup.  2. Cap-bank value can not be set correctly by use power lib capbank trim API.    -- This is a software bug which fixed in SDK2.8.2 already. Just replacement the power_lib library file should be workable for most of customers. the API should be compatible. Thank you! Magicoe
View full article
View Webinar Recording
View full article
LPC55xx系列的MCUXpresso SDK使用FLASH API来实现FLASH驱动。 一些用户在执行如下FLASH写操作时可能会遇到如下的问题: status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8);       执行完上述代码后,对应的地址区间数据没有变化,写入失败,返回错误代码101,如下图所示, 错误代码101看上去有点陌生,这在之前的LPC产品中并不常见,我们在用户手册中搜索FLASH driver status code,可以查找到错误代码101为FLASH 对齐操作错误(Alignment Error)。   对齐操作错误是什么?我们先来看程序是如何对FLASH_Program函数进行定义的。 FLASH写函数定义如下: status_t FLASH_Program(flash_config_t *config, uint32_t start, uint32_t *src, uint32_t lengthInBytes); 新用户经常会忽略掉用户手册中对于这个API的介绍“the required start and the lengthInBytes must be page size aligned”,这句话的意思是在执行FLASH_Program函数时,写入的起始地址和数据长度必须512字节对齐,所以如果我们把代码 status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8); 更正为 status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 512); FLASH_Program函数就可以运行成功。   请注意:在2.6.x版本的SDK中,FLASH_Program函数的注释将参数的起始地址和数据长度错误的表述为字对齐,2.7.0版本的SDK已经对注释进行了修正。即使你想要操作一个字节,lengthInBytes也是512字节对齐。   最后:建议用户在遇到关于FLASH API操作失败的相关问题,一定要查看用户手册中的FLASH驱动状态码,我们可以从UM11126中的第九章节FLASH API部分找到它,如下图所示。  
View full article