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  

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)

LPC55xx系列的MCUXpresso SDK使用FLASH API来实现FLASH驱动。 一些用户在执行如下FLASH写操作时可能会遇到如下的问题： status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8);       执行完上述代码后，对应的地址区间数据没有变化，写入失败，返回错误代码101，如下图所示, 错误代码101看上去有点陌生，这在之前的LPC产品中并不常见，我们在用户手册中搜索FLASH driver status code，可以查找到错误代码101为FLASH 对齐操作错误（Alignment Error）。   对齐操作错误是什么？我们先来看程序是如何对FLASH_Program函数进行定义的。 FLASH写函数定义如下： status_t FLASH_Program(flash_config_t *config, uint32_t start, uint32_t *src, uint32_t lengthInBytes); 新用户经常会忽略掉用户手册中对于这个API的介绍“the required start and the lengthInBytes must be page size aligned”，这句话的意思是在执行FLASH_Program函数时，写入的起始地址和数据长度必须512字节对齐，所以如果我们把代码 status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8); 更正为 status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 512); FLASH_Program函数就可以运行成功。   请注意：在2.6.x版本的SDK中，FLASH_Program函数的注释将参数的起始地址和数据长度错误的表述为字对齐，2.7.0版本的SDK已经对注释进行了修正。即使你想要操作一个字节，lengthInBytes也是512字节对齐。   最后：建议用户在遇到关于FLASH API操作失败的相关问题，一定要查看用户手册中的FLASH驱动状态码，我们可以从UM11126中的第九章节FLASH API部分找到它，如下图所示。  

[解决方案] IAR版本8.32无法调试’1B’版本的LPC55S69芯片   当您是第一次调试LPC55S69时，请阅读以下文档，并仔细检查您的IDE，SDK和EVK版本是否正确。 通常，我们推荐用最新的IDE，SDK和EVK板。 使用LPCXpresso55S69修订版A2板和1B芯片时的重要更新 [问题描述] 当您使用IAR 8.32调试LPC55S69'1B'芯片时，IDE会提醒您“调试会话无法启动”，如下图所示：   失败的原因是IAR 8.32的LPC55S69芯片配置文件仅支持0A 版本的芯片，而不支持'1B'。 我们强烈建议客户下载并使用IAR 8.40.2或最新版本。 IAR IDE从8.40.2开始支持LPC55S68'1B'芯片。 [解决方法] 如果出于某些原因必须使用IAR 8.32，则可以下载附加的zip文件。 该zip文件像补丁一样，包含IAR LPC55S69'1B'支持文件。   解压缩该文件并在IAR安装路径下合并相同的文件：IAR \ arm \ config \ flashloader \ NXP   这样之后IAR就可以支持“ 1B”芯片 [如何识别LPC55（S）6x芯片版本] 在顶部标记代码上，标记字符串的末尾有“ 1B”字符。 参见下面的两张图片，左边一张是“ 1B”版本芯片。   LPC55(S)6x ver '1B'                               LPC55(S)6x ver '0A'              标签： 0a  1b  8.32  8.40  iar  lpc55(s)69  patch

