LPC Microcontrollers Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC Microcontrollers Knowledge Base

Discussions

Sort by:
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:          
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
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
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
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.
View full article
  [LPC546xx] Understanding ECRP   Code protection is usually considered at the last step during developing stage. The purpose is to protect our code being hacked when the product is released to market. For example, using ECRP to disable SWD debug interface, disable ISP, disable mass erase, etc. 1.    ECRP vs Legacy CRP   ECRP (Enhanced Code Read Protection) is versus legacy CRP on early LPC devices. We can consider ECRP as an advanced version of CRP. Comparing with CRP, ECRP adds new protection features: − Block ISP via Pins − Block ISP using IAP − Block SWD − Mass Erase enable/disable − Sector protection This table lists the difference of ECRP vs. CRP from Anti-Tampering and Flexible view. 2.    Understand and implement ECRP ECRP allows user to tenable below features: − Protect FLASH from ISP Erase/Write − Protect FLASH from IAP Erase/Write − Enable/Disable ISP Entry from bootloader − Enable/Disable ISP Entry from IAP call − Enable/Disable SWD Enable/Disable It looks easy but it is important to know that ECRP feature is controlled by both FLASH and OTP configuration! The most restrictive combination in both setting is needed 2.1          Where is FLASH ECRP: ECRP is at 0x20 of vector table, it’s uint32_t type. We write to this address to set FLASH ECRP protection. The valid bits of FLASH_ECRP is 0-17bit, and the default value is 0xFFFF_FFFF. For detail, please see UM.   2.2          Where is OTP ECRP OPT is a non-volatile and write-once register. OTP is not FLASH and it can be ONLY written by IAP function. OPT ECRP configuration is at OPT bank 3. The default OTP ECRP value is 0.   2.3          FLASH ECRP + OTP ECRP Decides the Protection. See this table to show the combination. Here OTP ECRP is always set with higher priority than FLASH ECRP! Here is typical ECRP settings 2.4        Be Attention! The part is permanently disabled when On-chip Image(s) are ruined SWD access prohibited ISP entries prohibited Please be attention when testing ECRP feature, mis-operation may make the chip brick!
