New update to errata will be published regarding the vendor_usage field in the PFR. In ROM, the 16-bit monotonic counter is implemented in the upper 16 bits of the 32-bit VENDOR_USAGE field and the inverse of the monotonic counter is in the lower 16 bits. Users must take care when using the ROM API to increment the upper end of this field and write the inverse on the lower 16 bits in order for ROM to validate the value correctly. The initial value that shall be written is 0x0000FFFF. Then the updates will be as follows: 0x0001FFFE 0x0002FFFD . . 0x0005FFFA . . 0x1010EFEF . . 0xFFFF0000   Example Code using ROM API: *This example demonstrates the increment of the version in CFPA page as well as the vendor usage, it does not cover all use cases, so please use this as a reference only* case APP_INCREASE_VENDOR_USAGE_ONLY: PRINTF("Disable Flash Protect...\r\n"); /* Initialize flash driver */ FLASH_Init(&flashInstance); if (FFR_Init(&flashInstance) == kStatus_Success) { PRINTF("Flash init successfull!!. Halting...\r\n"); } else { error_trap(); } status = FFR_GetCustomerInfieldData(&flashInstance, (uint8_t *)g_CFPAData, 0x0, FLASH_FFR_MAX_PAGE_SIZE); PRINTF("\r\n"); PRINTF("Header 0x%08x , Version 0x%08x , SecureFW Version 0x%08x , NonSecureFW Version 0x%08x\r\n", g_CFPAData[0], g_CFPAData[1], g_CFPAData[2], g_CFPAData[3]); PRINTF("ImageKey Revoke 0x%08x , Reserved 0x%08x , RothRevoke 0x%08x , Vendor Usage 0x%08x\r\n", g_CFPAData[4], g_CFPAData[5], g_CFPAData[6], g_CFPAData[7]); PRINTF("NS PIN 0x%08x , NS DFLT 0x%08x , Enable FA Mode 0x%08x , Reserved1 0x%08x\r\n", g_CFPAData[8], g_CFPAData[9], g_CFPAData[10], g_CFPAData[11]); PRINTF("\r\n"); /* Clean-up CFPA area */ g_CFPAData[8] = 0; g_CFPAData[9] = 0; /*Increase Monotonic counter*/ p32 = (uint32_t *)(uint32_t)g_CFPAData; version = p32[1]; if (version == 0xFFFFFFFFu) { return kStatus_Fail; } version++; p32[1] = version; PRINTF("Version to write: 0x%08x \r\n", version); /*Increase Vendor Usage*/ uint32_t vendor_usage = p32[7]; if(vendor_usage == 0x0) { vendorUsage_right = 0xFFFF; vendorUsage_left = 0x0000; } else { vendorUsage_right = vendor_usage & 0xFFFF; vendorUsage_left = vendor_usage >> 16; } vendorUsage_left += 0x1; vendorUsage_right -= 0x1; vendor_usage = (vendorUsage_left << 16) | vendorUsage_right; p32[7] = vendor_usage; PRINTF("Vendor_Usage to write: 0x%08x \r\n", vendor_usage); Status = FFR_InfieldPageWrite(&flashInstance, (uint8_t *)g_CFPAData, FLASH_FFR_MAX_PAGE_SIZE); if (kStatus_FLASH_Success == Status) { status = kStatus_Success; PRINTF("CFPA Write Done!\r\n"); } else { status = kStatus_Fail; }

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.