Symptoms Some users cannot access MCU peripherals normally by add peripheral initialization code to MCUXpresso SDK TrusZone demo. For example, when add Flash operation code in the security world, the program code jumps to HardFault_Handler after running to function FLASH_INIT(), and the execution of Flash erase and Flash program operations fails also, as follows: Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Diagnosis As shown in figure 2 and figure 3, when the program code runs to code return VERSION_FLASH_API_TREE->flash_init(config), it automatically jumps to HardFault_Handler. VERSION_FLASH_API_TREE is located in the 0x1301fe00 address of the boot rom, the flash erase api is located in address 0x1300413bU, and the flash program api is located in address 0x1300419dU (the corresponding program code is shown in figure 6). All above addresses are not security privilege. Figure 6        From the 7.5.3.1.2 TrustZone preset data chapter in user manual, after enabling the TrustZone configuration, users must configure the security level of the entire ROM address space to security priority (S-Priv) in order to ensure that the ROM area can be accessed normally by the security area code. Figure 7 Solution Below is the steps of how to resolve this issue. The demo is based on MCUXpresso SDK demo hello_world_s. Step 1: firstly we use the TEE tool integrated with MCUXpresso IDE to configure the security level of the Boot ROM address area, as shown in Figure 8, double-click the Boot-ROM area in the Memory attribution map window, and configure the sector’s security level in the corresponding Security access configuration window on the left. Figure 8 Step 2: Second, when operating Flash or other peripherals in the security area, users must configure the security level of correlative peripherals to the security priority(S-Priv).        When operating flash in the SDK TrustZone demo, the MCU uses two slave peripherals, so users must configure their security level to S-Priv. Figure 9 Please Note: From the usermanual, when operating flash, the system clock frequency cannot exceed 100MHZ. When using the function of FLASH_Program(), because the s_buffer is 512-byte aligned, the BUFFER_LEN is equal to 512/N.   The above configuration of the security level can be configured through the TEE tool integrated the MCUXpresso IDE. After completing configuration, click Update Code to automatically update the relevant code in the tzm_config.c file, as shown in Figure 10. Figure 10 The updated code is shown in Figure 11 below. It is obvious that the security level settings of boot rom memory and peripheral (FLASH, SYSCTRL) have changed. If you do not use the TEE tool, you can also manually modify tzm_config.c to configure the same security options. Figure 11 Third-party tools users: Because many users are accustomed to using third-party development tools such as Keil or IAR, but these IDEs do not integrate the TEE tool, users need to check the configuration requirements of related registers in user manual when modifying the security level of related areas and peripherals in TrusZone, and update the associated code in the tzm_config.c file (similar to Figure 11) to complete the related configuration. In addition, NXP released the MCUXpresso Config Tools, which integrates MCU-related configuration functions. Users can download and install this tool to perform configurations and update codes. The download link is as follows: https://www.nxp.com/design/software/development-software/mcuxpresso-software-and tools/mcuxpresso-config-tools-pins-clocks-peripherals:MCUXpresso-Config-Tools   Introduction of MCUXpresso Config Tools After the tool is installed, open the configuration tool, select Create a new configuration based on an SDK example or hello world project, click Next, as shown in Figure 12: Figure 12   In Start Development window, follow below steps to generate project. As shown in Figure 13. Figure 13 After the tzm_config.c file is updated, copy or import it to the corresponding folder of KEIL or IAR third-party development tools, and it can be used normally.          

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    

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/        

There are two ways to program LPC chips using Flash Magic, ISP mode and  Single Wire Debug (SWD) mode. ISP mode support COM port, USB, CAN and Ethernet. SWD support LINK2(LPC1800/lpc4300) bridge and LPC11u35 bridge. This article uses four demonstrations to show these programming methods.   1. ISP mode   1.1 UART ISP Mode Demonstration   1.2 USB ISP Mode Demonstration 2. Single Wire Debug(SWD) Mode   2.1 SWD over Link2 Bridge     2.1.1 Introduction     2.1.2 Demonstration  2.2 SWD over LPC11U35    2.2.1 Introduction    2.2.2 Demonstration    2.2.3 Recover board   Download Flash Magic tool from: https://www.flashmagictool.com/ Pay attention use the new version Flash Magic v13.10 or later.   About detail steps please refer to attachment. Thanks!

I updated the design for the Mini-Monkey and used PCB:NG for fabrication.

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 

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

LPCXpresso54608 development board up and running out of the box with our unified software development kit (SDK)!

[中文翻译版] 见附件 原文链接： https://community.nxp.com/docs/DOC-343506

