LPCマイクロコントローラ・ナレッジ・ベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

LPC Microcontrollers Knowledge Base

ディスカッション

ソート順:
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.
記事全体を表示
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:          
記事全体を表示
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.  
記事全体を表示
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.
記事全体を表示
Summary A software vulnerability CVE-2021-40154 has been identified in the USB enumeration packet handler, which could leak memory contents if a malformed enumeration request packet is sent to the device. This may occur if the device is configured in the in-system programming (ISP) or serial downloader protocol (SDP) mode or if unpatched USB example code is used in an application.   Mitigations Mitigations have been applied to: The boot ROM in the latest silicon revisions of i.MX RT 500 and 600 and LPC55XX parts USB examples in the MCUXpresso SDK 2.10 release and later For other devices, the ISP/SDP mode and/or the USB communication mode can be disabled.   Affected product list:                 NXP Device     Impacted Silicon Revisions LPC55S6x, LPC55S2x, LPC552x                      0A, 1B LPC55S1x, LPC551x    0A i.MX RT600                                       A0, B0 i.MX RT500                                        B1, B2 i.MX RT1010/20/50/60 i.MX RT1160/70 All K8x/KL8x K27/K28 K32L3/ K32W032 / K32LA/K32LB  KL27/KL28/KL43                                    All   The vulnerability also affects all MCUXpresso SDK USB device stack examples prior to 2.10.x release. If the NXP device does not support USB or does not utilize the USB example code prior to version 2.10.x  in the application, then those would not be impacted. Additional Information Security bulletins with more details are available. For additional questions or support please contact your local NXP representative or submit a ticket at https://support.nxp.com/ Acknowledgments NXP PSIRT would also like to thank Sulthan Alaudeen Noor Mohamed from Digital14 – xen1thLabs, Hardware Labs for the responsible disclosure. _____________________________________________________________________________ Please note this information is preliminary and subject to change. To the best of NXP's knowledge, the information contained herein is accurate and reliable as of the date of publication; however, NXP does not assume any liability for the accuracy and completeness of the information.   Information in this document is provided solely to enable system and software implementers to use NXP products. There are no express or implied copyright licenses granted hereunder to design or fabricate any integrated circuits based on the information in this document. NXP reserves the right to make changes without further notice to any products herein. NXP makes no warranty, representation, or guarantee regarding the suitability of its products for any particular purpose, nor does NXP assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. “Typical” parameters that may be provided in NXP data sheets and/or specifications can and do vary in different applications, and actual performance may vary over time. All operating parameters, including “typicals,” must be validated for each customer application by customerʼs technical experts. NXP does not convey any license under its patent rights nor the rights of others. NXP sells products pursuant to standard terms and conditions of sale, which can be found at the following address: nxp.com/SalesTermsandConditions. While NXP has implemented advanced security features, all products may be subject to unidentified vulnerabilities. Customers are responsible for the design and operation of their applications and products to reduce the effect of these vulnerabilities on customer's applications and products, and NXP accepts no liability for any vulnerability that is discovered. Customers should implement appropriate design and operating safeguards to minimize the risks associated with their applications and products.
記事全体を表示
This is an example of how to use the CTimer to trigger the LPADC conversion in the LPC55s28. I attached the example in MCUXpresso.    
記事全体を表示
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部分找到它,如下图所示。  
記事全体を表示
[解决方案] 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
記事全体を表示
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.          
記事全体を表示
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!!
記事全体を表示
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    
記事全体を表示
https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2020/06/15/lpc55s69-powerquad-part-1-a-great-solution-for-the-industrial-iot-and-smart-metering 
記事全体を表示
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.
記事全体を表示
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
記事全体を表示
[中文翻译版] 见附件 原文链接: https://community.nxp.com/docs/DOC-343506
記事全体を表示
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 
記事全体を表示
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‌
記事全体を表示
When we use LPC55Sxx PRINCE feature, we need enable PRINCE sub-region “crypto” by setting SR_ENABLE register. If we “crypto” enable discontinuous sub-regions and erase part of them, we may find we can’t erase/read/write other “crypto” sub-regions any more. This article will discuss how to resolve this phenomenon.           Figure 1         Testing Steps According to LPC55Sxx UM, each PRINCE region has its SR_ENABLEx register. This register enables PRINCE encryption and decryption of data for each sub-region of crypto region 0. Each bit in this field enables a sub-region of crypto region 0 at offset 8kB*n, where n is the bit number.  For example, when we set SR_ENABLE0=0X00000005, PRINCE region 0 sub-region 1 and sub-region 3 are set as encryption region. When read data out from these sub-regions, PRINCE will decrypt the data automatically.   Now we will test discontinuous sub-region erase/read/write. Board: LPC55S16-EVK IDE: Keil MDK v5.29 Step 1: PRINCE initialization: Enable PRINCE region 0 and two discontinuous sub-regions; generate key, IV code; enable crypto. //set SR_ENABLE,SR_ENABLE=0X28000000,enable sub-regions(0x30000-0x32000,0x34000-0x36000) crypto。 status=PRINCE_SetRegionSREnable(PRINCE(prince_region_t)region0,0X28000000); //select PRINCE crypto for region0 PRINCE_SetRegionBaseAddress(PRINCE_Type*base,prince_region_tregion0,uint32_t0X0) //generate PRINCE region0 crypto key Status=FFR_KeystoreGetKC(&flashInstance,&keyCode[0],kFFR_KeyTypePrinceRegion0); status=PUF_GetHwKey(PUF,keyCode,sizeof(keyCode),kPUF_KeySlot2, rand()); //generate PRINCE region0 crypto IV_code status=PRINCE_GenNewIV(kPRINCE_Region0,&prince_iv_code[0],true,&flashInstance) //load IV code to PRINCE status=PRINCE_LoadIV(kPRINCE_Region0,&prince_iv_code[0]) //enable PRINCE encryption PRINCE_EncryptEnable(PRINCE)   Step 2: Select two discontinuous sub-regions ( 0x30000-0x32000,0x34000-0x36000). Erase one of them (0x30000-0x32000), then write data to this sub-region. Output: Erasing and Writing are all successful. See Figure 2. //Erase 0x30000-0x32000 sub-region status=PRINCE_FlashEraseWithChecker(&flashInstance,0x30000,0x2000,kFLASH_ApiEraseKey); //Write 0x30000-0x32000 sub-region status=PRINCE_FlashProgramWithChecker(&flashInstance,0x30000,(uint8_t *)prince_iv_code,0x2000);   Step 3: Erase and Write the other sub-region ( 0x34000-0x36000 ) Output: Erasing and Writing are failed. See Figure 2. //Erasing 0x34000-0x36000 sub-region status=PRINCE_FlashEraseWithChecker(&flashInstance,0x34000, 0x2000,kFLASH_ApiEraseKey); //Write 0x34000-0x36000 sub-region status=PRINCE_FlashProgramWithChecker(&flashInstance,0x34000, (uint8_t *)prince_iv_code,0x2000); Error Analysis According to UM11126(49.16.1 Functional details), each crypto region has its own SKEY and IV code. SKEY and IV are used together by the PRINCE when encrypting or decrypting the data in the sub-regions of crypto region. For Instance, For PRINCE region1, each time after we execute erasing operation, new Skey1 and IV1 are generated, thus when executing erase/read/write operation to another sub-region, the old IV1 and new IV1 don’t match, which causes PRINCE can’t decrypt correctly.   Suggestion We suggest user using SR_ENABLE to set continuous crypto sub-regions. When erasing operation is needed, erasing all the crypto sub-regions together, avoid erasing part of the sub-regions. One sub-region size is 8K, make sure the erasing/writing address 8K aligned.   Thanks for the suggestion from johnwu‌
記事全体を表示
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版本区别进阶
記事全体を表示