The documentation is only valid for the LPC55xx and LPC55Sxx families. In power down mode, some of peripherals for LPC55xx are power off, which means that the peripherals lose it’s power in power-down mode, so it is required to reinitialize the peripherals after waking-up from  power down mode. The DOC lists the peripherals which lose power in power down mode and are required to initialize, introduces the procedure to enter the power down mode, and  the procedure to reinitialize the peripherals after waking-up from power down mode. The doc is attached and power scheme is also attached.

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  

  [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!

        The all LPC MCU contain In-System Programming which is able to programming or reprogramming the on-chip memory by using the bootloader software (Flash Magic) with the UART, CAN, USB, SPI, or other peripherals etc. The UART is available in all LPC MCU, whereas other peripheral interfaces may be only supported in particular sort of MCU. The article introduces the CAN ISP implementation for the NXP’s LPC microcontroller family.     Overview        Taking the LPC11Cxx as an example, The C_CAN bootloader is activated by the ROM reset handler automatically if meets CAN ISP option. The C_CAN bootloader initializes the on-chip oscillator and the CAN controller for a CAN bit rate of 100 kbit/s and sets its own CANopen Node ID to a fixed value. The bootloader then waits for CANopen SDO commands and responds to them. These commands allow to read and write anything in a so-called Object Dictionary (OD). The OD contains entries that are addressed via a 16-bit index and 8-bit subindex. The command interface is part of this OD. In a word, these C_CAN ISP command handler allows to perform all functions that are otherwise available via the UART ISP commands, and the Table 1 summarizes the commanders. Table 1  CAN ISP SDO communication         The CAN ISP node listens for CAN 2.0A (11-bit) messages with the identifier of 0x600 plus the Node ID 0x7D equaling to 0x67D. The node sends SDO responses with the identifier 0x580 plus Node ID equaling to 0x5FD. The SDO communication protocols“expedited”and “segmented” are supported. This means that communication is always confirmed: Each request CAN message will be followed by a response message from the ISP node. However, the SDO block transfer mode is not supported. Fig1 CAN ISP object directory    CAN ISP Implementation           Hrdware preparation          LPCXpresso board LPC11C24 : OM13093 Fig 2 OM13093          PCAN-USB     Fig 3 PCAN-USB          Hardware assembling         Software preparation          Starting the Flash Magic, then follow the below figures to programing and executing the application demo. Fig 5           Result        Hex file: periph_blinky.hex (Froming the LPCopen library) Fig 6 Led is blinking

This is a quick introduction that shows how to interface a popular GPS module to the LPC845 Breakout Board using the UART drivers from the MCUXpresso SDK. This example reads and parses GPS data from the module when the user button is pressed and outputs the information to a host computer console via the board's VCOM interface.    UART Protocol The UART function uses two TPU channels to provide a 2-wire (TxD and RxD) asynchronous serial interface. One TPU channel is configured to function as the serial transmitter (TxD), and another TPU channel is configured to function as a serial receiver (RxD).    Adafruit Flora Wearable GPS The module used for this example is built around the MTK3339 chipset, a no-nonsense, high-quality GPS module that can track up to 22 satellites on 66 channels, has an excellent high-sensitivity receiver. It can do up to 10 location updates a second for high speed, high sensitivity logging or tracking. Power usage is very low, only 20 mA during navigation. Adafruit took this module and mounted it on one of their super-compact Flora boards, which are very easy to connect up to the LPC845 Breakout:     Figure 1. Flora Wearable GPS.   GPS Module Example NXP provides example packages that include projects to use the principal's peripherals that the board include: ADC, I2C, PWM, USART, Captouch, and SPI.   What we need: LPC845 Breakout Board MCUXpresso IDE V10.3.0 SDK_2.5.0_LPC845 NXP example packages Adafruit Flora Wearable GPS Micro USB cable   Once downloaded, we import the library project into the workspace using the ''Import project(s) from file system... from the Quickstart panel in MCUXpresso IDE:     Figure 2. Import projects   Then browse the examples packages archive file:     Figure 3. Select Example package.   Press next, and see that are a selection of projects to import, in this case, only keep select the LPC845_BoB_GPS how it looks in the picture below:     Figure 4. Select GPS project   Connections Now, with the project already in the workspace is time to set up the connection between the LPC845 Breakout board and the GPS module, as shown in the table below:     Table 1. LPC845 to GPS module.   The Flora module has the signals clearly printed on their silkscreen which really helps .     Figure 5. LPC845 Breakout Board to GPS module connections.   Once the connections are made, its time to build and run the example code, use the build and debug button inside the IDE. Now open a terminal program and connect to the COM port the board enumerated as. Configure the terminal with these settings:  115200 baud rate.   No parity.  8 data bits  1 stop bit   Place the GPS module outside. Once the GPS has located the satellite data, the red LED on the GPS will stop blinking. If you see the LED blinking once a second, it does not yet have a fix! It can take many minutes to get a fix if the module sees any satellites immediately. Once it has a fix, press the user button (K1) to display the GPS data in the serial monitor, which includes the current date and time in UTC. It will also give you your latitude, longitude and approximate altitude with the Serial monitor. Figure 6. GPS Print Out.

Because the LPC55S69 has PowerQuad, in SDK example code, the FFT/FIR/IIR and the other DSP function are implemented by the Powerquad module instead of the Cortex-CM33 core.  This is the Powerquad example to implement the DSP function:'   But if customers want to use CMSIS-DSP to implement the DSP function based on Cortex-CM33 instead of Powerquad module, customers can not import SDK example, he has to create a new project, this is the procedures: 1)Create a new project by clicking New->Create a new C/C++ Project   2)select the processor like LPC55S69 3)In the following menu,click CMSIS Driver, and check the CMSIS_DSP_Library and CMSIS_DSP_Library_Source You have to click the Driver which can select your peripherals driver you will use.    3)as the following screenshot, after completion, you can see the CMSIS-DSP source code and library have included in the project    

[解决方案] 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.          

This content was originally contributed to lpcware.com by Jerry Durand When I found the M4 core in the LPC43xx series could be used as a hardware Floating Point Unit (FPU) while the actual code ran in the M0 core, I immediately thought of an application; a stand-alone 4-axis CNC control box for use with table-top milling machines.  Currently these machines are almost exclusively controlled by software running on very old PC hardware that has a parallel port and either MS-DOS or Windows XP for an operating system. Control of these milling machines entails tasks such as receiving g-code commands in ASCII text and a large amount of high-precision floating point operations which calls for an FPU.  This all has to occur rapidly and continously as each of the 4 motors has to be updated thousands of times per second. It seemed the M0 core would excel at the basic input/output (I/O) and timing functions while using the M4 as an FPU would speed the floating point operations. I originally hoped to port the entire RS274NGC open source Enhanced Machine Controller (EMC) software to the LPC4350 and run it with and without the FPU enabled, comparing the time to process a sample g-code file.  Problems getting the development software and examples set up caused me to run short of time even though NXP was fairly fast to fix problems as they were found.  Instead I modified one of the example programs (GPIO_LedBlinky) to enable testing the performance and this turned out to have some interesting results I might have otherwise missed. I ran the test code in eight different configurations:      1. FPU disabled, 32-bit float multiplication      2. FPU enabled, 32-bit float multiplication      3. FPUdisabled, 64-bit double multiplication      4. FPU enabled, 64-bit double multiplication      5. FPU disabled, 32-bit float division      6. FPU enabled, 32-bit float division      7. FPUdisabled, 64-bit double division      8. FPU enabled, 64-bit double division All tests were run from internal SRAM so external memory access time would not distort the results.  The optimization level was left at the default of zero (0) as I had problems with the compiler eliding parts of my code if I tried higher levels. Test results (loops per second averaged over 10 seconds):      1. 990,550        float, *      2. 2,768,000        FPU, float, *      3. 284,455        double, *      4. 276,796        FPU, double, *      5. 282,316        float, /      6. 1,894,000        FPU, float, /      7. 85,762        double, /      8. 85,053        FPU, double, / As expected 32-bit floating point operations run a lot faster with the FPU, 2.79 times faster for multiply and 6.7 times faster for division.  I would have expected somewhat better performance but this is still a significant improvement in speed. The 64-bit floating point operations were a different story, for both multiplication and division the operations ran SLOWER with the FPU than they do without it.  This points to an error in the library functions since it should be no worse than equal.  I was very surprised by this result and hope when the problem is fixed the 64-bit operations improve significantly. In conclusion the low cost of these parts and the simplicity of using the FPU allows performance improvement to an existing product that uses 32-bit floating point operations.  There is no long development cycle or fear of breaking something in your code as the changes to use the FPU consist of adding a small initilization routine for the FPU and enabling it in your compiler options.  This also leaves open the option of an even greater improvement with no hardware changes once you've had time to port your critical code to run directly on the M4 core instead of just using it as an FPU. In the case of 64-bit floating point operations, it seems this may not be the best choice if you only use the M4 as an FPU.  Running your critical code directly on the M4 may give a significant improvement but that requires porting the code to run on both cores and isn't something I tested.

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.  

1 Abstract       This post is mainly about the LPC54608 LIN slave basic usage, it is similar to the post about the LPC54608 LIN master basic usage.            NXP LPC54608 UART module already have the LIN master and slave function, so this post will give a simple slave code and test result which is associated with the LIN analyzer. Use the LIN analyzer as the LIN master, LPC54608 as the LIN slave, master will send the specific ID frame (publish frame and the subscribe frame) to LIN slave, and wait the feedback from LIN slave side. 2 LPC54608 LIN slave example      Now use the LPCXpresso54608 board as the LIN slave, the PCAN-USB Pro FD LIN analyzer as the LIN master, give the hardware connection and the simple software code about the LIN slave. 2.1 Hardware requirement        Hardware：LPCXpresso54608，TRK-KEA8，PCAN-USB Pro FD(LIN analyzer), 12V DC power supply        LIN bus voltage is 12V, but the LPCXpresso54608 board don’t have the on-board LIN transceiver chip, so we need to find the external board which contains LIN transceiver chip, here we will use the TRK-KEA8, this board already have the MC33662LEF LIN transceiver, or the board KIT33662LEFEVB which is mentioned in the LPC54608 LIN master post.  The MC33662LEF LIN transceiver circuit from TRK-KEA8 just as follows: Fig 2-1. LIN transceiver schematic 2.1.1 LPCXpresso54608 and TRK-KEA8 connections      LPCXpresso54608 UART port need to connect to the LIN transceiver: No. LPCXpresso54608 TRK-KEA8 note 1 P4_RX J10-5 UART0_RX 2 P4_TX J10-6 UART0_TX 3 P4_GND J14-1 GND 2.1.2 TRK-KEA8 and LIN master analyzer tool connections        LIN analyzer LIN bus is connected to the TRK-KEA8 LIN bus.        LIN analyzer GND is connected to the TRK-KEA8 GND.             TRK-KEA8 P1 port powered with 12V, LIN master analyzer Vbat pin also need to be connected to 12V.        TRK-KEA8 J13_2 need to connect to 3.3V DC power, but because TRK-KEA8 is the 5V and 12V, so need to find another 3.3V supply to connect J13_2, here use the FRDM-KL43 as the 3.3V supply. Just make sure the LIN transceiver can input 3.3V and output the 3.3V signal to the UART port.    2.1.3 Physical connections 2.2 Software flow and code        This part is about the LIN publisher data and the subscriber ID data between the LIN master and slave. The code is modified based on the SDK  LPCXpresso54608 usart interrupt project.  2.2.1 software flow chart 2.2.2 software code    Code is modified based on SDK_2.3.0_LPCXpresso54608 usart interrupt, the modified code is as follows: void DEMO_USART_IRQHandler(void) {      if(DEMO_USART->STAT & USART_INTENSET_DELTARXBRKEN_MASK) // detect LIN break      {        DEMO_USART->STAT |= USART_INTENSET_DELTARXBRKEN_MASK;// clear the bit        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(0XEC == rxbuff[cnt])                           {                               state = SEND_DATA;                           }                           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 } /*! * @brief Main function */ int main(void) {     usart_config_t config;     /* attach 12 MHz clock to FLEXCOMM0 (debug console) */     CLOCK_AttachClk(BOARD_DEBUG_UART_CLK_ATTACH);     BOARD_InitPins();     BOARD_BootClockFROHF48M();     BOARD_InitDebugConsole();     /*      * config.baudRate_Bps = 19200U;      * config.parityMode = kUSART_ParityDisabled;      * config.stopBitCount = kUSART_OneStopBit;      * config.loopback = false;      * config.enableTxFifo = false;      * config.enableRxFifo = false;      */     USART_GetDefaultConfig(&config);     config.baudRate_Bps = BOARD_DEBUG_UART_BAUDRATE;     config.enableTx = true;     config.enableRx = true;     USART_Init(DEMO_USART, &config, DEMO_USART_CLK_FREQ);     /* Enable RX interrupt. */     DEMO_USART->INTENSET |= USART_INTENSET_DELTARXBRKEN_MASK; //USART_INTENSET_STARTEN_MASK |     USART_EnableInterrupts(DEMO_USART, kUSART_RxLevelInterruptEnable | kUSART_RxErrorInterruptEnable);     EnableIRQ(DEMO_USART_IRQn);     while (1)     {          if(state == SEND_DATA)        {         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;        }         } } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 3 LPC54608 LIN slave test result   Master define two frames： Unconditional ID Protected ID Direction Data checksum 0X2C 0XEC subscriber 0x01,0x02 0x10 0X2D 0XAD Publisher 0x01,0x02,0x03 0x4c   Now, LIN master send the above two frame to the slave LIN, give the test result and the wave from the LIN bus. 3.1 LIN master configuration Uart baud rate is: 19200bps 3.2 send 0X2C,0X2D frames From the above test result, we can find 0X2D send successfully, 0X2C can receive the data from the LIN save side, the received data is 0X01,0X02 and the checksum 0x10. 3.2.1 0X2D frame LIN bus wave and debug result   From the LIN slave debug result, we can find LIN slave can receive the correct data from the LIN master, and after check, the checksum also correct. 3.2.2 0X2C frame LIN bus wave From the LIN Master tool interface, we can find if the slave give the wrong checksum 0XAA, the master will also can find the checksum is wrong. This is the according LIN bus wave with wrong checksum. From the above test result, we can find LPC54608 LIN slave, can receive the correct LIN bus data, and send back the correct LIN data to the master.

MCUXpresso SDK for LPC55xx uses FLASH API to implement FLASH drivers. Some user may meet issue when executes FLASH program code, for instance: status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8); After execution this code, nothing changed in the destination address, but error code 101 returns: This error code looks new, as it doesn’t commonly exist in other older LPCs. If we check FLASH driver status code from UM, code 101 means FLASH_Alignment Error: Alignment error Ah ha? ! Go back to the definition of FLASH_Program, status_t FLASH_Program(flash_config_t *config, uint32_t start, uint32_t *src, uint32_t lengthInBytes); New user often overlooks the UM description of this API “the required start and the lengthInBytes must be page size aligned”. That’s to say, to execute FLASH_Program function, both start address and the length must be 512 bytes-aligned. So if we modify status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 8); To status = FLASH_Program(&flashInstance, destAdrss, (uint8_t *)s_bufferFF, 512); FLASH_Program can be successful.   ！！NOTE: In old version of SDK2.6.x, the description of FLASH_Program says the start address and length are word-aligned which is not correct. The new SDK2.7.0 has fixed the typo.  Keep in mind: Even you want to program 1 word, the lengInBytes is still 512 aligned, as same as destAdrss! PS. I always recommend my customer to check FLASH driver status code when meet problem with FLASH API. We can find it in UM11126, Chapter 9, FLASH API. I extract here for your quickly browse:   Happy Programming