LWIP debug output or application messages can be routed out to one of the serial ports by configuring the debug options. Enabling debug output in LWIP To enable debug code in LWIP, the "LWIP_DEBUG" flag needs to be defined when compiling the LWIP code. This can usually be done by using the "-D" option to define the flag as part of the argument list for the compiler. For example in the Keil tools, you can add the define C/C++ tab of the target options dialog. To enable specific debug messages in LWIP, just set the specific define value for the LWIP *_DEBUG value to " LWIP_DBG_ON". A full list of debug defines that can be enabled can be found in the opts.h file. Just copy the defines for the debug messages you want to enable into the lwipopts.h file for your project and enable them there. A few examples are shown below. #define TCP_DEBUG                       LWIP_DBG_ON #define ETHARP_DEBUG                    LWIP_DBG_ON #define PBUF_DEBUG                      LWIP_DBG_ON Selecting debug output The UART channel used for debug outputcan be selected by setting the UART_REDIRECT define to the UART number. On the LPC177x_8x devices, setting this to 0, 1, or 2 will enable output for UART ports 0, 1, or 2, respectively. You can completely disable output (while keep the debug code inside LWIP) by setting UART_REDIRECT to -1. As of release v1.01, simply enabling LWIP_DEBUG as the compilation define will automatically select the right UART for debug output. You can still override the UART for output if needed, but will need to edit the UART in the debug framework file. Caveats of enabling debug output Enabling debug output can add significant size to the generated code based on the debug options selected for the build. It will also slow down performance of the LWIP code due to required run-time checks and output. It's is recommended to enable debug support only if needed. Enabling just the UART for debug output adds about 4KBytes to the code size and about 512 bytes to the data size. The UART driver uses a ring buffer for buffering debug output with the UART IRQ to feed that data to the UART. The ring buffer size can be changed by changing the "UART_RING_BUFSIZE" define value in the serial.c file. Note: The call to initialize the debug framework used for LWIP debug output and printf() is active in the examples by default. Just remove the call to debug_frmwrk_init() in the examples to save some additional code and data memory. You may have also to remove the redirect.c file from the project for this change. Enabling debug output in the LWIP code uses a varying amount of memory based on which LWIP *_DEBUG defines are enabled. Without LWIP debug output enabled and the options selected below, the code size is increased by an additional 23.5KBytes and the data size increased by 1.6KBytes. #define LWIP_DEBUG #define TCP_DEBUG                       LWIP_DBG_ON #define ETHARP_DEBUG                    LWIP_DBG_ON #define PBUF_DEBUG                      LWIP_DBG_ON #define IP_DEBUG                        LWIP_DBG_ON #define TCPIP_DEBUG                     LWIP_DBG_ON #define DHCP_DEBUG                      LWIP_DBG_ON #define UDP_DEBUG                       LWIP_DBG_ON Note memory usage was checked at the 'default' compiler optimization setting. Example debug output Some example debug output use for capturing TCPIP, ethernet ARP, PBUF allocaiton and de-allocation, etc. are shown in the example output below captured from a LWIP run. Ethernet link not yet detected, will continue Starting LWIP ping server... dhcp_start(netif=1000eddc) en0 dhcp_start(): starting new DHCP client dhcp_start(): allocated dhcpudp_bind(ipaddr = 0.0.0.0, port = 68) udp_bind: bound to 0.0.0.0, port 68 udp_connect: connected to 0.0.0.0,port 68 dhcp_start(): starting DHCP configuration dhcp_discover() pbuf_alloc(length=308) pbuf_alloc(length=308) == 200018b4 transaction id xid(abcd0001) dhcp_discover: making request dhcp_discover: realloc()ing dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, DHCP_SERVER_PORT) pbuf_header: old 200018fc new 200018f4 (8) udp_send: added header in given pbuf 200018b4 udp_send: sending datagram of length 316 udp_send: UDP packet length 316 udp_send: UDP checksum 0xdee0 udp_send: ip_output_if (,,,,IP_PROTO_UDP,) pbuf_header: old 200018f4 new 200018e0 (20) ip_output_if: en0 IP header: +-------------------------------+ | 4 | 5 |  0x00 |       336     | (v, hl, tos, len) +-------------------------------+ |        0      |000|       0   | (id, flags, offset) +-------------------------------+ |  255  |   17  |    0xba9d     | (ttl, proto, chksum) +-------------------------------+ |    0  |    0  |    0  |    0  | (src) +-------------------------------+ |  255  |  255  |  255  |  255  | (dest) +-------------------------------+ netif->output()pbuf_header: old 200018e0 new 200018d2 (14) etharp_send_ip: sending packet 200018b4 dhcp_discover: deleting()ing pbuf_free(200018b4) pbuf_free: deallocating 200018b4 dhcp_discover: SELECTING dhcp_discover(): set request timeout 2000 msecs tcp_bind: bind to port 7 dhcp_discover() pbuf_alloc(length=308) pbuf_alloc(length=308) == 200018b4 transaction id xid(abcd0002) dhcp_discover: making request dhcp_discover: realloc()ing dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, DHCP_SERVER_PORT) pbuf_header: old 200018fc new 200018f4 (8) udp_send: added header in given pbuf 200018b4 udp_send: sending datagram of length 316 udp_send: UDP packet length 316 udp_send: UDP checksum 0xdde0 udp_send: ip_output_if (,,,,IP_PROTO_UDP,) pbuf_header: old 200018f4 new 200018e0 (20) ip_output_if: en0 IP header: +-------------------------------+ | 4 | 5 |  0x00 |       336     | (v, hl, tos, len) +-------------------------------+ |        1      |000|       0   | (id, flags, offset) +-------------------------------+ |  255  |   17  |    0xba9c     | (ttl, proto, chksum) +-------------------------------+ |    0  |    0  |    0  |    0  | (src) +-------------------------------+ |  255  |  255  |  255  |  255  | (dest) +-------------------------------+ netif->output()pbuf_header: old 200018e0 new 200018d2 (14) etharp_send_ip: sending packet 200018b4 dhcp_discover: deleting()ing pbuf_free(200018b4) pbuf_free: deallocating 200018b4 dhcp_discover: SELECTING dhcp_discover(): set request timeout 2000 msecs etharp_request: sending ARP request. pbuf_alloc(length=42) pbuf_alloc(length=42) == 200018b4 etharp_raw: sending raw ARP packet. pbuf_free(200018b4) pbuf_free: deallocating 200018b4 pbuf_alloc(length=594) pbuf_alloc(length=594) == 20004cc0 ethernet_input: dest:00:60:37:12:34:56, src:00:26:f3:a2:6b:b2, type:800 pbuf_header: old 20000050 new 2000005e (-14) ip_input: iphdr->dest 0x1d0a010a netif->ip_addr 0x0 (0x0, 0x0, 0x1d0a010a) ip_input: UDP packet to DHCP client port 68 ip_input: DHCP packet accepted. ip_input: IP header: +-------------------------------+ | 4 | 5 |  0x00 |       576     | (v, hl, tos, len) +-------------------------------+ |        0      |000|       0   | (id, flags, offset) +-------------------------------+ |   64  |   17  |    0x508e     | (ttl, proto, chksum) +-------------------------------+ |   10  |    1  |   10  |    1  | (src) +-------------------------------+ |   10  |    1  |   10  |   29  | (dest) +-------------------------------+ ip_input: p->len 576 p->tot_len 576 pbuf_header: old 2000005e new 20000072 (-20) udp_input: received datagram of length 556 UDP header: +-------------------------------+ |        67     |        68     | (src port, dest port) +-------------------------------+ |       556     |     0x8880    | (len, chksum) +-------------------------------+ udp (10.1.10.29, 68) <-- (10.1.10.1, 67) udp_input: calculating checksum pbuf_header: old 20000072 new 2000007a (-8) dhcp_recv(pbuf = 20004cc0) from DHCP server 10.1.10.1 port 67 pbuf->len = 548 pbuf->tot_len = 548 searching DHCP_OPTION_MESSAGE_TYPE DHCP_OFFER received in DHCP_SELECTING state dhcp_handle_offer(netif=1000eddc) en0 dhcp_handle_offer(): server 0x010a010a dhcp_handle_offer(): offer for 0x1d0a010a dhcp_select(netif=1000eddc) en0 pbuf_alloc(length=308) pbuf_alloc(length=308) == 200018b4 transaction id xid(abcd0003) pbuf_header: old 200018fc new 200018f4 (8) udp_send: added header in given pbuf 200018b4 udp_send: sending datagram of length 316 udp_send: UDP packet length 316 udp_send: UDP checksum 0x9958 udp_send: ip_output_if (,,,,IP_PROTO_UDP,) pbuf_header: old 200018f4 new 200018e0 (20) ip_output_if: en0 IP header: +-------------------------------+ | 4 | 5 |  0x00 |       336     | (v, hl, tos, len) +-------------------------------+ |        2      |000|       0   | (id, flags, offset) +-------------------------------+ |  255  |   17  |    0xba9b     | (ttl, proto, chksum) +-------------------------------+ |    0  |    0  |    0  |    0  | (src) +-------------------------------+ |  255  |  255  |  255  |  255  | (dest) +-------------------------------+ netif->output()pbuf_header: old 200018e0 new 200018d2 (14) etharp_send_ip: sending packet 200018b4 pbuf_free(200018b4) pbuf_free: deallocating 200018b4 dhcp_select: REQUESTING dhcp_select(): set request timeout 2000 msecs pbuf_free(20004cc0) pbuf_free: 20004cc0 has ref 1, ending here. pbuf_free(20004cc0) pbuf_free: deallocating 20004cc0

