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

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

LPC Microcontrollers Knowledge Base

ディスカッション

ソート順:
How to start with SDK v.2.0 for LPC5411x using LPCXpresso IDE This document gives an overview of SDK v.2.0 for LPC5411x and also describes the steps required to build, run, and debug an example application provided in the SDK using LPCXpresso IDE. The steps described in the document are for the LPCXpresso54114 board (OM13089).   SDK for LPC5411x Derivatives Overview   The Software Development Kit (SDK) provides comprehensive software support for Microcontrollers. The SDK includes a flexible set of peripheral drivers designed to speed up and simplify development of embedded applications. Along with the peripheral drivers, the SDK provides an extensive and rich set of example applications covering everything from basic peripheral use case examples to full demo applications. The SDK also contains RTOS kernels and various other middleware to support rapid development on devices. SDK board support provides example applications for development and evaluation boards. Board support packages are found inside of the top level boards folder, and each supported board has its own folder (a SDK package can support multiple boards). Within each <board_name> folder there are various sub-folders to classify the type of examples they contain. These include (but are not limited to): demo_apps: Full-featured applications intended to highlight key functionality and use cases of the target MCU. These applications typically use multiple MCU peripherals and may leverage stacks and middleware. driver_examples: Simple applications intended to concisely illustrate how to use the SDK’s peripheral drivers for a single use case. These applications typically only use a single peripheral, but there are cases where multiple are used (for example, ADC conversion using DMA). rtos_examples: Basic FreeRTOS examples showcasing the use of various RTOS objects (semaphores, queues, and so on) and interfacing with the SDK’s RTOS drivers multicore_examples: Applications for both cores showing the usage of multicore software components and the interaction between cores.   Build, run and debug a SDK example   This section describes the steps required to configure LPCXpresso IDE to build, run, and debug an example application. The hello_world demo application targeted for the LPCXpresso54114 is used as an example, though these steps can be applied to any example application in the SDK.   1. Download and install the latest LPCXpresso version from the next link: http://www.nxp.com/products/software-and-tools/software-development-tools/software-tools/lpc-microcontroller-utilities/lpcxpresso-ide-v8.2.2:LPCXPRESSO 2. Follow the steps describe here to download the Software Development Kit (SDK) v2.0 for LPCXpresso54114: Generating a downloadable MCUXpresso SDK v.2 package  3. Select "File -> Import" from the LPCXpresso IDE menu. In the window that appears, expand the "General" folder and select "Existing Projects into Workspace". Then, click the "Next" button.       4. Click the "Browse" button next to the "Import from file:" option, and point to the example application project, which can be found using this path: <install_dir>/boards/<board_name>/<example_type>/<application_name>/lpcx/cm4 For this example, the specific location is: <install_dir_SDK_2.0_LPCXpresso54114>\boards\lpcxpresso54114\demo_apps\hello_world\lpcx\cm4 Then Click the "Finish" button. 5. There are two project configurations (build targets) supported for each SDK project: Debug – Compiler optimization is set to low, and debug information is generated for the executable. This target should be selected for development and debug. Release – Compiler optimization is set to high, and debug information is not generated. This target should be selected for final application deployment. So it is necessary to choose the appropriate build target. For this example, select the "Debug" target.   6. Build the project using the hammer icon. 7. Connect the development platform to your PC via USB cable between the Link2 USB connector (named Link for some boards) and the PC USB connector. If connecting for the first time, allow some seconds for the devices to enumerate.   8. In the Windows operating system environment, open the terminal application on the PC and connect to the debug serial port number. For this example it is used Tera Term.   Configure the terminal with these settings: 115200 No parity 8 data bits 1 stop bit    9. In LPCXpresso IDE, click on “Debug Configurations”. In the Debug Configurations dialog box, select the debug configuration that corresponds to the hardware platform you’re using. In this example, select is the CMSIS-DAP option under C/C++ (NXP Semiconductors) MCU Application. 10. After selecting the debugger interface, click the "Debug" button to launch the debugger. 11. Additional dialog windows may appear to select LPC-INK2 CMSIS-DAP emulator and core in case of multicore derivatives. Select it and click the "OK" button. Then select the Cortex-M4. The application is downloaded to the target and automatically run to main():    12. Start the application by clicking the "Resume" button. The hello_world application is now running and a banner is displayed on the terminal. Enjoy!!   Related links: Introducing MCUXpresso SDK v.2 for LPC54xxx Series  Generating a downloadable MCUXpresso SDK v.2 package  MCUXpresso Config Tools is now available!  
記事全体を表示
Demo demonstrate how to use EMC to connect with external SDRAM.
記事全体を表示
        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