View full article
This is an example of how to use the CTimer to trigger the LPADC conversion in the LPC55s28. I attached the example in MCUXpresso.    
View full article
LPC: Regarding to Internal Clock Calibration In MCU development, using the internal crystal oscillator as a clock source instead of the external crystal oscillator can save costs. But the clock frequency generated by the internal crystal oscillator is affected by temperature and MCU frequency more than external crystal oscillator. Many customers have questions about the internal clock accuracy, whether the internal clock can be used for USB transmission, and how to calibrate the internal clock. This article mainly explains this. 1. Calibrate internal clock by FREQTRIM Normally, we can only calibrate the internal clock by adjusting the FREQTRIM value. The internal clock frequency is affected by temperature, MCU frequency and other factors. The FRO control register can calibrate the internal clock, as follows:   The FREQTRIM register value ranges from 0 to 255, and each adjustment step is about 0.1% of the internal clock frequency. There is no precise formula to express the relationship between the FREQTRIM value and the FRO frequency. The ideal FREQTRIM value can only be determined by adjusting FREQTRIM in code and observing FRO output waveform with oscilloscope. Test and observation: The following is the test result. It shows how FRO frequency varies with FREQTRIM increasing from 0-255. Test result of first development board:     Test result of second development board:   The following two points can be seen from test results: - There is no linear relationship between the FRO clock frequency and the FREQTRIM register value, and there is no precise formula to express the relationship between them; - Even for chips of the same part number, the internal clock frequency changes are slightly different, with the FREQTRIM register value changing, but the trend is same. Therefore, there is no precise formula to guide internal clock frequency calibration. You can only adjust the FREQTRIM register value repeatedly, just like adjusting the focus of a projector. Use an oscilloscope to check the frequency of the internal clock pin to find the most suitable FREQTRIM register value. There is same solution for FRO clock frequency calibration about other LPC chips.   2. LPC51U68: Software calibration USB transmission when using internal clock source The Full Speed USB module of LPC51U68 has a unique FRO automatic calibration function, which automatically adjusts the FREQTRIM value to achieve FRO calibration by measuring the USB SOF bit. Once FRO is calibrated, the corresponding system clock and peripheral clock are calibrated. This solution is only applicable to LPC51U68, please refer to the user manual for other chips. The following is the FRO clock accuracy described in LPC51U68 User Manual, which is ±1%:   For Full Speed USB, the USB data transmission accuracy requirement is ±0.25%, and the FRO clock accuracy is not satisfied. NXP provides a software solution to calibrate FRO by measuring the first packet of frame (SOF), which can meet the transmission accuracy in Full Speed mode.   The solution download link is as follows: https://www.nxp.com/docs/en/application-note/TN00035.zip  
View full article
After LPC54XXX enter ISP mode, there are two methods to upgrade the application through UART/I2C/SPI/USB. One method is to change the ISP pin state when power on, and the other method is to reinvoke ISP Boot ROM in source code during code running. The first method does not require user to write any code, and the operation is simple, but the disadvantage is that it is not flexible and is not suitable for on-site operation; The second method is more flexible and is widely used in Secondary Bootloader applications developed by yourself, but it requires users to write their own code. In actual development, because the USB port of personal computer is easy to use, the method of using the USB port for application upgrade is becoming more and more popular. Unfortunately, we currently do not have instructions for upgrading the application by the USB port in ISP mode. So we write this article to share the method here.   There are two methods to enter ISP mode: Method 1: Enter ISP mode to upgrade the application during power on On the hardware side, configure the ISP0~2 pins before power-on or reset, and the MCU enters ISP mode to upgrade the application. The pin configuration method is as follows: Figure 1.   Method 2: Activate Reinvoke ISP in source code to upgrade the application In ISP mode, the application is upgraded through UART/I2C/SPI/USB. This article focuses on the USB method. Here for USB, Both USB0 (Full Speed) and USB1 (High Speed) of LPC54XXX can be used for application upgrade. There are two USB upgrade modes: DFU (Device Firmware Updata) and MSC (Mass Storage Device Class), as follows: Figure 2.   Select the application upgrade mode by modifying byte 0 and byte 1 of the ISP parameter array. The key code is as follows Figure 3.   There are 3 key point we need to pay attention in Figure 3: -When isp_mode[0] is configured as 0xAA, it is DFU mode, otherwise it is MSC mode (for example, isp_mode[0] is configured as 0xFF). -When isp_mode[1] is configured as 8, USB FS is used, and when it is configured as 9, USB HS is used. -Enter the ISP mode through the Chip_IAP_ReinvokeISP function. 2.1 Use DFU for application upgrade Tool preperation: To work with DFU, dfu-util tool is needed to use DFU to upgrade the application, you can download the DFU tool on the DFU official website. The link is as follows: http://dfu-util.sourceforge.net/ NXP also includes the dfu-util tool in LPCScrypt. If you have downloaded LPCScrypt, you can use it directly in the bin directory.   DFU update application Steps: Take LPC54628 as an example, ISP is configured as DUF mode, and USB1 is used to upgrade the application. Modify the relevant code in Figure 3, as follows: isp_mode[0] = 0xAA; isp_mode[1] = SL_USBHS; Build and download the application to the MCU, power on again, and connect USB1 to the computer. Here Enter the dfu-util tool directory and copy the .bin file to the current directory. Use the command: ./dfu-util -l   Find the DFU devices. Use the command: ./dfu-util -D .\lpcxpresso54628_gpio_led_output.bin -a 0 Download the lpcxpresso54628_gpio_led_output.bin file to the device with alt number 0. Alt0 is "FLASH", alt1 is "RAM", and the specific operations are as follows:   Figure 4.   After downloading the application successfully, reset the MCU and observe the blinking phenomenon of the LED on the development board.   2.2 Use MSC for application upgrade Take LPC54628 as an example, ISP is configured as MSC mode, and USB1 is used to upgrade the application. Modify the relevant code in Figure 3, as follows: isp_mode[0] = 0xFF; isp_mode[1] = SL_USBHS; Build and download the application to the MCU, power on again, and connect USB1 to the computer. You will found another disk in my computer, as follows: Figure 5.   Then do the following to update firmware: -Remove the original firmware.bin in the CRP DISABLD disk. -Rename the application (for example, lpcxpresso54628_gpio_led_output.bin) to firmware.bin. -Copy the application firmware.bin to the CRP DISABLD disk. -Reset the MCU, if the LED is observed blinking, it proves that the application has been successfully upgraded. Note: The application must be renamed, and the rename cannot be performed in the CRP DISABLD disk.   Demo project:lpcxpresso54628_flashiap.zip Application upgrade file:lpcxpresso54628_gpio_led_output.bin (generated by SDK demo code)
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
经常有客户在使用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
Contents     The default storage address space of code and data. 1     Customize Flash and RAM partitions. 2     Place the data in the specified address space. 3     Place the function in the specified address space. 4     Place the specified file in the specified address space. 5   During MCU development, placing data, function, and file in the specified memory address according to actual requirements is important for the memory usage. We Combine customer’s frequent ask questions, explain how to operate these features step by step. 1.     The default storage address space of code and data Take the hello world demo in LPC54628 as an example, and the development environment: MCUXpresso IDE. After building, the memory allocation is as shown in the following console window:   The relationship between .text, .data, .bss, .dec and Flash and RAM is as follows:   2.     Customize Flash and RAM partitions In order to place the data, function or file in the specified address space, we split some new partitions. Open the project property setting interface, and split MY_FLASH and MY_RAM address spaces in the MCU settings option for testing. The size of these two address spaces can be customized, as follows:   After configuring Flash and RAM, click ‘Apply and Close’ button and you will see Flash2 and RAM2 in the project column, as follows: 3.     Place the data in the specified address space 1)The default storage address space of variables and constants View the default address space of variables and arrays, as follows: Initialized variable:uint16_t value1 = 1; Uninitialized array:char data_buffer1[1024]; Constant array:   const char data_buffer2[1024] = "hello nxp"; View storage address space of arrays using the Image Info window in MCUXpresso IDE, as follows:   Readable and writable variables and arrays are stored in RAM (0x20000000-0x20014000) named "SRAM_UPPER" by default, and const arrays are stored in Flash (0x0-0x40000) named "PROGRAM_FLASH".  2) Place the specified variables and constants in the specified address space To place the array in custom Flash and RAM, you need to call the C language: __attribute__ ((section(#type #bank))) For example, place the data in .text of Flash2: __attribute__ ((section("text_Flash2" ".$Flash2"))) + data declaration The NXP official has encapsulated this and defined it in cr_section_macros.h. __DATA(RAM2) means that the readable and writable array is placed into the .data section of RAM2, and __RODATA(Flash2) means that the read-only array is placed into the .rodata section of Flash2. __DATA(RAM2) char data_buffer3[1024]; __RODATA(Flash2) const char data_buffer4[1024] = "hello nxp"; Note that you must #include "cr_section_macros.h".   Global variables and arrays are placed in custom RAM2 (0x20014000-0x20028000) named "MY_RAM", and const arrays are placed in custom Flash2 (0x40000-0x80000) named "MY_FLASH". 4.      Place the function in the specified address space 1)The default storage address space of functions The code is placed in the Flash (0x0-0x40000) named "PROGRAM_FLASH" by default, and the following function is defined: int hello1(void) {         return 1; } 2)Place the specified function in the specified address space To place the function in custom Flash, you need to call the C language: __attribute__ ((section(#type #bank))) For example, place the function in .text of Flash2: __attribute__ ((section("text_Flash2" ".$Flash2")))+function declaration The NXP official has also encapsulated this and defined it in cr_section_macros.h. The method to change the address space of the function is as follows, and place the function in a custom Flash named "MY_FLASH" (0x40000-0x80000). __TEXT(Flash2) int hello2(void) {                return 2; }   5.      Place the specified file in the specified address space When there are many functions that need to be placed in the specified Flash, it is a little clumsy to use the __TEXT(Flash) method to set each function. If you need to place all the functions in the c file in the specified Flash, you only need to place the compiled .o file in the specified Flash. Split a new partition named "MY_FLASH_O" , create a new hello.c under the source folder, compile and generate hello.o, and configure Linker Script to place hello.o in the partitioned Flash, as follows:   Reference: https://mcuoneclipse.com/2021/05/26/placing-code-in-sections-with-managed-gnu-linker-scripts/ Relocating Code and Data Using the CW GCC Linker File for Kinetis .pdf  
View full article
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.        
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
The ADC converter for LPC55Sxx is a new IP, it has a lot of new features. The ADC converter clock frequency must be less than 24MHz, the ADC converter sampling rate can reach up to 1MSPS, the ADC converter supports to sample both the single-end analog signal and differential analog signal. It supports software triggering mode and hardware triggering mode, the triggering source can be from internal Timer, external pins, comparator output signal. The ADC converter supports synchronous sampling for only single-ended analog channel, but the analog channel pair are fixed for example CH0A/CH0B and CH1A/CH1B. The ADC of LPC55S6x consist of 16 Trigger Control (TCTRLa) registers, one trigger control register corresponds one hardware trigger source. For example, the TCTRL[0] corresponds trigger source0 GPIO irq_pint[0], the TCTRL[1] corresponds trigger source1 GPIO irq_pint[1]. When the GPIO IRQ_PIN[0] signal edge is detected, the ADC will be trigger to convert the analog channel. Hardware trigger Mapped to 0 GPIO irq_pint[0] 1 GPIO irq_pint[1] 2 State Configurable Timer (SCT) sct0_outputs[4] 3 State Configurable Timer (SCT) sct0_outputs[5] 4 State Configurable Timer (SCT) sct0_outputs[9] 5 State Counter Timer (CTIMER) ct0_mat3_out 6 State Counter Timer (CTIMER) ct1_mat3_out 7 State Counter Timer (CTIMER) ct2_mat3_out 8 State Counter Timer (CTIMER) ct3_mat3_out 9 State Counter Timer (CTIMER) ct4_mat3_out 10 Comparator 11 ARM tx event 12 GPIO BMATCH   The trigger attributes is defined in the corresponding TCTRLaXX register, when the TCTRLaXX[HTEN]=0, software trigger is enabled, hardware trigger is disabled. Setting the SWTRIG[xx] bit will trigger ADC to start conversion. The TCTRLaXX[TCMD] specifies which command buffer is executed.   There are 15 command buffers (CMDa), each consists of  two 32-bit registers (CMDLa:CMDHa), which specifies the ADC channels, resolution, sampling time.. For all the examples, a hardware triggering mode example is developed, the hardware triggering source 7 “State Counter Timer (CTIMER) ct2_mat3_out” is used to trigger ADC, so TCTRL[7] register is initialized, the TCMD bits in TCTRL[7] register is set up as 1, so the CMDH[1]:CMDL[1] are initialized to configure the analog channel, ADC sample resolution… .  
View full article
The series of LPC540XX chips are flashless, only LPC54018JXM and LPC54S018JXM integrate internal QSPI Flash. The typical part numbers are LPC54018J2(4)M and LPC54S018J2(4)M. Some customers have questions about the concept of SPIFI interface and clock configuration when using this series of chips. This article mainly explains this. Introduction to SPIFI SPIFI (SPI Flash Interface) is an SPI Flash interface that can help microcontrollers replace large-size, high-cost parallel Flash with small-size, low-cost serial Flash. Using SPIFI technology, the external serial FLash can be mapped to microcontroller memory to achieve on-chip memory read effect, that is, cost can be optimized and Flash size can be increased while ensuring the operating speed. The electrical interface of SPIFI is as follows:   In the LPC540XX series of chips, if the part number includes M, QSPI Flash is integrated inside chip; if the part number does not include M, the QSPI Flash is externally connected to chip. The following picture shows the comparison of LPC54S018JXM and LPC54S018 in SPIFI structure:   SPIFI clock frequency description Taking LPC54S018J4M as an example, the SPIFI clock frequency is described below in the UserManual. SPIFI supports 1/2/4bit transmission mode. In 4bit transmission mode, the maximum transmission rate is SPIFI_CLK/2 bytes per second. The data transmission rate is up to 52Mbytes /s, that is, it takes two clock to transmit one byte. If you want to configure the SPIFI transmission rate to 52Mbytes /s, it needs to be in 4bit mode, so SPIFI_CLK is configured to 104M.     The SPIFI clock source is as follows in LPC54S018J4M Datasheet. By default, the SPIFI clock source is FRO96. For example, when the SPIFI clock is configured to 96M, in 4bit transmission mode, the transmission rate is 96/2=48Mbyte/s.   The LPC54S018J4M uses W25Q32JV-DTR as the internal SPIFI Flash. The figure below shows the maximum clock frequency it supports. In 4bit transmission mode, the maximum transmission rate is 133/2=66.5Mbyte/s, which is greater than SPIFI's maximum transmission rate of 52Mbyte/s. It shows that the maximum data transmission rate of W25Q32JV can meet the requirements of LPC54S018J4M QSPI Flash interface for communication rate.   3.Change SPIFI clock frequency The description of the SPIFI clock frequency in UserManual is as follows. In setup_lpc54s018m.c, the SPIFI clock frequency is defined on the address with an offset of 0X1C (the macro is defined as IMG_BAUDRATE), and the initial value is 0. According to the following table, when IMG_BAUDRATE=0, the SPIFI clock frequency is 24M. Since the default SPIFI clock source is the internal clock FRO96M, the SPIFI clock can be configured up to 96MHz in the following table by modifying the value of IMG_BAUDRATE.          There are two ways to modify the SPIFI clock.   3.1 Modify the SPIFI clock through IMG_BAUDRATE Before the main function runs, IMG_BAUDRATE is obtained by BOOT ROM to set the SPIFI clock frequency. If the requirement for the SPIFI clock rate is less than or equal to 96M, it is recommended to directly change the macro definition of IMG_BAUDRATE in setup_lpc54s018m.c to change the SPIFI clock frequency, as follows:   3.2 Modify the SPIFI clock through system config Another method is to modify the SPIFI clock frequency by changing the SPIFI frequency division coefficient in user code, as follows:   The result is as follows. The SPIFI clock frequency is set to 96M.   If you want to configure a higher SPIFI working clock, such as 104M, you must use a higher frequency external clock source to adjust the PLL coefficient and SPIFI frequency division coefficient in order to achieve the required clock frequency.
View full article
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  
View full article
This article mainly introduces how to use CTIMER measuring pulse-width in LPC845, in fact, it can applies to all LPC products  including CTIMER modules. 1  CTIMER has below features: A 32-bit timer/counter with a programmable 32-bit prescaler. Four 32-bit match registers that allow interrupt generation on  match. The timer and prescaler may be configured to be cleared on a designated capture event. This feature permits easy pulse width measurement by clearing the timer on the leading edge of an input pulse and capturing the timer value on the trailing edge.(This article mainly use this feature.) Up to four match registers can be configured for PWM operation.   2 Introduction There is neither pulse-width measurement nor input capture demo under SDK, so write this article and related code for this topic. The principle is clearing the timer and prescaler on the leading edge of an input and capturing the timer valued on the trailing edge.   3  Main steps   Step1 Choose CAP input channel, capture edge, and enable interrupt if needed. Using “Capture control register”. The Capture control register is used to control whether one of the four capture registers is loaded with the value in the timer counter when the capture event occurs, and whether an interrupt is generated by the capture event. Setting both the rising and falling bits at the same time is a valid configuration, resulting in a capture event for both edges. In the description below, n represents the timer number, 0 or 1. In this example, choose capture channel 0 as input channel, falling edge as capture edge, and enable capture interrupt. SDK code: CTIMER_SetupCapture(CTIMER,CTIMER_CAP0_INT,  CTIMER_CAP_FALL,TRUE); Step2 Select which capture input edge will cause the timer and pre-scaler to be cleared. Using “Count control register”. The Count Control Register (CTCR) is used to select between timer and counter mode, and in counter mode to select the pin and edge(s) for counting. When counter mode is chosen as a mode of operation, the CAP input (selected by the CTCR bits 3:2) is sampled on every rising edge of the APB bus clock. After comparing two consecutive samples of this CAP input, one of the following four events is recognized: rising edge, falling edge, either of edges or no changes in the level of the selected CAP input. The timer counter register is incremented only if the identified event occurs and the event corresponds to the one selected by bits 1:0 in the CTCR register. Effective processing of the externally supplied clock to the counter has some limitations. Since two successive rising edges of the APB bus clock are used to identify only one edge on the CAP selected input, the frequency of the CAP input cannot exceed one half of the APB bus clock. Consequently, duration of the HIGH/LOWLOW levels on the same CAP input in this case cannot be shorter than 1/APB bus clock. Bits 7:4 of this register are also used to enable and configure the capture-clears-timer feature. This feature allows for a designated edge on a particular CAP input to reset the timer to all zeros. Using this mechanism to clear the timer on the leading edge of an input pulse and performing a capture on the trailing edge, permits direct pulse-width measurement using a single capture input without the need to perform a subtraction operation in software. In this example, we choose timer mode, configure Channel 0 rising edge clearing the timer, enable clearing of the timer and the pre-scaler. SDK code:   CTIMER->CTCR = CTIMER_CTCR_CTMODE(0)|CTIMER_CTCR_SELCC(1)   |CTIMER_CTCR_ENCC_MASK ; Step3 Read pulse-width value from “Capture register”. Each Capture register is associated with one capture channel and may be loaded with the counter/timer value when a specified event occurs on the signal defined for that capture channel. The signal could originate from an external pin or from an internal source.   SDK code: CTIMER_GetCAPCounter(HW_CTIMER0, HW_CTIMER_CH0); We can read capture value on capture interrupt. Detail code please refer to attached project, it based on MCUXpresso IDE v11.3, SDKv2.9, LPCxpresso845MAX board.   4  Test Result Input a signal as below into channel 0 (P1_0), pulse width is 10us. Print the measurement results on Console view of MUXpresso IDE:        
View full article
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!!
View full article