DALI Software Development Kit The DALI development kits for LPC are no longer available. The LPC MCUs used are still available. This page is provided for reference purposes only. The DALI Software Development Kit (SDK) for the LPC11xx/LPC13xx contains an updated DALI Library for compliancy with the IEC 62386-102 and IEC 62386-201 standard. Parts of the IEC 62386-207 specification are also included. The DALI slave (AN11174 with OM13026 board) and the USB to DALI master (AN11175 with OM13046 board) can be used in combination with the Windows 7 PC GUI to create a demonstration and evaluation setup as described in UM10553. The SDK contains the example software, DALI library, a hardware description and design files of both boards, documentation and is available for download at the end of this document. DALI Slave OM13026                                                       DALI Master OM13046 System notes Controller side: The LPC1100XL (up to 50 MHz - 45 DMIPS) offers enough performance to integrate DALI message coding/decoding and PWM generation in a single chip Industry-leading low active power consumption of 110 uA/MHz for bus-powered devices Storage of scene settings in non-volatile memory using EEPROM emulation in flash, or integrated EEPROM in LPC11E00 series Up to four 16-bit and 32-bit timers, generating up to 11 PWM signals to control and dim the ballast Reduced development complexity - software can be written in C Reduced bill of materials - significant cost savings through Cortex-M0 architecture, plus many built-in peripherals to interface with lighting drivers and network in LPC1100XL Power stage: LED dimming using the PWM input of the NXP UBA3070 DC-to-DC LED driver with up to 98% efficiency SSL4101 provides mains isolation for both the RGB LED power stage and the DALI wires Low component count and high efficiency through integrated PFC and flyback control functionality GreenChip TEA1721 buck converter supplies LPC1100XL with high efficiency; no-load power consumption levels <10 mW DALI Slave Implementation example (OM13026 board): Contains isolated physical layer for the DALI bus with a Cortex M0 LPC111x microcontroller for the DALI protocol handling, and many I/O functions to steer external lighting drivers for solid state or compact fluorescent lighting applications Schematics, gerbers and BOM also available to speed up development Up to four PWM signals available to independently drive different lighting units Frequency and resolution of the signals is software programmable ON_OFF signal can be used independently from the PWM signals to switch a lighting driver into an OFF or ON state I2C-bus pins can be used to externally connect other devices like EEPROM or a temperature sensor Analog A/D input is available via pin 8 IO signal is left open for the end user UART, I2C and A/D converter functionality not included in the software release

View Webinar Recording

This content was originally contributed to lpcware.com by Brewster LaMacchia   This project shows how to take the filter coefficients created by MDS' QEDesign filter design package and use them for real time audio filtering using the floating point DSP capability of the LPC4350. It's designed to run on the Hitex board and uses the UDA1380 for analog stereo I/O. It also uses the touch buttons, COG LCD, and LEDs for controlling operation.   Keil's Logic Analyzer tool was used for performance measurement. For full details see \doc\gen\html\index.html after unzipping the download.   Updated 16-Mar-12 to correct output rolloff in the UDA1380 due to the deemphasis filter being on by mistake.   Original Attachment has been moved to: MyProj.zip