記事全体を表示
Introducing MCUXpresso SDK v.2 for LPC54xxx Series What's New in MCUXpresso SDK v.2 for LPC54xxx? The Software Development Kit (SDK) 2.0.0 is a collection of software enablement for microcontrollers that includes peripheral drivers, multicore support, and integrated RTOS support for FreeRTOS OS and μC/OS. In addition to the base enablement, the SDK is augmented with demo applications and driver example projects, and API documentation to help the customers quickly leverage the support of the SDK. Development Tools The MCUXpresso SDK v.2 for LPC54xxx 2.0.0 was compiled and tested with these development tools: - LPCXpresso 8.2.0 - IAR Embedded Workbench for ARM® platform version 7.60.2 - MDK-ARM Microcontroller Development Kit (Keil)® 5.20 Supported Development Systems Development boards MCU devices LPCXpresso54114 LPC54114J256BD64, LPC54114J256UK49, LPC54113J128BD64, LPC54113J256BD64, LPC54113J256UK49 LPCXpresso54608 LPC54605J256ET180, LPC54605J512ET180, LPC54606J256ET180, LPC54606J512BD208, LPC54607J256ET180, LPC54607J512ET180, LPC54607J256BD208, LPC54608J512ET180, LPC54608J512BD208   SDK Board Support Folders SDK board support provides example applications for development and evaluation boards. Board support packages are found inside of the top level boards folder, and each supported board has its own folder (a SDK package can support multiple boards). Within each <board_name> folder there are various sub-folders to classify the type of examples they contain.   demo_apps: Full-featured applications intended to highlight key functionality and use cases of the target MCU. These applications typically use multiple MCU peripherals and may leverage stacks and middleware. driver_examples: Simple applications intended to concisely illustrate how to use the SDK’s peripheral drivers for a single use case. These applications typically only use a single peripheral, but there are cases where multiple are used (for example, ADC conversion using DMA). rtos_examples: Basic FreeRTOS examples showcasing the use of various RTOS objects (semaphores, queues, and so on) and interfacing with the SDK’s RTOS drivers usb_examples: Applications that use the USB host/device/OTG stack. multicore_examples: Applications for both cores showing the usage of multicore software components and the interaction between cores. Example Application Structure This section describes how the various types of example applications interact with the other components in the SDK. To get a comprehensive understanding of all SDK components and folder structure, see the SDK v.2.0 API Reference Manual document (SDK20APIRM). Each <board_name> folder in the boards directory contains a comprehensive set of examples that are relevant to that specific piece of hardware. We’ll discuss the hello_world example (part of the demo_apps folder), but the same general rules apply to any type of example in the <board_name> folder. In the hello_world application folder you see this: All files in the application folder are specific to that example, so it’s very easy to copy-paste an existing example to start developing a custom application based on a project provided in the SDK. Related links: For information on how to import and debug the MCUXpresso SDK example projects using LPCXpresso or generate your MCUXpresso SDK package take a look to this document: How to start with SDK v.2.0 for LPC5411x using LPCXpresso IDE Generating a downloadable MCUXpresso SDK v.2 package https://community.nxp.com/docs/DOC-333369  MCUXpresso Config Tools is now available!  
記事全体を表示
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.
記事全体を表示
Abstract This paper discusses our approach to crypto acceleration and asset protection using novel techniques that help bring high levels of security to low-cost microcontrollers with minimal power and area penalty. CASPER, our asymmetric cryptography acceleration engine, aims to optimize crypto algorithm execution (e.g., RSA, ECC). It is built on a hardware-software partitioning scheme where software functions map asymmetric crypto functions to the hardware modules of the accelerator, delivering sufficient flexibility to software routines to enable mapping of new algorithms. Further efficiency is achieved by making use of the co-processor interface on the Arm® Cortex®-M33 core. Important assets such as keys, proprietary and/or licensed application software are protected against side-channel analysis or cloning using SRAM PUF and PRINCE. SRAM PUF technology enables secure storage of root-of-trust keys and user keys by exploiting the deep sub-micron process technology variations. PRINCE is a low-latency lightweight cryptography algorithm implementation in hardware that allows encrypted non-volatile storage and real-time, latency-free decryption of the execution code. Read More >
記事全体を表示
        In recently, NXP released a new sub-series: LPC80x which contains two kinds: LPC802 and LPC804 now, they have a variety of package types for choose and the LPC804 seems like the advanced version to LPC802. For details, please refer to these two articles: 《小巧‘零’珑的MCU:LPC80X面面观》 《LPC800系列选型指南》        Below are block diagrams of LPC802 and LPC804. We can find the difference easily after comparing them. Fig1 LPC802 system block diagram Fig2 LPC804 system block diagram        According to the above two figures, we can find that LPC804 has the capacitive touch interface, programmable logic unit (PLU), 10-bit DAC output, and an I2C interface. But these peripherals are not supported in the LPC802. In further, LPC804 has two times as much memory as LPC802 does.Especially, the capacitive touch interface provides hardware support for LPC804 to design the complex HMI implemented.        In the coming section, I'd like to illustrate the problem capacitive touch demo and share some experience to overcome it. Capacitive Touch Demo Testing 1. Evaluation board (OM40001) Fig3 LPCXpresso804 Develpment Kit        2. Demo code        CapTouch_5ch demo is from Code Bundle (supports Keil, IAR, and MCUXpresso), after reset, all the 5 LEDs would be On and Off one by one and flash together. Please do not touch the pads during this period. After all the LEDs are silent, touch any pad and the responding LED will be on until your finger moves away. Meanwhile, run the Freemaster project to monitor the sensing value in runtime. Fig4 Capacitive Touch Shield Fig5 FreeMASTER monitor the sensing value          3. Testing summary         In general, the testing result is not very good, for instance, when touching S4 and S3, LED D1~D5 may be lighted arbitrarily, even the S1 and S2 which have the best performance,  the responding LED usually be on when touching them, sometimes other LEDs would response the touching event.         Combining with the observation of FreeMaster, it can get the conclusion that the discrimination of these touchpads is not enough to distinguish each other.          4. Workaroud         According to the feedback from the AE co-worker, the discrimination performance of the touchpad is mainly determined by the PCB design and the power supply source. Obviously, the touchpad is impossible to be modified, so we should consider eliminating the power supply's noise to improve the performance.          I tried these three power source for supply. Using the USB port of the notebook, meanwhile, the notebook is supplied by 220 V, 50 Hz Using the USB port of the notebook Using mobile power       After several rounds of testing, it illustrates that demo code can work well when using mobile power to supply, as the mobile power is clean enough and the noise is the smallest.       Note: Slowing the FCLK can extend the scan period for a channel (more energy is released through YL for each recharge cycle), then increase the discriminability performance.  mobile power supply