[中文翻译版] 见附件   原文链接： https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2019/05/05/trustzone-with-armv8-m-and-the-nxp-lpc55s69-evk

The document describes how to use DMA triggering mode to transfer data between memory and peripheral. In detail, the CTimer0_match0 is configured to generate matching event with programmable period, the CTimer0 matching event triggers DMA, the DMA transfer data between a variable in memory and GPIO Toggling register(the GPIO is connected to a LED), so user can see the LED toggling. The DMA Ping-Pong modes are used, so user can observe different LED toggles. The Example code is developed on SDK package, run on LPC55S69-EVK, the tools is MCUXpresso ver11.5.  

Welcome to the LPC4350 Hitex Board Getting Started Guide! This page will walk new owners of the LPC4350 development platform from Hitex through bringing the board up with the example projects. Connecting the Hardware Here is a photo of a typical hardware setup. The board is connected to a PC through a JTAG debugging interface and a USB-serial cable. +5V center-positive power is also applied to X14. If a 5V regulated power supply is not available, the board may be powered by USB connected to one of the USB connectors using the included cable. To date we have tested this board with a Keil ULink 2, ULink Pro, and the Segger JLink but any JTAG-capable tool should be able to debug with the LPC4350. The example projects should run without modification on Keil MDK. To see the debugging output from the example code on the serial-to-usb cable, first the driver must be installed. Many cables use chips from FDTI and the drivers can be downloaded from here: FDTI VCP Drivers. To view the serial output, any standard terminal program such as Tera Term can be used. LPC4300 Hitex Board with Connections LPC4350 PDL Examples and Flash Drivers The example code for this board can be downloaded from here: LPC4350 PDL There are 53 code examples. Once the code has been downloaded, it should be unzipped. The unzipped peripheral driver library includes an Examples directory containing examples that work with each peripheral on the LPC4350 dual-core microcontroller. Also included are flash drivers located in the Tools\Flash\Keil_Binaries directory. If using ARM/Keil MDK V4.22 and earlier, these should be copied to the C:\Keil\ARM\Flash directory. Later tool versions should include these drivers. LPC4350 PDL Examples and Flash Drivers If you are using the Hitex LPC4350 board using the ARM/Keil MDK, the driver library projects have several configurations built-in. They can build for Internal SRAM, build for SPIFI (external 1 MB QSPI flash on the Hitex board), or build for Hitex Flash (external parallel flash on the Hitex board).The best performance will be achieved with building for Internal SRAM, but if you would like the board to boot on its own without a debugger, then the code will have to be built either for SPIFI or for Hitex Flash. LPC4350 PDL Keil Project Configurations LPC4350 PDL Boot Jumpers Once you have successfully programmed the flash on the Hitex board, there is one step left before the LPC4350 can boot from external flash. That final step is to configure the boot mode using the boot mode jumpers. LPC4350 PDL Boot Jumpers Here is a diagram that shows how to configure the boot jumpers on the LPC4350 Hitex board. The boards are shipped with the center two positions shorted with jumpers. This configures the LPC4350 to boot from the "EMC" (External Memory Controller) which is connected to the parallel flash on the Hitex board. When using the sample projects with the Keil tool, after building a project, the LOAD button can be used to program it into Flash memory for stand-alone booting. To debug a project that has been programed in to Flash, you may need to click the LOAD button to configure the memory controller on the LPC4350 (if it has been reset) before entering debug mode. LPC4350 PDL Boot Jumper Diagram We can ship boards with two example projects flashed in them- one loads when the board is configured to boot from Parallel Flash, and a second loads when the board is configured to boot from QSPI flash. Recent boards are shipped with a Mass Storage Class ROM USB demo in parallel Flash and an LED/button demo in QSPI Flash. Using the SD/MMC Card Slot The SD/MMC Card Slot, on the right edge of the board in the photo above, can accept an SD card to read and write data. Before this slot will work properly, several jumpers must be configured on the Hitex board. The jumpers needed are: Jumper Block Jumper Settings SV3 positions 7-8 and 13-4 must be open SV6 positions 1-2, 3-4, 7-8, 15-16, 17-18 must be open SV12 all positions must be shorted JP9 position 1-2 must be shorted Next- load the Usb_MassStorage example from the USBDEV_ROM directory. This Mass Storage Class example has been extended with sdio drivers. Insert an SD card (we have tested 2GB) into the SD connector on the right side of the board. Connect X2 (USB1, high-speed) to a PC. You should see a disk drive on the PC and be able to read and write the SD card. Operation at 204 MHz The LPC4350 is qualified to operate at up to 204 MHz, but normally starts up at a slower speed to make design easier. In particular, even if memories and power subsystems are not designed to support 204 MHz, booting is still possible. To run the LPC4350 at 204 MHz, take a look at the BOOTFAST example project. This project supports the same configurations (SRAM, Parallel Flash, and QSPI Flash) as the other examples, but after startup, it relocates some code to internal SRAM, and then it reconfigures the parallel flash and SPIFI peripheral to a high speed mode and increases the clock speed to 204 MHz. This is a good way to see how a standard system would boot. Typically, the most critical code would also be located within internal SRAM which runs at 204 MHz with zero wait states while other less performance-intensive code could be located in external Flash, SRAM, or QSPI flash which are set up to run at 102 MHz in this example. Multi-Core Operation The LPC4350 contains two cores, a Cortex-M4 and a Cortex-M0 which both operate at 204 MHz. An example that demonstrates how you can use the cores together is located in Examples\DUALCORE\Mbx_Demo. This example sets up a mailbox mechanism to facilitate communication between the two cores. The M0 core is assigned the task of outputting serial communications via UART 1. This example includes a multi-project workspace. Once the workspace is opened, the M0 project must be built first before the M4 project can be built. For more details, see the abstract in the M4 project. State Configurable Timer (SCT) The LPC4350 contains a special timer called the State Configurable Timer (SCT). The SCT is a timer with a state machine integrated into it. It is great for doing complex signal generation such as PWM waveforms. An SCT example is provided in the LPC4350 code repository which emulates the behavior of a simple traffic light. The example is called SCT_TrafficLight and is in the SCT subdirectory of the Examples directory in the code bundle. To use this example, you must assemble a PCB with four LEDs and two pushbuttons. Here is a photo of an example board: SCT Traffic Light SCT Traffic Light Schematic The traffic light should be connected as follows: Signal Port Connector Signal Wire Color CTOUT_0 P4_2 X11, pin 7 Red LED red CTOUT_1 P4_1 JP20, pin 2 Yellow LED yellow CTOUT_2 P4_4 JP22, pin 2 Green LED green CTOUT_3 P4_3 X11, pin 6 White LED red CTIN_2 P4_10 X11, pin 13 WALK Button blue CTIN_3 P7_3 SV18, pin 16 RESET button yellow GND ADC ADC, GND Common black Traffic Light Connections If you would like to edit the state machine used in the traffic light example, you will need to use the LPCXpresso or Red Suite tool, which has "Red State," a state-machine editor, built-in. Here is an image of the state machine used in the traffic light example: Traffic Light Diagram Once you have edited the state machine, click "Generate Code." You can test the state machine within LPCXpresso if you have a Red Probe or an LPC-Link probe, or you can copy the following source code files from the LPCXpresso project over to the Keil SCT project: sct_fsm.c, sct_fsm.h, and sct_user.h and make use of a JLink or uLink. Serial GPIO (SGPIO) The LPC4350 contains a peripheral called Serial GPIO which is similar to a bank of shift registers with some extra logic for bonding and counters for timing. The SGPIO is great for implementing standard or custom digital data interfaces. To demo this peripheral, we have configured it to implement four I2S ports to add 7.1 8-speaker audio capability to the LPC4300 family. The example for this will soon be provided in the LPC4350 code repository. The example will be called SGPIO_71 and will be in the SGPIO subdirectory of the Examples directory in the code bundle. To use this example, you need a demonstration PCB with four stereo audio codecs on board. Here is a photo of an example board: LPC4350 Codec Board The codec board should be connected as follows: Signal Connector Wire Color MCLK SV16, pin 6 blue LRCLK SV3, pin 11 green SCLK SV5, pin 6 yellow GND GND post near U23 black V33 JP5, pin 2 red - - - SDIN0 SV13, pin 4 blue SDIN1 SV5, pin 4 green SDIN2 SV16, pin 4 yellow SDIN3 SV3, pin 3 blue LPC4300 Hitex Codec Connections Once you have connected the codec board, you should be able to connect the Hitex board to your PC using a USB cable to connector X2. After running the example project, a stereo USB speaker device should appear on your PC which can accept audio and mirror it onto two of the stereo audio channels.

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

This content was originally contributed to lpcware.com by Cam Thompson This project is a simple data logging example that takes readings from various sensors, and log the information to a web page. The Cortex-M4 is used to collect and process sample data, and the Cortex-M0 is used to run a web server for supplying data to web clients. This allows data to be viewed on any web browser, including portable devices such as smart phones and tablets. The web data logging example was implemented using the Hitex LPC4300 evaluation board, which has all the necessary components. The LPC43xx has a built-in ethernet controller accessible by either core, and the Hitex evaluation board provides the physical layer. An on-board 128x32 pixel Chip-on-Glass (COG) LCD display, four touch sensors, and several LEDs are used for implementing a simple user interface. The LPC43xx contains a Real-Time Clock (RTC) which is used to record the date and time of data samples.

LPC China team creats a serial of LPC82x training slides with hands-on examples for GC customers, disti and fans. And all the material are written in Chinese. This is just the SCT chapter of the whole serials. Enjoy it. #sct‌ #lpc824‌ #lpc82x‌