LPC Microcontrollers Knowledge Base

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

LPC Microcontrollers Knowledge Base

Discussions

Sort by:
  [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
[解决方案] 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
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
Introducing the LPC550x/S0x family of MCUs The LPC550x/S0x is an extension of the LPC5500 MCU series based on the Arm® Cortex®-M33 technology, featuring up to 256kB of Flash memory and 96kB of on chip RAM. There are up to 8 Flexcomm (choice of any 8 serial –I2C/UART/SPI) and one dedicated 50MHz SPI, and CAN FD(CAN 2.0 for LPC550x). The dual 16-bit ADC can do two independent conversions simultaneously at 2MSPS, there are up to 10 ADC input channels. The comparator has 5 input pins and an external reference voltage.   LPC55S0x MCUs have the Arm TrustZone® technology support and are powered with a security acceleration engine (CASPER) and Secure ROM to provide the support for RSA base authentication. The on chip Physical Unclonable Function (PUF) uses a dedicated SRAM for silicon fingerprint instead of storing the Root key, which means there is no way to read the root key without powering the device up. It also features a True Random Number Generator (TRNG), AES encryption/decryption engine, 128 bit unique device serial number for identification (UUID) and Secure GPIO.   Powering the System Operating at up to 96MHz, the active power consumption of the LPC550x is only 32uA/MHz. The on chip flash is optimized for low power hence it does not perform well in pure Flash and CPU benchmark like the EEMBC Coremark. However in practice, most applications have relatively slow peripherals like I2C, UART, being the bottleneck.  The MCU’s low power consumption performance means that a lot of power is being saved for the system. In addition, high power efficiency enables the LPC550x devices to run much cooler than most 32-bit MCUs. The on-chip DC-DC gives >85% power conversion efficiency, result in very little energy loss as heat inside the chip. In fact LPC5500 MCU series has <2 deg C self-heating when operating at the max frequency. The highly accurate (+/-2% at full temp range, +/-1% from 0 to 85 deg C) on chip Free Running Oscillator (FRO) provides the 96MHz without the need of addition PLL or external crystal for running UART, reducing power consumption. The simple power modes:  Sleep, deep-sleep with RAM retention, power-down with RAM retention and CPU retention, and deep power-down with RAM retention; Provide user the choice on what to keep alive when going into low power mode. In addition, LPC550x/S0x MCUs can be woken-up from configurable peripherals interrupts like the 32kHz RTC, resulting in more power savings.   Powering the Future The LPC550x/S0x family provide a powerful 32-bit MCU with 256kB Flash, low power (active and leakage) at a price point the current existing Cortex-M33 base MCU in the market cannot meet.   Let the LPC550x/S0x power your next product! Learn more about this family at www.nxp.com/LPC550x. Here's the picture of the LPC55S06 EVK board    
View full article
Some customers want to generate CRC checksum during compile project, while the GUN tool chain in MCUXpresso IDE doesn’t include CRC checksum calculation function, so we need  the help of CRC checksum tools. In this article, use SRecord. About detail theoretical knowledge of SRecord, please refer to https://mcuoneclipse.com/2015/04/26/crc-checksum-generation-with-srecord-tools-for-gnu-and-eclipse/ In this thread, mainly describe the steps about how to generate CRC checksum with MCUXpresso IDE post-build, through a hands on.   Environment: LPC54S018 chip MCUXpresso IDE SRecord tool (http://srecord.sourceforge.net/)   Purpose: Generate and place CRC checksum to 0x10000170 of LPC54s018 after compile project. In image header for LPC540xx devices, the offset 0x10 is crc_value, in LPC54s018 , the address is 0x10000170. so we need save CRC checksum value in  this  place.   Steps: Import SDK demo “led_blinky” into MCUXpresso IDE (Just use this demo to demonstrate).   Enable Compute CRC, because there is one bit in Image header for LPC540xx,Just add “ADD_CRC” or “ADD_CRC =1”, build project.     Can check from S19 file: When choose no CRC computation (no defined “ ADD_CRC “ symbol), the data in address 0x0164 bit0 is 1,   When choose compute CRC, the data in address 0x0164 bit0 is 0,        Download SRecord from http://srecord.sourceforge.net/ After download, srec_cat.exe is the main program we used. Place srec_cat.exe utility in a common directory (to reuse it even if you change the project or even the MCUXpresso IDE version). Be sure you add that “common directory” in the PATH environment variable, then be sure the eclipse was restarted to “see” the PATH content.   Create command file crc_add.txt, and place it under" Debug" folder of project. (About detail commands, please refer to SRecord Reference Manual.) # srec_cat command file to add the CRC and produce application file to be flashed # Usage: srec_cat @filename #first: create CRC checksum lpcxpresso54s018m_led_blinky.srec # input file -fill 0xFF 0x10000180 0x10010000 # fill code area with 0xff -crop 0x10000180 0x10010000 # just keep code area for CRC calculation below (CRC will be at 0x1FFFE..0x1FFFF) -CRC16_Big_Endian 0x10000170 -CCITT # calculate big endian CCITT CRC16 at given address. -crop 0x10000170 0x10000172 # keep the CRC itself #second: add application file lpcxpresso54s018m_led_blinky.srec # input file -fill 0xFF 0x10000180 0x10010000 # fill code area with 0xff -crop 0x10000000 0x10000170 0x10000172 0x10010000 #keep all except CRC #finally, produce the output file -Output # produce output lpcxpresso54s018m_led_blinky_crc.srec   Add post-build command to create srecord file with CRC checksum. arm-none-eabi-objcopy -v -O srec "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.srec" & srec_cat.exe @CRC_add.txt   7) Build project, the .srec with CRC checksum file will under Debug folder:         Pay attention: For the format of image header of LPC540xx devices, we need enable compute CRC and put the CRC value in the specific address. while for other chips, maybe do not need enable, and also can place it in your own address.   Reference: https://mcuoneclipse.com/2015/04/26/crc-checksum-generation-with-srecord-tools-for-gnu-and-eclipse/        
View full article
This document describes the different source clocks and the main modules that manage which clock source is used to derive the system clocks that exists on  LPC’s devices. It’s important to know the different clock sources available on our devices, modifying the default clock configuration may have different purposes since increasing the processor performance, achieving specific baud rates for serial communications, power saving, or simply getting a known base reference for a clock timer. The hardware used for this document is the following: LPC: LPCXpresso55S69 Keep in mind that the described hardware and management clock modules in this document are a general overview of the different platforms and the devices listed above are used as a reference example, some terms and hardware modules functionality may vary between devices of the same platform. For more detailed information about the device hardware modules, please refer to your specific device Reference Manual. LPC platforms The System Control Block (SYSCON) facilitates the clock generation in the LPC platforms, many clocking variations are possible and the maximum clock frequency for an LPC55S6x platform is @150MHz. For example, the LPC55S69 device supports 2 external and 3 internal clock sources. ·    External Clock Sources   Crystal oscillator with an operating frequency of 1 MHz to 32 MHz.   RTC Crystal oscillator with 32.768 kHz operating frequency.   ·    Internal Clock Sources Internal Free Running Oscillator (FRO). This oscillator provides a selectable 96 MHz output, and a 12 MHz output (divided down from the selected higher frequency) that can be used as a system clock. These 96MHz and 12MHz output frequencies come from a Free Running Oscillator of 192MHz. The 12MHz output provides the default clock at reset and provides a clean system clock shortly after the supply pins reach operating voltage. Note that the 96MHz clock can only be used for a USB device and is not reliable for USB host timing requirements of the data signaling rate.  32 kHz Internal Free Running Oscillator FRO. The FRO is trimmed to +/- 2% accuracy over the entire voltage and temperature range. This FRO can be enabled in several power-down modes such as Deep-Sleep mode, Power-Down mode, and Deep power-down mode, also is used as a clock source for the 32-bit Real-time clock (RTC).  Internal low power oscillator (FRO 1 MHz). The accuracy of this clock is limited to +/- 15% over temperature, voltage, and silicon processing variations after trimming made during assembly. This FRO can be enabled in Deep-Sleep mode, used as a clock source for the PLL0 & PLL1, and for the WWDT(Windowed Watchdog Timer). The LPC55S69 can achieve up to 150MHz but the clock sources are slower than the final System Clock frequency (@150MHz), inside the SYSCON block two Phase Loop Locked (PLL0 & PLL1) allow CPU operation up to the maximum CPU rate without the need for a high-frequency external clock. These PLLs can run from the Internal FRO @12 MHz, the external oscillator, internal FRO @1 MHz, or the 32.768 kHz RTC oscillator. These multiple source clocks fit with the required PLL frequency thanks to the wide input frequency range of 2kHz to 150 MHz. The PLLs can be enabled or disabled by software. The following diagram shows a high-level description of the possible internal and external clock sources, the interaction with the SYSCON block, and the PLL modules.    Figure 1. General SYSCON diagram   SYSCON manages the clock sources that will be used for the main clock, system clock, and peripherals. A clock source is selected and depending on the application to develop the PLL modules are used and configured to perform the desired clock frequency. Also, the SYSCON module has several clock multiplexors for each peripheral of the board i.e(Systick, FullSpeed-USB, CTimer), so each peripheral can select its source clock regardless of the clock source selection of other peripherals. For example, the following figure shows these described multiplexers and all the possible clock sources that can be used at the specific module.  Figure 2. Source clock selection for peripherals   For more detailed information, refer to “Chapter 4. System Control (SYSCON)” from the LPC55S6x User Manual.  Example: Enabling/Disabling PLLs The Clock tools available in MCUXpresso IDE, allows you to understand and configure the clock source for the peripherals in the platform. The following diagram shows the default PLL mode configured @150MHz, the yellow path shows all the internal modules involved in the clock configuration. Figure 3. Default PLL mode @150MHz at Reset of LPC55S69   For example, you can use the Clock tools to configure the clock source of the PLL to use the clk_in coming from the internal 32MHz crystal oscillator, the PLL is configured in bypass mode, therefore the PLL gets inactive resulting in power saving. Figure 4. Bypass of the PLL For more detailed information about PLL configuration, refer to “Chapter 4.6.6. PLL0 and PLL1 functional description” from the LPC55S6x User Manual.  Example: The next steps describe how to select a clock source for a specific peripheral using Clock Tools. 1.1 Configure clock for specific peripheral To configure a peripheral as shown in figure 17, Clock Tools is also useful to configure the clock source for the desired peripheral. For example, using the CTimer0 the available clock sources are the following: Main Clock PLL0 Clock FRO 96MHz Clock  FRO 1MHz Clock MCLK Clock  Oscillator 32KHz Clock No Clock(Inactive)                  Figure 5. CTimer0 Clock Source Selector Select CTIMERCLKSEL0 multiplexor and then switch to one of the mentioned clock sources, for example, the main_clk(Main Clock @150MHz) the clock multiplexor gets active and the yellow path is highlighted as shown in the following image.    Figure 6. CTimer0, Main Clock attached 1.2 Export clock configuration to the project After you complete the clock configuration, the Clock Tool will update the source code in clock_config.c and clock_config.h, including all the clock functional groups that we created with the tool. This will include the clock source for specific peripherals. In the previous example, we configured the CTimer0 to use the main_clk; this is translated to the following instruction in source code: “CLOCK_AttachClk(kMAIN_CLK_to_CTIMER0);” inside the “BOARD_BootClockPLL150M();” function.                      Figure 7. API called from clock_config.c file Note. Remember that before configuring any internal register of a peripheral, its clock source needs to be attached, otherwise, a hard fault occurs. References LPC55S6x/LPC55S2x/LPC552x User Manual Also visit RT's System Clocks Kinetis System Clocks
View full article
I updated the design for the Mini-Monkey and used PCB:NG for fabrication.
View full article
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 
View full article
A demonstration of decoding animated GIF files from internal flash on the LPC55S69.   I ported this library:   GitHub - bitbank2/AnimatedGIF: A lightweight Arduino GIF decoder for playing animated files from memory or files on SD c…    The code for the MiniMonkey can be found here:   https://bitbucket.org/ehughes_/minimonkey-sw/src/master/   
View full article
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.
View full article
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
View full article
Live at Computex 2018 this week is: The High Performance Gaming Mouse Controlling Hundreds of Full Color LEDs Powered by LPC51U68 A 100MHz Arm® Cortex®-M0+ delivering real-time response for game player 96K SRAM for LED pattern allows for a smooth transition  Built-in USB drivers in ROM and supports 1K report rate 8 Flexcomm serial channels to drive up to 800 LEDs with full color control at the same time
View full article