記事全体を表示
NXP’s Arm® Cortex®-M33 based LPC551x MCU Family Enhanced Security & Performance Efficiency
記事全体を表示
The MCUXpresso IDE SWO trace function is a special feature which enables user to observe variable update, interrupt entry/exit timing, interrupt event statistic, to print information in SWO ITM Console while the MCU is running. The MCUXpresso IDE SWO trace function is a supplement to the debugger of the MCUXpresso IDE. The main advantage is to display variable, print information, list interrupt entrying/exitting/returing while the MCU is running.  The documentation describes the hardware connection to implement the SWO function, MCUXpresso configuration and source code to implement the function. 
記事全体を表示
This content was originally contributed to lpcware.com by George Romaniuk     This project included testing the performance of the SPIFI interface on LPC4350. Example files were modified to run the M4 core at 200MHz and read and write to SPIFI attached FLASH. Timer was added to measure the execution and data transfer time. Reads were at an amazing 44.9MByte/s; writes were much slower due to FLASH. In addition to SPIFI, some DSP routines were timed and performance was documented.
記事全体を表示
1 Abstract       In the previous time, I have shared one post about the kinetis L series LIN slave basic usage. Now, because the LPC54608 still don’t have any sample code about the LIN, so this post, I will share a simple code about the LPC54608 LIN master usage, and use the LPCXpresso 54608 board associated with the LIN analyzer to test the result.       This document will realize the LIN master and LIN slave communication, LIN master will send the specific publisher frame and the subscriber frame, the LIN slave will detect the master data’s correction, and feedback the according data. 2 LPC54608 LIN master example      Now use the LPCXpresso54608 board as the LIN master, the LIN analyzer tool as the LIN slave, test the LIN send and receive function between the LIN master and LIN slave. 2.1 Hardware requirement      Hardware:LPCXpresso54608,KIT33662LEFEVB,PCAN-USB Pro FD       LIN bus voltage is 12V, but the LPCXpresso54608 board don’t have the on board LIN transceiver, so we need to find the external LIN transceiver, then connect the LPC54608 UART port to the LIN transceiver. About the external LIN transceiver, we use the NXP official LIN driver board KIT33662LEFEVB, this board schematic can be found from this link: https://www.nxp.com/docs/en/user-guide/KT33662UG.pdf          Fig 2-1. LIN transceiver schematic    If you don’t have the KIT33662LEFEVB board, don’t worry, you also can use the TRK-KEA8, just like the kinetis LIN post which I have shared. TRK-KEA8 have the on board transceiver chip. 2.1.1 LPCXpresso5460 and IT33662LEF EVB connections No. LPCXpresso54608 KIT33662LEFEVB note 1 P4_RX J4-2 UART0_RX 2 P4_TX J4-1 UART0_TX 3 P4_GND J5-1 GND 4 JP2_3 J5_2 3.3V power supply   2.1.2 KIT33662LEFEVB 12V power supply and LIN slave connection KIT33662LEFEVB board J2_1: 12V power supply, also connect to LIN analyzer VBAT pin J2_3: 12V ground, also connect to LIN analyzer GND pin J2_2: LIN bus, connect to the LIN analyzer LIN pin   2.1.3 Use TRK-KEA8 on board LIN transceiver       This chapter just for those don’t have KIT33662LEFEVB board, but have the TRK-KEA8 board. 1)LPCXpresso54608 and TRK-KEA8 connections      LPCXpresso54608 need to connect the UART pin to the LIN transceiver, the connections like this: 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) TRK-KEA8  and LIN analyzer connections         LIN bus is the single wire, connect to LIN analyzer LIN pin, GND also need to connect together.        TRK-KEA8 need to use the P1 powered by 12V DC power supply, LIN analyzer also need to connect to the 12V DC.        Because the LPC54608 board is powered by the 3.3V, then also need to power the LPC54608 board with a 3.3V DC power supply. 2.1.4 Physical connections                Fig 2-2. Physcial connections 2.2 Software code       Now, talk about the LIN master send the LIN publisher data and the subscriber ID data, the software code is modified from the SDK_2.3.0_LPCXpresso54608 usart interrupt project, the detail code just 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 = 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 } /********************************************************************************************/ /*Publisher LIN frame /*13bit break+0x55 sync+0xad(0x2D's protected ID)+0x01+0x02+0x03+0x4C(check sum) //All the above byte is sent by the LIN master /********************************************************************************************/ void Lin_Master_Publisher(void) {     unsigned int i=0; //===============================LIN master send=====================        DEMO_USART->CTL |= USART_CTL_TXBRKEN_MASK;//enable TX break;        while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART))         {             USART_WriteByte(DEMO_USART, 0Xff);//dummy byte, no means             break;  //just send one byte, otherwise, will send 16 bytes         }         for(i=0;i<10000;i++); // delay for the break generation.        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, 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;        DEMO_USART->CTL |= USART_CTL_TXBRKEN_MASK;//enable TX break;        while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART))         {             USART_WriteByte(DEMO_USART, 0Xff);//dummy byte, no means             break;  //just send one byte, otherwise, will send 16 bytes         }         for(i=0;i<10000;i++); // delay for the break generation.       // for(i=0;i<5000;i++);        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, 0XEC);//0XEC             break;  //just send one byte, otherwise, will send 16 bytes         } } /*! * @brief Main function */ int main(void) {     unsigned int i=0;     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 |        //enable USART interrupt     cnt=0;            USART_EnableInterrupts(DEMO_USART, kUSART_RxLevelInterruptEnable | kUSART_RxErrorInterruptEnable);     EnableIRQ(DEMO_USART_IRQn);//All ID datas will be received in the interrupt         Lin_Master_Publisher(); //LIN master send publisher ID 0x2D     for(i=0;i<65535;i++);//delay     Lin_Master_Subscribe();//LIN master send subscriber ID 0x2c     while (1)     {     } } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍     In USART_Init function,add the LIN function enable code:     /* setup configuration and enable USART */     base->CFG = USART_CFG_PARITYSEL(config->parityMode) | USART_CFG_STOPLEN(config->stopBitCount) |                 USART_CFG_DATALEN(config->bitCountPerChar) | USART_CFG_LOOP(config->loopback) | USART_CFG_ENABLE_MASK | USART_CFG_LINMODE_MASK;// 3 LPC54608 LIN master test result   Master side define two ID frame: Unconditional ID Protected ID Direction Data checksum 0X2C 0XEC subscriber 0x01,0x02 0x10 0X2D 0XAD Publisher 0x01,0x02,0x03 0x4c   Now, LIN master will send the above two ID frame to the slave, then give the test result about the feedback from the slave and the LIN bus wave. 3.1 LIN slave configuration The LIN baud rate is defined as 9600bps. The following picture is from the LIN analyzer (PEAK LIN tool) software: To get the data from the LIN slave, the master need to send the 0x2C frame at first, then the slave will send back the according data. The master subscriber frame is the slave’s publisher frame; the master publisher frame is the slave’s subscriber. Master send, slave receive. Master receive, then the slave is the send side.       In the slave software side, need to configure the 0X2C ID according data, then press the space key, the slave will wait for the master’s according frame. 3.2 Send 0X2C and 0X2D frame From the slave side, we can find 0X2D is received successfully from the master, 0X2C can send the correct data to the master. 3.2.1 0X2D frame data LIN bus wave and debug result Yellow wave is the LPC54608 UART TX pin wave. Blue wave is the LIN bus wave. From the LIN bus wave, we can find that the LIN master can send out the correct LIN data, and the checksum also correct from the slave received side. 3.2.2 0X2C data LIN bus wave and debug result Yellow wave is the LPC54608 UART TX pin wave. Blue wave is the LIN bus wave. From the wave, we can find that after the LIN master send the 0X2C data, the slave will send back the according data to the master, now check the LPC54608 debug data from IAR: From the received data and the checksum data,  we can find the slave feedback is correct. So, the above modified code can realize the LPC54608 LIN master frame basic send and receive function.  Next time, I will also share a post about the LPC54608 LIN slave code. Wish it helps you!  
記事全体を表示
To help you get started with the LPC800 Mini-Kit, we've put together a few basic resources for you here. LPC800 Mini-Kit Code Base The LPC800 comes populated with an LPC810 MCU in a DIP8 package. The LPC810 package a lot of peripheral punch into a small, extremely affordable package, but as with any deeply embedded device, it's always a challenge to fit the most code and functionality possible into the smallest device available. The LPC810 with 4KB flash and 1KB SRAM is no exception. To help you get started writing light-weight, but easy to understand code in C, we've put together a basic code base for the LPC810 Mini-Kit based around NXP's free LPCXpresso IDE, which uses the free GNU toolchain beneath the surface. The latest version of the code can be viewed and downloaded online on github (LPC810 Code Base), or you can download the latest version directly. Board Schematic The schematics for the LPC800 Mini-Kit are available for download here. See what the LPCWare community did with it! In 2013, NXP ran the LPC800 Simplicity Challenge, and the LPCWare community showed amazing inventiveness in what they created. Check out what they did on our LPC800 campaign pages. Further LPC800 Resources In addition to the LPC800 Mini-Kit Code Base above, you may find some of the following links useful working with the LPC810: LPC810 Product Page on NXP.com LPC800 Switch Matrix Configuration Tool Introducing the LPC800 Videos on YouTube LPC800 Switch Matrix: Making life easier one pin at a time (LPCNow.com) LPC800 LPCXpresso Board Schematics LPCXpresso Forum (for LPCXpresso related support) Tutorial: Getting Started with the LPC810 (Adafruit.com) Programming the LPC800 Mini-Kit with Flash Magic The LPC800 mini board can be programmed using any SWD debugger and your favorite IDE -- NXP's own LPCXpresso, as well as IAR, Keil uVision, and Crossworks for ARM all support the LPC800 out of the box! -- but you can also use an inexpensive UART/USB adapter and ISP mode to program the flash memory on the LPC810. What You'll Need A USB to UART cable or adapter, such as FTDI's popular 'TTL-232R-3V3' cables or a breakout based on the FT232RL chipset The latest version of the free Flash Magic tool​ Configuring the LPC800 Mini Board The first step you will need to do is connect you UART to USB adapter cable to the 'FTDI' header on the top of the LPC800 Mini Board. The pin layout is setup to match FTDI's popular cables by default, specifically the 'TTL-232R-3V3'. Other adapters can of course be used, but you will need to connect the GND, VCC, TXD and RXD pins in the right location yourself. FTDI's TTL-232R-3V3 cable is shown connected here as a reference: LPC800-mini-board The next step is placing the LPC810 in 'ISP' mode. This is accomplished by pulling PIO0_1 'low' during reset, which causes the bootloader to enter ISP mode. The LPC800 mini board conveniently has an 'ISP' switch – the white button in the bottom left-hand side of the board – which we can hold down to pull the ISP pin low. While continuing to press the ISP button, press and then release the 'RESET' button (the red button on the opposite side of the board). This will cause the board to reset, the internal bootloader will see that the ISP pin is low, and it will enter ISP mode where we can program the flash in Flash Magic using the on-chip UART0 peripheral. Configuring Flash Magic for the LPC810 The next step requires you to download and install the latest version of Flash Magic if you haven't already done so. It's available for free at http://www.flashmagictool.com/. Once installed, open the tool, and the run through the following steps: Setup the 'Communications' options: Select LPC810M021FN8 as your target device Set your COM port to whatever port your USB to UART adapter enumerated as (you can find this in the device manager in Windows) Set the Baud Rate to 115200, or whatever matches your USB to UART adapter Make sure that the 'Interface' is set to 'None (ISP)' Set the Oscillator to '12', which matches the speed of the IRC used by the bootloader You can double-check all of your communications settings and connection by selecting the 'ISP > Read Device Signature …' menu item. If you are in ISP mode and properly connected, with the right 'Communications' settings, you should see something similar to the following screen:FlashMagic Device IDIf you get an error message, double check your connections and your settings in Flash Magic, making sure you are actually in ISP mode on the LPC810, and that you've selected the right COM port. Check the 'Erase blocks used by Hex File' checkbox in the 'Erase' section. Select your hex file in the 'Hex File' section: Use the 'Browse' button to point to the Intel Hex file generated by your toolchain or IDE (for example, LPCXpresso). You can also use one of the sample .hex files available here if you don't have a .hex file ready yet. You should end up with Flash Magic configuration as follows ('Verify after programming' is optional): Flash magic settings: Now click the 'Start' button to program the flash … … and finally, once the device has been programmed, reset your board (via the red 'Reset' button). If at some point you want to change your firmware, simply repeat the process of re-entering ISP mode by holding the ISP pin low, resetting the LPC810, releasing the ISP pin, and the programming the device via Flash Magic again. Known issues There is an issue with some of the LPC810 DIP8 parts that are populated on the mini board that prevents the analog comparator from functioning. To see if the part on your board is affected, locate the date code on the top of the DIP8 package (the last line of text on top of the chip). If this line end with either "2X" or "2A", your part is affected. LPC800 mini board schematics Rev AR2.pdf - Attached
記事全体を表示
This document introduces how to debug TrustZone project on MCUXpresso IDE.   Use the latest version of MCUXpresso IDE v10.3.1. Project is from SDK_2.5.0_LPCXpresso55S69. Board is LPCXpresso55s69, use the LinkServer debug probe(on board debugger).   Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project. The secure project is stored in SDK_2.5.0_LPCXpresso55S69\boards\lpcxpresso55s69\trustzone_examples\<application_name>\ cm33_core0 \<application_name>_s directory. The non-secure project is stored in SDK_2.5.0_LPCXpresso55S69\boards\lpcxpresso55s69\ trustzone_examples\<application_name>\ cm33_core0 \<application_name>_ns directory. The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project. In this document, we use “hello_world” as example, this project contains both “hello_world_s” and “hello_world_ns” projects. Unlike Keil or IAR IDE, MCUXpresso IDE can’t debug jump directly from secure project to no-secure project, so we need add the no-secure executable file to secure project debug configuration manually(For this version of MCUXpresso IDE v10.3.1, we need do this step, while for  the later new versions, maybe they support jump directly from secure project to no-secure project ). Steps outline: Import “hello_world_s” and “hello_world_ns” project. Build “hello_world_s” and “hello_world_ns”, without any error. Erase flash. Program no-secure project “hello_world_ns ”. Kill active debug. Add the location of file “lpcxpresso55s69_hello_world_ns.axf” to Debugger commands of “hello_world_s” project, and download “hello_world_s” project. After finish download, it stop at “hello_world_s” project, set a breakpoint at “hello_world_ns” project: Debug project Detailed steps please refer to DOC in attachment. Hope it helps, BR Alice
記事全体を表示
This document is an introduction to the Programmable Logic Unit (PLU) provided for the LPC804 MCU device. PLU is used to create small combinatorial and/or sequential logic networks including simple state machines. This allows to replace external components like the 74xx series, which are used for the glue logic with the microcontroller and external devices, making simple the PCB and saving design costs. Figure 1. LPC80x MCU families The PLU is comprised of an array of 26 inter-connectable, 5-input Look-up Table (LUT) elements, and 4 flip-flops.  Each LUT element contains a 32-bit truth table (look-up table) register and a 32:1 multiplexer. During operation, the five LUT inputs control the select lines of the multiplexer. This structure allows any desired logical combination of the five LUT inputs. Figure 2. PLU Features The PLU is used to create small combinatorial and/or sequential logic networks including simple state machines. The PLU is comprised of an array of 26 inter-connectable, 5-input Look-up Table (LUT) elements, and 4 flip-flops. Eight primary outputs can be selected using a multiplexer from among all of the LUT outputs and the 4 flip-flops. An external clock to drive the 4 flip-flops must be applied to the PLU_CLKIN pin if a sequential network is implemented. Programmable logic can be used to drive on-chip inputs/triggers through external pin-to-pin connections. A tool suite is provided to facilitate programming of the PLU to implement the logic network described in a Verilog RTL design.   Advantages Some advantages of the PLU are: Replace the combinational logic of the 7400 series. State machine design using Flip-flop. Address decoder. Pattern match. Low-power application. PLU works in deep-sleep and power-down mode. Programmable so PLU can be reprogrammed and reused. Seamless connection using SWM and PLU. Pin description There are up to six primary inputs into the PLU module, one clock input, and eight primary outputs. All the inputs are connected directly to the package pins via chip-level I/O multiplexing.  All these pins can be enabled by configuring the relevant SWM register (PINASSIGN_FIXED0). A particular logic network may not require all of the available inputs or outputs. The user can specify which inputs and outputs to use, and which package pins those inputs and outputs will connect to as part of the overall top-level IO configuration. Registers Programming the PLU to implement a particular logic network involves writing to the various Truth Table registers to specify the logic functions to be performed by each of the LUT elements, programming the Input multiplexer registers to select the five inputs presented to each LUT, and programming the Output multiplexer register to select the eight primary outputs from the PLU module. Programming of all of these registers is performed only during initialization. Table 1. PLU registers PLU Shield board with LPCXpresso804 The OM40001 package includes a shield board for use with the LPCXpresso804 board when prototyping programmable logic unit (PLU) designs. The PLU shield provides the following features to assist with this type of development: 5 slide switches to enable 5 possible PLU inputs to be connected to VDD (marked as VCC on the Shield) or GND through a resistor (to set those inputs to a logic 1 or zero). 8 LEDs with jumpers to connect/disconnect possible PLU outputs for visual status indication. Push button option for momentary / edge signal inputs. Low-frequency oscillator with 1024Hz and 8Hz outputs. The PLU shield also includes a test circuit that can be used to implement a simple continuity tester. Several signals from the LPC804 used on the PLU Shield are shared with other functions on the main LPCXpresso804 board. Please review jumper settings on the LPCXpresso804 board carefully before installing the PLU Shield. https://www.nxp.com/docs/en/user-guide/UM11083.pdf  Figure 3. LPCXpresso804 + PLU Shield = PLU demo board   PLU input options On/off switches S1 through S5 connect possible PLU inputs to VDD or GND via a resistor, enabling those inputs to be driven to a known, fixed state. PIO0_8 is connected to a push button (S6) and a 100kohm pull up to VDD; PIO0_8 will be grounded when the button is pressed. Table below shows these connections. Table 2. PLU input on/off switches. A digital oscillator circuit is also included on the Shield, with 1.024kHz and 8Hz outputs available. LPC804 signal PIO0_1 can be connected to these oscillator signals in order to provide a low-speed clock to the flip-flops in the PLU block. The center pin (2) of JP12 connects to PIO0_1, so a jumper can be placed onto JP12 to connect this signal to the required clock (see markings on the Shield silk screen.) An external clock can be provided to the PLU by connecting it to the center pin of JP12. PLU output options LEDs are used to monitor the PLU outputs. Due to the limited number of pins on the chip/board, some of the inputs and outputs are shared. Table 3. PLU shield LEDs. PLU examples You have two options to find a PLU example: Using the SDK for the LPCXpresso804. You can download the SDK for the LPCXpresso804 from Welcome | MCUXpresso SDK Builder The PLU project is a simple demonstration program of the SDK PLU driver. In this example, a number of switches are used act as PLU inputs and LEDs are used to monitor the PLU outputs to demonstrate the configuration and use of the Programmable Logic Unit (PLU). Using the LPC804 Example Code Bundle. Code Bundle, containing source code for drivers, example code and project files. You can download it from LPCXpresso804 board for LPC804 Microcontroller (MCU)|NXP  It is recommended to use the PLU configuration tool. Please check the following links for more details. PLU Tool Direct, LUT-based design: https://www.nxp.com/video/part-2-plu-tool-direct-lut-based-design:Part2-PLU-config-tool-verilog PLU Tool Schematic design: https://www.nxp.com/video/part-3-plu-tool-schematic-design:Part3-PLU-config-tool-schematic PLU Tool Importing Verilog files: https://www.nxp.com/video/part-4-plu-tool-importing-verilog-files:Part4-PLU-config-tool-directlut
記事全体を表示
At the time of the latest update to this article, the latest silicon revision of the LPC55S6x is revision 1B. Since Nov,2019, all the LPCXpresso55S69 EVK boards marked as Revision A2 or A3 are equipped with revision 1B silicon. Initial production boards that have 0A silicon installed are marked Revision A1.                                     NXP introduced its new debug session request functionality on silicon revision 1B. For some IDE versions, the method of initiating a debug session is designed for current 1B silicon revisions and will result in an endless loop when used on older revision 0A parts due to the older revision not implementing some aspects of the handshake protocol. The protocol for this debug connection method, including handling of both 0A and later silicon revisions correctly, is included in the latest LPC55S6x/S2x/2x User Manual, section Debug session protocol.   IDE Considerations MCUXpresso IDE MCUXpresso IDE v11.0.1, incorrectly only supports silicon revision 1B debug session requests and cannot silicon to revision 0A parts in some situations. When connecting LPCXpresso55S69 Revision A1 board, you may have connection error like this: NXP released an MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix1 for this issue. Please follow the steps to fix the issue below if you have to use IDE v11.0.1 with silicon revision 0A; however it is recommended to update to the latest version of the IDE instead of taking this approach: https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/10/30/mcuxpresso-ide-v1101-lpc55xx-debug-hotfix IAR According to our test: IAR Embedded Workbench for ARM v8.42 and later can support both silicon revision 1B and 0A production without issue, which can be downloaded from https://www.iar.com/iar-embedded-workbench/tools-for-arm/arm-cortex-m-edition/ Note: The IAR 8.50.5 changed the CMSIS-DAP debug support for trustzone feature. There is known debug issue with the combination of IAR 8.50.5+SDK2.8.0. Thus our recommendation is:        Use IAR 8.50.5 with SDK2.8.0       Use IAR 8.40.2 with SDK 2.7.1   Keil MDK Both Keil MDK v5.28 and v5.29+ latest LPC55S69 pack v12.01 can support silicon revision 1B without problem but cannot support silicon revision 0A. LPC55S69 Revision 0A vs. 1B differences summary Silicon Revision 0A production 1B production Board Revision A1 A2 Deliver Date Before Nov,2019 After Nov,2019 Debug Access handshake Supported but not required. Handshake signaling partially supported Required Secure Boot Revision SB2.0 SB2.1 Maximum CPU Frequency 100MHz 150MHz IDE revision required 1.      MCUXpresso IDE v11.0.0 and older 2.      MCUXpresso IDE v11.0.1 + hotfix1 3.      MCUXpresso IDE 11.1 and later MCUXpresso IDE v11.0.0 and newer SDK version SDK2.5 and newer are supported; SDK2.6.3 and newer are recommended SDK2.6.3 and newer     LPC55S69 Defect Fix: 0A vs. 1B 0A Production 1B Production Defect: For PRINCE encrypted region, partial erase cannot be performed Fixed Defect: For PUF based key provisioning, a reset must be performed Fixed Defect: Unprotected sub regions in PRINCE defined regions cannot be used. Fixed Defect: Last page of image is erased when simultaneously programming the signed image and CFPA region Fixed Defect: PHY does not auto-power down in suspend mode Fixed For more detail, see Errata sheet LPC55S6x which can be downloaded  from NXP web site.   Pre-production Silicon: Note that NO BOARDS WERE EVER SOLD THROUGH DISTRIBUTION WITH PRE-PRODUCTION SILICON. In case you have board marked with Revision 1, 2 ,A, or A1 board with 1B silicon, contact NXP to ask for production replacement.   Get Silicon Revision: The silicon revision info is marked on the chip and board revision is marked on the board silkscreen. For silicon revision marking information, please consult LPC55S6x Data Sheet section 4. Marking . Below is an example of silicon revision marking information where revision is highlighted in red: The user application can also get the silicon revision through chip revision ID and number: SYSCON->DIEID:     The English and Chinese version documents are attached.  
記事全体を表示
For the CM33 of LPC55S6x family, the trust zone module is integrated, the memory space and peripherals are classified as security and non-security space. In order to generate interrupt in non-security mode, the NVIC module including the NVIC_ITNSx register must be initialized in security mode so that interrupt module can generate interrupt in non-security mode. The example demos that MRT0 module generates interrupt in non-security mode, the NVIC module is initialized at security mode, MRT0 is initialized at non-security mode. The project is based on MCUXpresso IDE ver11.1 tools, LPC55S69-EVK board and SDK_2.x_LPCXpresso55S69 SDK package version 2.11.1.
記事全体を表示
For LPC55(S)1x/2x/6x users, please update your fsl_power_lib to SDK2.8.2. The previous SDK(2.6.x and 2.7.x)'s power library have two known function bugs,  1. FRO trim value can not be recovery correctly after wakeup from deep-sleep / power-down / deep power-down.    -- this means the 12MHz FRO frequency is different for after boot-process(11.99 MHz for example) and wakeup from low-power modes(11.89MHz for example).     -- The reason is the FRO trim value not recovery after wakeup.  2. Cap-bank value can not be set correctly by use power lib capbank trim API.    -- This is a software bug which fixed in SDK2.8.2 already. Just replacement the power_lib library file should be workable for most of customers. the API should be compatible. Thank you! Magicoe
記事全体を表示
Test Elapsed time based on CTimer module   Sometimes, It is required to test the time which an api function takes when the function is executed, for example, some users want to test the flash erasing time and flash programming time. User can use GPIO to set/clear and use scope to test the GPIO timing to measure the time an api function takes, the method is very simple and straightforward but inaccurate. The document describes to configure CTimer as a 32bits  free-running counter, user can read the counter value before and after an api function and compute the counter value difference to get the time the api function takes. The CTimer of LPC54xxx family counts the APB bus clock, the APB bus clock Is driven by 12 MHz FRO, user can use the following code to measure the elapsed time. For example, we test the elaped time of  delayTimer(10000); function, we get the variable tPoint1, tPoint2. The actual time is (tPoint2- tPoint1)*(1/12000000). In the example, the tPoint2=110127, the tPoint1=53, the elapsed time is (110127-53)*(1/12000000)=9.172us. //the souce code focuses on LPC54xxx family uint32_t tPoint1,tPoint2,tPoint3,tDiff; void test(void) {     tPoint1=CTIMER_GetTimerCountValue(CTIMER2);     //simulate elapsed time     delayTimer(10000);     tPoint2=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint2-tPoint1;       //simulate elapsed time     delayTimer(20000);     tPoint3=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint3-tPoint2;      PRINTF("Time instand:tPoint1=%d, tPoint2=%d, tPoint3=%d \r\n",tPoint1,tPoint2,tPoint3); } Snippet of simple source code based on MCUXpresso tools and LPC54618 board developed by XiangJun Rong #include "fsl_ctimer.h" void test(void); void CTimerInit(void); void delayTimer(uint32_t elapsedTimer); uint32_t tPoint1,tPoint2,tPoint3,tDiff; void CTimerInit(void) {     ctimer_config_t config;     ctimer_match_config_t matchConfig;     /*CTimer use APB bus clock as Timer tick, set the APB bus clock as 12MHz internal FRO */      CLOCK_AttachClk(kFRO12M_to_ASYNC_APB);     CTIMER_GetDefaultConfig(&config);       CTIMER_Init(CTIMER2, &config);       matchConfig.enableCounterReset = true;     matchConfig.enableCounterStop = false;     matchConfig.matchValue = 0xFFFFFFFF;     matchConfig.outControl = kCTIMER_Output_NoAction;     matchConfig.outPinInitState = true;     matchConfig.enableInterrupt = false;     CTIMER_SetupMatch(CTIMER2, kCTIMER_Match_3, &matchConfig);     CTIMER_StartTimer(CTIMER2); }   void test(void) {     tPoint1=CTIMER_GetTimerCountValue(CTIMER2);     //simulate elapsed time     delayTimer(10000);     tPoint2=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint2-tPoint1;       //simulate elapsed time     delayTimer(20000);     tPoint3=CTIMER_GetTimerCountValue(CTIMER2);     tDiff=tPoint3-tPoint2;      PRINTF("Time instand:tPoint1=%d, tPoint2=%d, tPoint3=%d \r\n",tPoint1,tPoint2,tPoint3); }   void delayTimer(uint32_t elapsedTimer) {     uint32_t i;     for(i=0; i<elapsedTimer; i++)     {         __asm("nop");     } }   int main(void) {    …………………………………………………………………………………………………..     PRINTF("Elapse time test start: \r\n");     CTimerInit();     test();     for(;;) {} ………………………………………… }  
記事全体を表示