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

ディスカッション

The following document contains a list of documents, questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in LPC or MCUXpresso you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table FAQ: MCUXpresso Software and Tools How to create a new LPC project using LPCOpen and MCUXpresso IDE Introducing MCUXpresso SDK v.2 for LPC54xxx Series Generating a downloadable MCUXpresso SDK v.2 package Using the MCUXpresso Pins Tool MCUXpresso Config Tools is now available! LPC55xx Multicore Applications with MCUXpresso IDE LPC information LPC5460x MCU Family Overview USB with NXP Microcontrollers LWIP memory requirements LPC800 Four-Part Webinar Series! The LPC804 Programmable Logic Unit (PLU) LPC84x Technical Training - Now Available Guides and Examples Flashing and Installing the new firmware and drivers for LPC11U35 debug probes Enabling debug output USB FLASH download, programming, and security tool (DFUSec) DMA Ping-Pong application Getting start with LPCXpresso54608 & emWin Graphics; Capacitive Touch example using the LPC845 Breakout Board OLED Display Application Example using LPC845 Breakout Board and SPI Mixed-Signal Logic Analyzer & Oscilloscope (Lab Tool) Solution LPC FAQ How to calculate the value of crystal load capacitors? Can I send a message with X/Y/Z bits in the ID? What is the difference between error active and error passive? What is the sample point for? How can I verify the configured CAN bitrate, using an oscilloscope?

ADCHS and DAC programming with LPC-Link 2 + LabTool Dirceu Rodrigues, Jr. - Oct. 2013 Bio Dirceu Rodrigues, Jr. is a computer engineer with a master's degree in electrical engineering. As an independent consultant, he tests new products with particular interest in the areas of wireless sensor networks, ARM processors, DSP, motor control, and medical applications. Introduction When I got involved with this campaign, my initial idea was to use the NXP LPC4370 microcontroller available on the LPC-Link 2 to implement a multicore FIR filter. Combined with the analog processing capabilities present on LabTool add-on board, would be ideal to put in place a structure which I discussed on ESC Brazil 2013 (Multicore Microcontrollers in Instrumentation and Control). But after a time studying the schematics of these boards, I realized that understanding the signal conditioning circuits, gain settings, input calibration and the correct use of ADCHS (12 bit High Speed ADC) peripheral and external DAC, deserve a whole article. For me, the most important feature of the board LPC-Link 2 (in addition to being a programmer/debugger for the target) is able to program a generic application on LPC4370 memory, since there are several analog/digital pins available on expansion connectors. Firstly, I downloaded the latest version of the ARM Keil µVision (V4.72.10.0). At time, I had not experienced the new LPCOpen library, so I changed the LPC43xx.h provided by the compiler to add a raw support for ADCHS peripheral - renaming it to LPC43xx_new.h. The change consists primarily in define register addresses, enabling references such as “LPC_ADCHS->xxx”. Before attach LPC-Link 2 on top of LabTool board, I connected the 10 pin SWD cable on J2 of LPC-Link 2, according Figure 1. Will look like the cable is squeezed between the boards, but that is quite normal. Also, the user must to ensure the other connectors are not slightly misaligned. LabTool - Analog Inputs Next I tried to unveil the structure around the high speed analog to digital converter. The reason for the presence of the BNC connectors on LabTool is to implement a complete two channel oscilloscope, whose features are far from modest, since the LPC4370 includes a 12 bit ADC, and can operate up to 80 MHz. Note that the two 10 bit ADC modules are absent on LPC4370 TFBGA100 package used in LabTool. A very simplified schematic of input conditioning circuit for each channel is shown on Figure 2. The complete design, provided by Embedded Artists[1], includes several other components, including capacitors for shaping the frequency response. All settings are controlled via the SPI interface, including the DC/AC coupling. The input (0.5 V) is provided by a proper MCU pin related to ADCHS, as I will explain later. Two analog multiplexers allow set the gain when changing the operational amplifier feedback resistor. From the nominal values of components on figure, we can write some equations for the DC model: The LPC4370 ADC is a flash type with differential input - Figure 3. The value converted to digital domain, as presented on page 1287 of LPC43xx User Manual (2013 draft version), is: Through the DCINNEG and DCINPOS bits on ADCHS POWER_CONTROL register, the user can add a 0.5 V DC offset to the differential inputs. In the case of Labtool board, is convenient make DCINNEG = 1 and DCINPOS = 0, considering the presence of amp op with the non-inverting input voltage according Figure 2. With these settings: and . Also, note that Substituting these results on Eq. 4: , and: Defining: The value of G A depends on position of two multiplexers (feedback resistor selection 1 out 😎 and SPDT switch (divided input voltage selection V U or V D ). So, I can create the Table 1, which allow me to calculate the analog input value or V CH1 , for each selection. Feedback resistance Non-inverting Amp. Op. gain GA VCH1 2k87 // 158R 2 0.4 2k87 // 536R 4 0.8 2k87 // 1k65 8 1.6 2k87 20 4 0R 1 0.016 1k33 // 270R 2.5 0.04 1k33 // 1k07 5 (4.95) 0.08 1k33 10 ( 9.86) 0.16 In order to obtain a value of acceptable precision it's required to compensate the ADC readings (N ADC ) for component tolerances and other deviations associated with the input conditioning circuit. This is done in software. An affine function (gain and offset) makes the correction based on the current reading and previous calibration data – Listing 1. Remember that a measuring instrument is not only as good as its components, but also as the calibration method used. LabTool - Analog Outputs The Digital to Analog section is more straightforward. Since the 10 bit DAC module is absent on LPC4370 TFBGA100 package, the LabTool board relies on external DAC102S085 from National to output two analog voltages. As before, the simpler schematic on Figure 4 shows the essential components for the DC model. On LabTool board, the LPC4370 SSP1 peripheral has three usages: Settings for the ADCHS conditioning circuit. Writing on DAC Communication with an EEPROM The sharing is carried out through appropriate slave selection signals (SSEL and GPIOs) from MCU. The DAC has two channels with internal data register including controls for update/refresh timing. The relevant equations are: Substituting Eq. 7 in Eq. 8: Application: Filtering an ECG In order to test the ADCHS and related equations obtained from the LabTool manufacturer schematics, I decided to program the ARM Cortex-M4 on LPC4370 to implement a stop-band FIR (Finite Impulse Response) filter with 127 taps. The idea is to filter an ECG signal corrupted by 60 Hz hum. To avoid building a circuit around an instrumentation amplifier (something I've done a few times) and waste some skin electrodes; I thought using the computer sound card to generate the desired signal. So, the following tasks were performed: Find an ECG signal database in audio format [2]. Select the file ecg.wav (60s duration, 16 bit, 1 kSa/s). Extract the file data on Matlab, insert a 60 Hz noise and rewrite it in wav format . Play the file on computer line-out using a software for audio editing like GoldWave. This will allow some experimentation, as repeat intervals, invert polarity, attenuate and many other useful transformations - Figure 6. Design a notch FIR filter in Matlab and simulate the result. Make a header file with the generated 127 coefficients. For this application, I used DC coupling on input (capacitor short-circuited on Figure 2). Also, the ADCHS was configured to present the result in two’s complement format (other option is offset binary) . Figure 7 shows a diagram for the FIR filter - coefficients and output labeled as c and NFILT, respectively. To check the result, the filtered signal is sent to the analog output in real time. For this it’s necessary to perform a conversion between the ADCHS and DAC102S085 ranges using appropriate equations. Here I have at least two options: 1. Taking advantage of maximum available resolution (not used): In this case, the conversion is performed through the Equation 10 and Figure 8. Substituting Eq. 10 on Eq. 9: In order to ensure compatibility with the amplitude of sound card output it is appropriate to select the gain 10 for the ADC non-inverting amplifier (last row of Table 1). Therefore, the equation for the analog to digital conversion is: This leads to a maximum input voltage around +/- 2.5V, when -2048 <= NFILT < +2048. Combining Eq.11 and Eq. 12, the relationship b etween input and output is given by: 2. Equal amplitudes (input/output): In the ECG filtering applicatioon it is desirable that the original and filtered signals had the same amplitude, or a 1:1 relationship. Therefore, I've carried a different conversion in order to meet VEXT_AOUT1 = VCH1. Still maintaining the gain 10 between VCH1 and NFILT and equating Eq. 12 and Eq. 9: Thus resulting in the equation responsible for the conversion: Armed wiht this modeling I did a simulation on Matlab. The plots on Figure 9 allowed me to check the filter performance by comparing the input, the noisy signal and the output. Note an approximate delay of 64ms between the input and output (representing taps/2 samples). With this set of equations and the FIR itself coded on LPC4370, the final result is shown following. The sampling and output rates both are equal to 1k/s. Note an approximate delay of 64 ms between input and output (representing taps/2 samples). This powerful microcontroller and its high speed ADC are able to handle sample rates much higher than the one I used here, including multichannel audio. As I mentioned earlier, the purpose of this simple application is just to introduce the analog resources available on LabTool board. Conclusion The ADCHS has many other configuration options. It works through a state machine with a dedicated timer and a set of eight descriptors, for which it is possible to establish how and when a conversion occurs, generating interrupts, filling a 16 position FIFO or transferring data through DMA The clock for this application was adjusted to 180 MHz, a value more than sufficient. In a next installment, I intend to wake-up the other two Cortex-M0 cores on the LPC4370, implementing a truly multicore filter through IPC (Inter-process Communication), running at a lower clock; something like 60 MHz and compare the results with the single core solution – for example, analyzing the power consumption. Stay tuned [3]. References [1] http://www.embeddedartists.com [2] http://courses.engr.illinois.edu/bioe415/labs/ecgwav.html [3] http://www.youtube.com/DirceuRodriguesJr

SCTimer implement traffic signal Overview The State Configurable Timer (SCTimer/PWM) is a peripheral that is unique to NXP Semiconductors. It can operate like most traditional timers, but also adds a state machine to give it a higher degree of configurability and control, in another word, the SCTimer/PWM can be considered as consist of Stand Timer and State/Event Logic (Fig 1). This allows the SCT to be configured as multiple PWMs, a PWM with dead-time control, and a PWM with reset capability, in addition to many other configurations that can’t be duplicated with traditional timers. Once the SCTimer/PWM has been configured, it can run autonomously from the microcontroller core, unless the SCTimer/PWM interrupt has been enabled which requires the core to service the interrupt. Fig 1 The first time you look at the SCTimer/PWM, it may appear to be a very complex peripheral, but you will see that it is actually not that difficult to use. Understanding the Event and State is critical to understanding the SCTimer/PWM. Event: The following conditions define possible events: a counter match condition, an input (or output) condition, a combination of a match and/or an input/output condition in a specified state, and the count direction. Events can control outputs, interrupts, DMA requests and the SCTimer/PWM states. They can also cause timer limit, halt, start, or stop conditions to occur. State: The state variable is the main feature that distinguishes the SCTimer/PWM from other counter/timer/PWM blocks. Events can be made to occur only in certain states. Events, in turn, can perform the following actions: a) Set and clear outputs; b) Limit, stop, and start the counter; c) Cause interrupts; d) Modify the state variable; Regarding the event and state mechanism (Fig 2 show a basic example), The SCT allows the user to group and filter events, thereby selecting some events to be enabled together while others are disabled. A group of enabled and disabled events can be described as a state, and several states with different sets of enabled and disabled events are allowed. Changing from one state to another is event driven as well and can happen without software intervention. Formally, the SCTimer/PWM can be programmed as state machine generator. The ability to perform switching between groups of events provides the SCT the unique capability to be utilized as a highly complex State Machine engine. Events identify the occurrence of conditions that warrant state changes and determine the next state to move to. This provides an extremely powerful control tool - particularly when the SCT inputs and outputs are connected to other on-chip resources (comparators, ADC triggers, other timers etc.) in addition to general-purpose I/O. Fig 2 Traffic signal implementation Fig 3 illustrates the application of the SCT to simulate the traffic signal. Fig 3 v Demo create LPCOpen is an extensive collection of free software libraries (drivers and middleware) and example programs that enable developers to create multifunctional products based on LPC microcontrollers. In this article, I will illustrate the steps of creating a new demo in the LPCOpen, for instance, create a demo by using the IAR IDE. Since the selected hardware board is the LPCXpresso824, the creating work is based on the corresponding LPCOpen. Creates a new project Fig 4 2. Create the example and lib groups, then add the startup and board initialization files under the example group and add the library files: board_nxp_lpcxpresso_824.a and chip_82x_lib.a under the lib group. Next, create a main.c file: traffic_signal_demo.c. Fig 5 3. Add the corresponding paths $PROJ_DIR$\..\..\..\..\..\..\software\lpc_core\lpc_chip\chip_8xx\config_82x $PROJ_DIR$\..\..\..\..\..\..\software\lpc_core\lpc_chip\chip_common $PROJ_DIR$\..\..\..\..\..\..\software\lpc_core\lpc_chip\chip_8xx $PROJ_DIR$\..\..\..\..\..\..\software\lpc_core\lpc_board\board_common $PROJ_DIR$\..\..\..\..\..\..\software\lpc_core\lpc_board\boards_8xx\nxp_lpcxpresso_824 $PROJ_DIR$\..\..\..\..\..\..\software\CMSIS\CMSIS\Include 4. Miscellaneous settings For instance, target selecting, adds the linker file, add other c files (Fig 6),etc. Fig 6 v Crucial code Table 1 main.c /** * @brief Application main program * @return Nothing (This function will not return) */ int main(void) { /* Generic Initialization */ SystemCoreClockUpdate(); /*Set system clock div as 30*/ Chip_Clock_SetSysClockDiv(30); /*Assign SCT_out to board LED pin*/ Chip_SWM_MovablePinAssign(SWM_SCT_OUT1_O, 13); // assign SCTOUT_0 to P0_13 YELLOW_LED Chip_SWM_MovablePinAssign(SWM_SCT_OUT2_O, 27); // assign SCTOUT_0 to P0_27 GREEN_LED Chip_SWM_MovablePinAssign(SWM_SCT_OUT0_O, 17); // assign SCTOUT_0 to P0_17 RED_LED /* Initialize the SCT clock and reset the SCT */ Chip_Clock_EnablePeriphClock(SYSCTL_CLOCK_SCT); Chip_SYSCTL_PeriphReset(RESET_SCT); /*Initialize SCT*/ sct_fsm_init(); /* Start the SCT counter by clearing Halt_L in the SCT control register */ Chip_SCT_ClearControl(LPC_SCT, SCT_CTRL_HALT_L); /* Enter sleep mode */ while (1) { __WFI(); } } Table 2 sct_fsm_init(void) void sct_fsm_init (void) { /*The SCT operates as a unified 32-bit counter*/ LPC_SCT->CONFIG = (LPC_SCT->CONFIG & ~0x00060001) | 0x00000001; /* UNIFIED */ /* MATCH/CAPTURE registers */ LPC_SCT->REGMODE_L = 0x00000000; LPC_SCT->MATCH[0].U = entry_mat; /* entry_match */ LPC_SCT->MATCHREL[0].U = entry_mat; LPC_SCT->MATCH[1].U = flash; /* flash_mat0 */ LPC_SCT->MATCHREL[1].U = flash; LPC_SCT->MATCH[2].U = flash1; /* flash_mat1 */ LPC_SCT->MATCHREL[2].U = flash1; LPC_SCT->MATCH[3].U = delay; /* match0 */ LPC_SCT->MATCHREL[3].U = delay; LPC_SCT->MATCH[4].U = yel_delay; /* yel_delay_mat */ LPC_SCT->MATCHREL[4].U = yel_delay; LPC_SCT->MATCH[5].U = yel_flash; /* yel_flash_mat */ LPC_SCT->MATCHREL[5].U = yel_flash; /* OUTPUT registers */ /*Event 1 set the output*/ LPC_SCT->OUT[5].SET = 0x00000002; /* out_track */ /*Event 3 clear the output*/ LPC_SCT->OUT[5].CLR = 0x00000008; /*Event 0 and 3 set the output*/ LPC_SCT->OUT[2].SET = 0x00000009; /* turn_green */ /*Event 7 clear the output*/ LPC_SCT->OUT[2].CLR = 0x00000080; /*Event 1 set the output*/ LPC_SCT->OUT[0].SET = 0x00000002; /* turn_red */ /*Event 0 and 6 clear the output*/ LPC_SCT->OUT[0].CLR = 0x00000041; /*Event 0, 2, 4, 5, 6 and 7 set the output*/ LPC_SCT->OUT[1].SET = 0x000000F5; /* turn_yellow */ /*Event 1, 3, 4, 5 set the output*/ LPC_SCT->OUT[1].CLR = 0x0000003A; /* Unused outputs must not be affected by any event */ LPC_SCT->OUT[3].SET = 0; LPC_SCT->OUT[3].CLR = 0; LPC_SCT->OUT[4].SET = 0; LPC_SCT->OUT[4].CLR = 0; /* Conflict resolution register */ LPC_SCT->RES = (LPC_SCT->RES & ~0x0000000C) | 0x0000000C; /* Set COMBMODE = 0x1. Event 0 uses match condition only. Set MATCHSEL = 0x0. Select match value of match register 0. The match value of MAT0 is associated with event 0 Set STATEV bits to 1 and the STATED bit to 1. Event 0 changes the state to state 1 */ LPC_SCT->EV[0].CTRL = 0x0000D000; /* U: --> state RED */ LPC_SCT->EV[0].STATE = 0x00000001; /* Set COMBMODE = 0x1. Event 1 uses match condition only. Set MATCHSEL = 0x3. Select match value of match register 3. The match value of MAT3 is associated with event 1 Set STATEV bits to 2 and the STATED bit to 1. Event 1 changes the state to state 2 */ LPC_SCT->EV[1].CTRL = 0x00015003; /* U: --> state YELLOW */ LPC_SCT->EV[1].STATE = 0x00000002; /* Set COMBMODE = 0x1. Event 1 uses match condition only. Set MATCHSEL = 0x4. Select match value of match register 4. The match value of MAT4 is associated with event 2 Set STATEV bits to 4 and the STATED bit to 1. Event 1 changes the state to state 4 */ LPC_SCT->EV[2].CTRL = 0x00025004; /* U: --> state YELLOW_FLASH */ LPC_SCT->EV[2].STATE = 0x00000004; /* Set COMBMODE = 0x1. Event 1 uses match condition only. Set MATCHSEL = 0x3. Select match value of match register 3. The match value of MAT3 is associated with event3 Set STATEV bits to 2 and the STATED bit to 1. Event 1 changes the state to state 2 */ LPC_SCT->EV[3].CTRL = 0x00015003; /* U: --> state YELLOW */ LPC_SCT->EV[3].STATE = 0x00000008; /* Set COMBMODE = 0x3. Event 6 uses when match and I/O condition occur. Set MATCHSEL = 0x5. Select match value of match register 5. Set OUTSEL = 1. Select output. Set IOSEL = 5. Select output 5. Set IOCOND = 0x0. Output 0 is Low The match value of MAT5 is associated with event 6 Set STATEV bits to 1 and the STATED bit to 1. Event 1 changes the state to state 1 */ LPC_SCT->EV[6].CTRL = 0x0000F165; /* U: --> state RED */ LPC_SCT->EV[6].STATE = 0x00000010; /* Set COMBMODE = 0x3. Event 6 uses when match and I/O condition occur. Set MATCHSEL = 0x5. Select match value of match register 5. Set OUTSEL = 1. Select output. Set IOSEL = 5. Select output 5. Set IOCOND = 0x3. Output 0 is High The match value of MAT5 is associated with event 7 Set STATEV bits to 3 and the STATED bit to 1. Event 7 changes the state to state 3 */ LPC_SCT->EV[7].CTRL = 0x0001FD65; /* U: --> state GREEN */ LPC_SCT->EV[7].STATE = 0x00000010; /* Set COMBMODE = 0x1. Event 1 uses match condition only. Set MATCHSEL = 0x1. Select match value of match register 1. The match value of MAT1 is associated with event4 Set STATEV bits to 4 and the STATED bit to 1. Event 1 changes the state to state 4 */ LPC_SCT->EV[4].CTRL = 0x00025001; /* U: --> state YELLOW_FLASH */ LPC_SCT->EV[4].STATE = 0x00000010; /* Set COMBMODE = 0x1. Event 1 uses match condition only. Set MATCHSEL = 0x2. Select match value of match register 2. The match value of MAT2 is associated with event5 Set STATEV bits to 4 and the STATED bit to 1. Event 1 changes the state to state 4 */ LPC_SCT->EV[5].CTRL = 0x00025002; /* U: --> state YELLOW_FLASH */ LPC_SCT->EV[5].STATE = 0x00000010; /* STATE registers */ LPC_SCT->STATE_L = 0; /* state names assignment: */ /* State U 0: U_ENTRY */ /* State U 1: RED */ /* State U 2: YELLOW */ /* State U 3: GREEN */ /* State U 4: YELLOW_FLASH */ /* CORE registers */ LPC_SCT->START_L = 0x00000000; LPC_SCT->STOP_L = 0x00000000; LPC_SCT->HALT_L = 0x00000000; /* Event0, 1, 2, 3, 6 and 7 reset the counter register */ LPC_SCT->LIMIT_L = 0x000000CF; LPC_SCT->EVEN = 0x00000000; LPC_SCT->DMAREQ0 = 0x00000000; LPC_SCT->DMAREQ1 = 0x00000000; } v Result demonstrate The demo runs on the LPCXpresso824-MAX board, and using the Blue led replaces the Yellow led, and the video shows the demo working. Fig 7 LPCXpresso824-MAX board Video's link: SCTimer implement traffic signal - YouTube

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!

The example demos how to use ARM TX Event to trigger ADC based on LPC55S69-EVK board and MCUXPresso IDE and SDK. As the Table 753, the “ARM tx event” is the one of the ADC triggering source, although it is a hardware triggering, but the mechanism is the same as software triggering, after ADC configuration, you execute the instruction asm(“SEV”); the ARM tx event will be generated and trigger ADC to sample. The ADC of LPC55xx support hardware trigger mode, each hardware trigger source corresponds to a trigger register, as the Table 753, the ARM tx event ASC triggering source index is 11, so you have to initialize the ADC trigger control register TCTRL11. In the TCTRL11 register, you can assign the command ID, select the FIFO0 or FIFO1 to save the ADC result, enable hardware triggering.

Hello Community! This document is provided as a hands-on lab guide. The intent of the lab is to demonstrate how to program and use the LPC8N04 development board by using the LPC8N04 board support package demo application and make use of the read, write and energy harvesting capabilities of the NFC tag. Setup The following items are needed to complete the lab: Software: • LPC8N04 Board Support Package MCUXpresso, can be downloaded at this link: https://www.nxp.com/downloads/en/lab-test-software/LPC8N04-MCUXpresso-BSP.zip • MCUXpresso IDE version 10.2.1, can be installed from here: https://www.nxp.com/mcuxpresso/ide • LPC8N04 NFC Demo Android application, can be installed at the link below: https://play.google.com/store/apps/details?id=com.nxp.lpc8nxxnfcdemo Hardware: • LPC8N04 Development Board for LPC8N04 MCU (OM40002): https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/lpc-cortex-m-mcus/lpc800-series-cortex-m0-plus-mcus/lpc8n04-development-board-for-lpc8n04-mcu:OM40002 • Android Phone with NFC • 1 Micro USB cable Hope this guide is helpful! Any comments are welcome. Best Regards, Carlos Mendoza Technical Support Engineer

Description The Telephone Answering Machine Design Example is a sophisticated telephone answering machine that provides everything commercial devices offer and more. Noteworthy features include improved voice quality and increased storage capacity over commercial machines. Additionally, Internet connectivity enables convenient messaging in the form of SMS messages or e-mails from anywhere in the world. Virtual answering machines can be set up for four different users. A user-friendly interface makes learning how to use this device and taking advantage of its many special features easy for anyone, regardless of their electronics savvy. The highly efficient system is designed around an LPC2138 microcontroller, which features an ARM7 RISC processor. Built with a small handful of components, the Telephone Answering Machine Design Example is cost-effective. The thoughtful inclusion of an external flash memory card and well-chosen algorithms for nearly unlimited storage capacity of crystal-clear messages contribute to the success of the design. Block Diagram Documentation Telephone Answering Machine Products Below are recommended microcontrollers for use in implementing a telephone answering machine. Comparison Table Product Pins On-Chip Flash On-Chip RAM Comments LPC2138 64 512KB 32KB Base microcontroller used in the design example. LPC2136 64 256KB 32KB A lower-cost microcontroller with the same amount of on-chip RAM but with only half the on-chip flash memory. LPC2146 64 256KB 32KB + 8KB An upgraded microcontroller with a USB interface. USB could be used instead of Ethernet to connect to a PC if Internet functionality is not desired. More Information Images Working Prototype Circuit Blocks Answer Flow Telephone Answering Machine Schematics Example Code Bill of Materials Disclaimer This design example shows possible hardware and software techniques used to implement the design. It is imperative that the viewer use sound engineering judgment in determining the fitness of this design example for any particular application. This design example may include information from 3rd parties and/or information which may require further licensing or otherwise. Additional hardware or software design may be required. NXP Semiconductors does not support or warrant this information for any purpose other than an informational design example. documentation.pdf 927.44 KB schematics.pdf 92.13 KB example.code_.zip 646.98 KB bom.txt 1.39 KB

Description The Audio Player Design Example, based on an NXP LPC2138 ARM7-based microcontroller, delivers high-quality, uncompressed, 16-bit digital audio playback. This design allows engineers to add MP3 music or sound effects to a variety of consumer applications at a very low cost. Entertaining sounds could be added to children's items or music clips could be easily added to products targeted at teens. There is no limit to the number of existing applications that could be enhanced by inexpensively adding high-quality sound or music. Block Diagram Documentation Audio Player Products Below are recommended microcontrollers for use in implementing this design to a system. Comparison Table Product Pins On-Chip Flash On-Chip RAM Comments LPC2138 64 512KB 32KB Base microcontroller used in the design example. LPC2136 64 256KB 32KB A lower-cost microcontroller with the same amount of on-chip RAM but with only half the on-chip flash memory. LPC2146 64 256KB 32KB + 8KB An upgraded microntroller with more on-chip RAM allowing for a real-time MP3 software decoder. The added USB interface allows file transfer with a personal computer. LPC2148 64 512KB 32KB + 8KB An upgrade to the LPC2138 microntroller, the LPC2148 substitutes Full-speed USB 2.0 device functionality for a slightly higher cost. More Information Images Working Prototype DAC Circuit SD Card InterfaceSchematics Audio Player Example Code Audio Player Disclaimer This design example shows possible hardware and software techniques used to implement the design. It is imperative that the viewer use sound engineering judgment in determining the fitness of this design example for any particular application. This design example may include information from 3rd parties and/or information which may require further licensing or otherwise. Additional hardware or software design may be required. NXP Semiconductors does not support or warrant this information for any purpose other than an informational design example. documentation.pdf 418.54 KB schematics.zip 123.65 KB example.code_.zip 719.42 KB

Continuously reducing the power consumption of integrated circuits is a constant topic in the development of integrated circuits. Reduced power consumption helps save power, extend standby time and reduce product heat, etc. Needless to say, low power consumption has become one of the important factors to measure product performance. We usually recommend customers to refer MCUXpresso SDK power_mode_switch_lpc demo as low power design reference code. With this demo, customers can use serial terminal to control MCU to enter four low power consumption modes：Sleep mode，Deep Sleep mode，Power Down mode and deep power down mode. Meanwhile, user can also choose a variety of wake-up methods to wake up MCU through UART command. However, when customers take use of power_mode_switch_lpc demo to measure lower power static characteristics, they find discrepancies with data sheet. Take example with LPCXpresso845MAX board. In power down mode, the demo board current reaches to around 100uA in debug mode. But data sheet states the typical current value is 1.5uA, no more than 10uA (see the Table below). Where is the problem? The purpose of the power_mode_switch_lpc demo is to demonstrate several low power modes and multiple wake-up methods to customers. We can’t get similar low power current value with default demo board as spec shows, but let's walk through a step-by-step demonstration and modify the routine to get the data sheet values. LAB ENVIRONMENT: Demo Board: LPCXpresso845MAX SDK: SDK_2.11.0_LPCXpresso845MAX Demo Code: power_mode_switch_lpc IDE：MCUXpresso IDE v11.5.0 STEP: 1. Download power_mode_switch_lpc to LPC845 development board and run it. The serial port selects low power mode, press (SW2 button) to wake up. The program runs into power down mode, with debugger connected, the measured Idd is 99.5uA To enter low power mode, the following code is used: POWER_EnterPowerDown(DEMO_ACTIVE_IN_DEEPSLEEP); In order to wake up, parameter DEMO_ACTIVE_IN_DEEPSLEEP is configured with PDSLEEPCFG. BOD and watchdog oscillator power domains are turned on. All these setting results in potential current loss, causing power supply current higher than expectation. 2. In this step, we will remove wakeup initialization code // DEMO_InitWkt(); Replace this line of code //POWER_EnterPowerDown(DEMO_ACTIVE_IN_DEEPSLEEP); //enter power down mode with BOD and watchdog osc with POWER_EnterPowerDown(0); //power down BOD and watchdog osc The modification is to turn off BOD power domain and watchdog clock in power down mode, compile and download the code again and enter the power down mode. At this time, the measured Idd is 57.3uA In this way, Idd is significantly reduced. However, 57.3uA is still far from the typical value of 1.5uA stated in the data sheet. This is due to MCU debug power domain is turned on by IDE debugger, which leads to extra current consumption. 3. Thus we disconnect debugger and let the development board work in stand-alone mode (power off and re-power on). After power on, LPC is in power down mode. At this time, the measured Idd is 1.4uA. This is quite similar as the current value in datasheet. Consider GPIO configuration: The spec data shown in datasheet are tested under a dedicated test board with almost no external peripheral devices, and unused pins are basically in a floating state. For custom board or LPCXpresso804 EVK. Some of its IO pins have external pull-up resistors and LEDs. If the GPIO is configured to output low power, the small light will be lit, resulting in additional power consumption. So we configure all pins as pull-up inputs for low power measurement. Consider package: The test is based on LPCXpresso845MAX equipped LPC845 64pin package. It also applies to LPC845 48pin package. 33 package doesn't have VDDA pin. Due to VDD and VDDA pin design are not exactly the same as other package, for instance, 33pin low power consumption in power down mode is slightly higher than 64/48pin, but no more than 10uA as our spec in DS. Summary: Low power current parameters of the data sheet are measured with all MCU oscillators and analog domains off. Besides, reasonable configuration of GPIO can further reduce MCU power consumption. Before entering the low power consumption mode, it is recommended to set the unused GPIO as a pull-up input according to the actual situation (It can also be set to output low when the pin is floating). In applications with high requirements for low power consumption, users need to carefully optimize the code design to obtain the best low power consumption design.

1 Abstract MCB1700 is the evaluation board from KEIL, the onboard chip is LPC1758, LPC1768 or LPC1769 which is based on ARM cortex-M3. EmWin is the embedded graphics library developed by SEGGER, it is now offered by NXP in library form for free commercial use with NXP microcontrollers. The software bundle offered by NXP includes the emWin Color basic package, the Window Manager/Widgets module including the GUIBuilder, the Memory Devices module for flicker-free animation, the Antialiasing module for smooth display of curves, lines and fonts, the Font Converter and the VNC Server. NXP have provided the MCB1700 emWin board support packages: emWin 5.14 BSP version 1.0 for MCB1700 This package includes three IDE project: IAR, MDK and LPCXpresso, but now, when customer use it, normally will find these questions: LPCXpresso project have the build error MDK project have the build error Some MCB1700 boards can’t work after downloading this code, LCD always display white, no other pictures. This document is mainly talking about these three problems and give the according solutions to make the MCB1700 emWin_mcb1700_bsp work. 2 Code issue analysis and solutions Customer need to download the emWin_mcb1700_bsp at first from the above link, and install it, after the package is installed in default, the source code can be found in this path: C:\nxp\emWin\NXP_emWin514_MCB1700_BSP 2.1 keil project build error This chapter mainly describe the emWin_mcb1700_bsp keil project build error and it’s solutions. 2.1.1 Problem reproduction Open the emWin_mcb1700_bsp keil project with keil IDE, you may find there has 6 errors like the following picture: All these errors are related to the GUI function which is included in the emwin lib, after click the GUI folder, you will find the lib is emWin_514 which is the old emWin lib. So people can try to use the newest lib from the nxp website. 2.1.2 Problem solution Download the newest emWin lib from this link: emwin 5.30 Pre-Compiled Libraries for NXP ARM MCUs After install it, copy emWin_M3.lib from folder: NXP_emWin530\emWin_library\Keil\ to NXP_emWin514_MCB1700_BSP\GUI folder. Then add this new lib to the KEIL project’s GUI folder like this: After the emWin_M3.lib is added, remove the build of old lib emWin_514_Keil4_M3_LE.lib, just deselect item include in Target build in the right click options like this: Save and rebuild it again, you will find the error is disappeared. 2.2 LPCXpresso project build error This chapter mainly describe the emWin_mcb1700_bsp LPCXpresso project build error and it’s solutions. 2.2.1 LPCXpresso project problem reproduction Open LPCXpresso project, and build it, you may find these problems: All the errors are C/C++ Problem. 2.2.2 LPCXpresso project problem solution Choose project->properties, change the language standard to GNU C90 stand like this: Click button “ Apply”, then rebuild it again, you will find the error is disappeared: Of course, you also can change the lib to the newest one, just like the method in the KEIL project, use the newest LPCXpresso emWin lib from this folder: NXP_emWin530\emWin_library\LPCXpresso\libemWin_M3.a 2.3 Code function problem in some MCB1700 board This part is mainly taking about the function problem in some MCB1700 boards, give the analysis and the according solutions. 2.3.1 Code function problem reproduction After the build problem is solved, customer can download the code to the MCB1700 board by debugger or programmer, no matter with LPC1758, LPC1768 or LPC1769. After testing some MCB1700 boards, we found some board always display white, the emwin function doesn’t work, but some board can display the correct picture. All these boards seems the same. I have compared these boards carefully, I found the series number in the LCD have difference, now I list it as follows: MCB LCD Series number RESULT MCB1758 A774A-43-P101210-4072 OK MCB1758 A774A-61-P120814-4074 Abnormal, LCD display white MCB1769 A774A-22-P120814-4074 Abnormal, LCD display white MCB1769 A774A-57-P120814-4074 Abnormal, LCD display white From the above form, we can find all the MCB boards which can’t work have one feature: the LCD series number contains P120814, so it should be related to the LCD controller, but what the controller on these MCB1700 boards? After download the LCD_Blinky code from the KEIL IDE install path: C:\Keil_v5\ARM\Boards\Keil\MCB1700\LCD_Blinky I found this project can display the picture correctly, so I do the debugging and the source code checking, after that I get the LCD with P120814 is using the HX8347-D LCD controller which from Himax company. But the LCD diver code in emWin MCB1700 BSP is for SPFD5408 LCD controller. 2.3.2 Code function problem solutions Here take MDK project as an example, describe how to modify the emWin_MCB1700_BSP code and make it work in those not working MCB1700 boards. After the analysis in the above chapter, you will get that the main problem is caused by the LCD driver, so the code modification is mainly about the LCDConf.c file, this code in this file is for the LCD driver configuration. 2.3.2.1 Modify the display orientation Comment the old DISPLAY_ORIENTATION definition, and define it like this: //#define DISPLAY_ORIENTATION (GUI_SWAP_XY) #define DISPLAY_ORIENTATION (GUI_MIRROR_X | GUI_SWAP_XY) 2.3.2.2 Modify the LCD controller initialization code From chapter 2.3.1, we can get the LCD on the not working MCB1700 board is HX8347-D, the HX8347 LCD controller initialization code should be modified like this: static void _InitController(void) { #ifndef WIN32 GUI_X_Delay(10); LCD_X_SPI_Init(); GUI_X_Delay(10); /* Driving ability settings ------------------------------------*/ wr_reg(0xEA, 0x00); /* Power control internal used (1) */ wr_reg(0xEB, 0x20); /* Power control internal used (2) */ wr_reg(0xEC, 0x0C); /* Source control internal used (1) */ wr_reg(0xED, 0xC7); /* Source control internal used (2) */ wr_reg(0xE8, 0x38); /* Source output period Normal mode */ wr_reg(0xE9, 0x10); /* Source output period Idle mode */ wr_reg(0xF1, 0x01); /* RGB 18-bit interface ;0x0110 */ wr_reg(0xF2, 0x10); /* Adjust the Gamma Curve --------------------------------------*/ wr_reg(0x40, 0x01); wr_reg(0x41, 0x00); wr_reg(0x42, 0x00); wr_reg(0x43, 0x10); wr_reg(0x44, 0x0E); wr_reg(0x45, 0x24); wr_reg(0x46, 0x04); wr_reg(0x47, 0x50); wr_reg(0x48, 0x02); wr_reg(0x49, 0x13); wr_reg(0x4A, 0x19); wr_reg(0x4B, 0x19); wr_reg(0x4C, 0x16); wr_reg(0x50, 0x1B); wr_reg(0x51, 0x31); wr_reg(0x52, 0x2F); wr_reg(0x53, 0x3F); wr_reg(0x54, 0x3F); wr_reg(0x55, 0x3E); wr_reg(0x56, 0x2F); wr_reg(0x57, 0x7B); wr_reg(0x58, 0x09); wr_reg(0x59, 0x06); wr_reg(0x5A, 0x06); wr_reg(0x5B, 0x0C); wr_reg(0x5C, 0x1D); wr_reg(0x5D, 0xCC); /* Power voltage setting ---------------------------------------*/ wr_reg(0x1B, 0x1B); wr_reg(0x1A, 0x01); wr_reg(0x24, 0x2F); wr_reg(0x25, 0x57); wr_reg(0x23, 0x88); /* Power on setting --------------------------------------------*/ wr_reg(0x18, 0x36); /* Internal oscillator frequency adj */ wr_reg(0x19, 0x01); /* Enable internal oscillator */ wr_reg(0x01, 0x00); /* Normal mode, no scrool */ wr_reg(0x1F, 0x88); /* Power control 6 - DDVDH Off */ GUI_X_Delay(200); wr_reg(0x1F, 0x82); /* Power control 6 - Step-up: 3 x VCI */ GUI_X_Delay(50); wr_reg(0x1F, 0x92); /* Power control 6 - Step-up: On */ GUI_X_Delay(50); wr_reg(0x1F, 0xD2); /* Power control 6 - VCOML active */ GUI_X_Delay(50); /* Color selection ---------------------------------------------*/ wr_reg(0x17, 0x55); /* RGB, System interface: 16 Bit/Pixel*/ wr_reg(0x00, 0x00); /* Scrolling off, no standby */ /* Interface config --------------------------------------------*/ wr_reg(0x2F, 0x11); /* LCD Drive: 1-line inversion */ wr_reg(0x31, 0x00); wr_reg(0x32, 0x00); /* DPL=0, HSPL=0, VSPL=0, EPL=0 */ /* Display on setting ------------------------------------------*/ wr_reg(0x28, 0x38); /* PT(0,0) active, VGL/VGL */ GUI_X_Delay(200); wr_reg(0x28, 0x3C); /* Display active, VGL/VGL */ // wr_reg(0x16, 0x00); /* Mem Access Control (MX/Y/V/L,BGR) */ /* Display scrolling settings ----------------------------------*/ wr_reg(0x0E, 0x00); /* TFA MSB */ wr_reg(0x0F, 0x00); /* TFA LSB */ wr_reg(0x10, 320 >> 8); /* VSA MSB */ wr_reg(0x11, 320 & 0xFF); /* VSA LSB */ wr_reg(0x12, 0x00); /* BFA MSB */ wr_reg(0x13, 0x00); /* BFA LSB */ #endif } 2.3.2.3 Modify the LCD_X_Config configuration From the emWin display drivers website in the Segger: https://www.segger.com/emwin-display-drivers.html You can find the HX8347 display driver is GUIDRV_FlexColor, the parameter pfFunc in function GUIDRV_FlexColor_SetFunc is GUIDRV_FLEXCOLOR_F66712. So, modify GUIDRV_FlexColor_SetFunc in the LCD_X_Config function like this: GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66712, GUIDRV_FLEXCOLOR_M16C0B16); After the modification, then save and rebuild it. At last, download the code to the MCB1700 board which was not working before, download the code to the board, press the RESET button on the board, you will find the LCD displays the GRAPH_DATA_XY demo picture like this: 2.3.3 Other applications testing After the above code modification for the not working MCB1700 board, if you have interest, you also can try the other application to display other pictures. In folder NXP_emWin514_MCB1700_BSP\Application, there still has a lot of other applications, you just need to add it to the application folder in the project, then the LCD can display the according picture, now list some application’s testing result. 2.3.3.1 GUI_WIDGET_GraphYtDemo.c 2.3.3.2 GUI_HelloWorld.c 2.3.3.3 GUI_ALPHA_TransparentDialogDemo.c 2.3.3.4 WM_RadialMenu.c 3 Conclusion From the above detail descriptions, you will know emWin_MCB1700_bsp KEIL project build error can be fixed by changing the lib to the newest emwin lib, LPCXpresso project build error can be fixed by changing the language standard to GNU C90, the function problem in some MCB1700 is mainly caused by the mismatch LCD driver, just modify the code to the according LCD driver can fix the LCD display white problem. Wish this document can help those customers who are using the emWin_MCB1700_bsp on the MCB1700 board, the modified project also in the attachment for your reference.

MCUXpresso Config Tools is now available! You can access it on the following link: Welcome to MCUXpresso | MCUXpresso Config Tools Overview. MCUXpresso Config Tools provides a set of system configuration tools that help users of all levels with a Kinetis or LPC-based MCU solution. Let it be your guide from first evaluation to production development. High Quality, Comprehensive Enablement - Production-grade, rigorously tested software and tools. - Easy-to-use SDK, IDE and configuration tools. Compatibility Across MCUs - Supports Kinetis, LPC Cortex-M. - Easy migration and scalability between MCUs. Note: i.MX Cortex-M device support coming in 2017 Interoperability Across Tools - Common experience and broader support through fewer, more cohesive software and tools. - Seamless development using SDK, IDE and Config tools together. - SDK and configuration tools also support the large ecosystem of NXP’s partner IDEs. Features. Architecture - CMSIS-CORE compatible - Single driver for each peripheral - Transactional APIs w/ optional DMA support for communication peripherals Integrated RTOS - FreeRTOS, µC/OS-II & -III - RTOS-native driver wrappers Integrated Stacks and Middleware - USB Host, Device and OTG - lwIP, FatFS - Crypto acceleration plus wolfSSL & mbedTLS - SD and eMMC card support Reference Software - Peripheral driver usage examples - Application demos - FreeRTOS usage demos License - BSD 3-clause for startup, drivers, USB stack Toolchains - IAR®, ARM® Keil®, GCC w/ Cmake - + MCUXpresso IDE Quality - Production-grade software - MISRA 2004 compliance - Checked with Coverity® static analysis tools Configuration and development tools. SDK Builder packages custom SDKs based on user selections of MCU, evaluation board, and optional software components. Pins, Clocks, and Peripheral(1) tools generate initialization C code for custom board support. Project Generator(1) creates new SDK projects or clones existing ones. Power Estimation tool provides energy and battery-life estimates based on a user’s application model Power Analyzer(1) measures and displays energy consumption data. (1)Coming 2017 Related links: Introducing MCUXpresso SDK v.2 for LPC54xxx Series Generating a downloadable MCUXpresso SDK v.2 package How to start with SDK v.2.0 for LPC5411x using LPCXpresso IDE https://community.nxp.com/docs/DOC-333369

Writing this post just want to remind the customer of RAM allocation when use the on-chip CAN drivers in LPC11C24. Otherwise, when meet the abnormal issues, it is difficult to locate the root reason and it also causes a waste of time. Now, take a real customer question as an example, to highlight the RAM allocation importance when using the on-chip CAN API in LPC11C24. Problem description Customer used the LPC11C24 on-chip CAN API to realize the CAN frames sending and receiving, the CAN code was from the official lpcopen, and it worked OK when he just used the CAN code. But when customer added the UART code, they found the code always enter hardfault after a short time running. They test the UART code which without the CAN code directly, the UART code worked perfectly. It means, independent UART code and independent CAN code are all working normally, but when combine the UART and on-chip CAN code together, the code will enter hardfault. Problem analysis From the Cortex M0 devices generic user guide, we can get the information about the hard fault: Faults are a subset of exceptions, see Exception model. All faults result in the HardFault exception being taken or cause lockup if they occur in the NMI or HardFault handler. The faults are: execution of an SVC instruction at a priority equal or higher than SVCall execution of a BKPT instruction without a debugger attached a system-generated bus error on a load or store execution of an instruction from an XN memory address execution of an instruction from a location for which the system generates a bus fault a system-generated bus error on a vector fetch execution of an Undefined instruction execution of an instruction when not in Thumb-State as a result of the T-bit being previously cleared to 0 an attempted load or store to an unaligned address Now we debug the problem project to check, which detail code line caused this hardfault problem. When the code enters the hardfault handler, check the MSP address in the flash, then find the LR register, which will link to the code before entering in the hardfault handler, the following are the according debug result: The LR register is 0X1FFF2C1F, it means before enter in hardfault handler, the code runs to this address code. Now, check the 0X1FFF2C1F in the memory map. We can find the address is in the ROM area, because we just use the ROM CAN driver, UART is just the pure register control code, then we can get the problem still relate to the on-chip CAN driver, not the UART code. But we can’t see or debug the detail ROM CAN driver directly, we still can’t find the root problem. Even we know the problem is not caused by the UART, but another important clue which relates to the UART function also influence the test result after I do a lot of testing. In the customer code, he defines the UART user transmit and receive buffer like this: #define UART_SRB_SIZE 128 // Send #define UART_RRB_SIZE 32 // Receive /* Transmit and receive buffers */ static uint8_t rxbuff[UART_RRB_SIZE], txbuff[UART_SRB_SIZE]; On one occasion, I tried changing #define UART_SRB_SIZE 128 To #define UART_SRB_SIZE 32 Just minimize the txbuff size, I found the code won’t enter in the hardfault handler any more. It seems very strange and contradiction with the hardfault handler enter point which is test before. I also check the generated code size, the used RAM and flash size is: text data bss dec hex filename 7672 0 244 7916 1eec pscan.axf LPC11C24 RAM is 8K, here just 244 Bytes, the stack also use the whole RAM, so the 8K RAM size should be enough to use. In this situation, I check the project’s .map file about the txbuff with 128 and 32 respectively. 1)txbuff with 128Bytes Rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X100000E8. 2)txbuff with 32Bytes Rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X10000088. We can find the txbuff start address is the same, just the end address has difference. With these information, we checked the LPC11C24 user manual chapter C_CAN on-chip drivers again, we found a significant description: 0X10000050 to 0X100000B8 is used by the on-chip CAN API RAM, and from the issue project, memory map file, we can find rxbuff and txbuff RAM address is 0X10000048 to 0X100000E8, it already occupies the whole CAN API RAM, this is the key point. Minimize the txbuff, then rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X10000088, this address doesn’t occupy the whole on chip CAN API RAM, in this situation, the problem doesn’t happen, I think the used CAN API may in the RAM address 0X10000089-0X100000B8. Anyway, just minimize the buffer size can’t solve the problem from the root side. We must follow the user manual to keep the RAM address from 0x10000050 to 0x100000b8 won’t be used by any other application code. Problem solutions From the above chapter, we can find the root problem is the application code occupies the on-chip CAN RAM, to solve the problem, we need to modify the linker file, to prevent the usage of on-chip CAN RAM range. Because the customer is using the LPCXPresso IDE, then we take this IDE as an example, to protect the RAM address 0x10000050 to 0x100000b8. From the above, we can get that the LPCX11C24 have 8Kbytes RAM, normally, customer will define it just in one, now we divide the RAM to two pieces. 1) RAM2: Location 0X10000000, size 0X100 2) RAM: Location 0X10000100, size 0X1F00 In the LPCXpresso, Project Properties -> C/C++ Build -> MCU settings, then modify it like this: Then generate the code, and check the map file again. RAM address from 0x10000000 to 0X10000FF is not used by any other application code. All the application code RAM is using from address 0x10000100. After long time testing, we find the hardfault problem never happens, on customer side, it also works OK. In conclusion, when customer want to use the on-chip CAN API, they need to protect the RAM address from 0x10000050 to 0x100000b8 in the linker file.

This content was originally contributed to lpcware.com by Steve Sabram This example project implements acoustic range, finite infinite response (FIR) filters using the LPC4350 demo board and the ARM CMSIS DSP library. A sound resource of a science fiction “zap gun” plays out the headphone jack of the demo board. This sound sample is great for demonstration since it has many low-, mid-, and high-frequency components along the acoustical band. You play the sound resource by touching the capacitive touch buttons on the demo board as explained by the menu shown on the demo board’s LCD. It is best to listen to the sound with a headphone or ear buds. Each of the four buttons plays the same sound resource differently: 1) Raw – The unprocessed sound plays according to its format (sample rate of 44.1 kHz, 16-bit sample and mono sound). 2) Low Pass – filtered through a low pass, Butterworth filter with a cutoff of 5 kHz, similar to the bandwidth of a common analog telephone. When played, notice that high pitch components are removed similar to the sound heard over a telephone. 3) High Pass – filtered through a high pass, Butterworth filter with a low frequency cutoff of 8 kHz. Notice that the sound is lower in volume since only the upper harmonic components are played. 4) Backward Mask – The sound resource sample plays in reverse order. The “Zap!” is now a “Zoup!” The digital filters were designed with a favorite public domain tool, WinFilter (http://www.winfilter.20m.com/) accompanying this example. With exposure of this free DSP design tool via NXP, I hope its author expands its features.

The power measurement board includes eight measurement channels which support for eight programmable gain amplifiers(LTC6915) and two ADC converters(AD7175). The measurement board measures the voltage drop across sampling resistor, and send to the ADC after the voltage drop is processed by amplifier and make it available via SPI. Microcontroller LPC55S69 collects the data from the measurement circuit and send it to the host computer via USB VCOM port. The MCU can control the gain value of programmable gain amplifiers by SPI when different power circuit are measured. The host computer connects to the power measurement board through the USB virtual serial port, the MCU initializes and configures the measurement unit by SPI, and starts to measure the inside current and monitor the voltage. MCU adjust the gain parameter and then transmit current and voltage data to MCU by SPI, then MCU transmits the data to the host computer for processing and display through the virtual serial port. The voltage drop of the measured circuit to be measured is firstly amplified by the programmable amplifier LTC6915, and MCU monitor the state which whether the data is abnormal at the same time. R0 is the sampling resistor, LTC6915 is a selectable programmable amplifier, the gain can be set to 14 kinds, PGA gain parameter is adjusted when the current changes. ADC7175 is the 24-bit high-precision ADC, which is more advantageous in the application of small current measurement. When the MCU switches the low power mode to the normal mode, and the LTC6915 will reduce the gain value by SPI. The power measurement board provides easy connection method by two-wires cable. For example, the MIMXRT1180EVK and MIMXRT1020EVK are connected with power measurement board. The USB virtual COM is used for data transfer, and display by PMT(power management tool) or other PC GUI, the measurement power data include current, voltage and power. There are more detailed descriptions in the attachment.

INTRODUCTION The goal of this example is to demonstrate basic LIN communication between two devices where one active as Master another as Slave. In this case, the two devices used are LPC55S16 EVK's. LIN master will send a specific publisher frame and a subscriber frame, the LIN slave will detect the master data and feedback the data accordingly. This article will mainly focus on the software side, for hardware please refer https://community.nxp.com/t5/LPC-Microcontrollers-Knowledge/LPC54608-LIN-master-basic-usage-sharing/ta-p/1118103. LIN MASTER EXAMPLE LIN master sends the LIN publisher data and the subscriber ID data, the software code is modified from the SDK_2.8.2_LPCXpresso55S16 usart_interrupt_rb_transfer project, the detailed code is as follows: /* USART callback */ void FLEXCOMM3_IRQHandler() { if(DEMO_USART->STAT & USART_STAT_RXBRK_MASK) // detect LIN break { Lin_BKflag = 1; cnt = 0; state = RECV_DATA; DisableLinBreak; } if((kUSART_RxFifoNotEmptyFlag | kUSART_RxError) & USART_GetStatusFlags(DEMO_USART)) { USART_ClearStatusFlags(DEMO_USART,kUSART_TxError | kUSART_RxError); rxbuff[cnt] = USART_ReadByte(DEMO_USART);; switch(state) { case RECV_SYN: if(0x55 == rxbuff[cnt]) { state = RECV_PID; } else { state = IDLE; DisableLinBreak; } break; case RECV_PID: if(0xAD == rxbuff[cnt]) { state = SEND_DATA; } else if(0XEC == rxbuff[cnt]) { state = RECV_DATA; } else { state = IDLE; DisableLinBreak; } break; case RECV_DATA: Sub_rxbuff[recdatacnt++]= rxbuff[cnt]; if(recdatacnt >= 3) // 2 Bytes data + 1 Bytes checksum { recdatacnt=0; state = RECV_SYN; EnableLinBreak; } break; case SEND_DATA: recdatacnt++; if(recdatacnt >= 4) // 2 Bytes data + 1 Bytes checksum { recdatacnt=0; state = RECV_SYN; EnableLinBreak; } break; default:break; } cnt++; } /* Add for ARM errata 838869, affects Cortex-M4, Cortex-M4F Store immediate overlapping exception return operation might vector to incorrect interrupt */ #if defined __CORTEX_M && (__CORTEX_M == 4U) __DSB(); #endif } void Lin_Master_Publisher(void) { unsigned int i=0; unsigned char ch =0xa0;//dummy byte //===============================LIN master send===================== DEMO_USART->CTL |= USART_CTL_TXBRKEN_MASK;//enable TX break; while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteBlocking(DEMO_USART,&ch,1);//dummy data break; //just send one byte, otherwise, will send 16 bytes } DEMO_USART->CTL &= ~(USART_CTL_TXBRKEN_MASK); //disable TX break // Send the sync byte 0x55. while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X55); break; //just send one byte, otherwise, will send 16 bytes } //protected ID while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0Xad); break; //just send one byte, otherwise, will send 16 bytes } //Data1 while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X01); break; //just send one byte, otherwise, will send 16 bytes } //Data2 while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X02); break; //just send one byte, otherwise, will send 16 bytes } //Data3 while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X03); break; //just send one byte, otherwise, will send 16 bytes } // checksum byte while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X4c);//0X4c break; //just send one byte, otherwise, will send 16 bytes } } void Lin_Master_Subscribe(void) { unsigned int i=0; unsigned char ch=0xf0;//dummy byte DEMO_USART->CTL |= USART_CTL_TXBRKEN_MASK;//enable TX break; while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteBlocking(DEMO_USART,&ch,1); break; //just send one byte, otherwise, will send 16 bytes } DEMO_USART->CTL &= ~(USART_CTL_TXBRKEN_MASK); //disable TX break // Send the syncy byte 0x55. while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X55); break; //just send one byte, otherwise, will send 16 bytes } //protected ID while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X3C); break; //just send one byte, otherwise, will send 16 bytes } state = RECV_DATA; } The main task here was to generate and detect the LIN break field. If one look closely, to generate the LIN break field in publisher and subscriber frame, we first set the Tx break and then send a dummy byte and then disable the Tx break. The function used to send the dummy byte is USART_WriteBlocking whereas USART_WriteByte is used to send data other than dummy byte. This is because if we use USART_WriteByte during dummy byte then it was not a continuous low as in the other case. I still need to find the reason for this, will update here once done. LIN SLAVE EXAMPLE LIN Slave receives the LIN publisher data and the subscriber ID data from Master and respond back id required, the software code is modified from the SDK_2.8.2_LPCXpresso55S16 usart_interrupt_rb_transfer project, the detailed code is as follows: void FLEXCOMM3_IRQHandler() { if(DEMO_USART->STAT & USART_STAT_RXBRK_MASK) // detect LIN break { Lin_BKflag = 1; cnt = 0; state = RECV_SYN; DisableLinBreak; } if((kUSART_RxFifoNotEmptyFlag | kUSART_RxError) & USART_GetStatusFlags(DEMO_USART)) { USART_ClearStatusFlags(DEMO_USART,kUSART_TxError | kUSART_RxError); rxbuff[cnt] = USART_ReadByte(DEMO_USART);; switch(state) { case RECV_SYN: if(0x55 == rxbuff[cnt]) { state = RECV_PID; } else { state = IDLE; DisableLinBreak; } break; case RECV_PID: if(0xAD == rxbuff[cnt]) { state = RECV_DATA; } else if(0X3C == rxbuff[cnt]) { state = SEND_DATA; senddata(); } else { state = IDLE; DisableLinBreak; } break; case RECV_DATA: recdatacnt++; if(recdatacnt >= 4) // 3 Bytes data + 1 Bytes checksum { recdatacnt=0; state = RECV_SYN; EnableLinBreak; } break; default:break; } cnt++; } /* Add for ARM errata 838869, affects Cortex-M4, Cortex-M4F Store immediate overlapping exception return operation might vector to incorrect interrupt */ #if defined __CORTEX_M && (__CORTEX_M == 4U) __DSB(); #endif } void senddata(void) { { while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X01); break; //just send one byte, otherwise, will send 16 bytes } while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X02); break; //just send one byte, otherwise, will send 16 bytes } while (kUSART_TxFifoNotFullFlag & USART_GetStatusFlags(DEMO_USART)) { USART_WriteByte(DEMO_USART, 0X10);// 0X10 correct 0Xaa wrong break; //just send one byte, otherwise, will send 16 bytes } recdatacnt=0; state = RECV_SYN; EnableLinBreak; } } Attaching herewith the codes of the Master and Slave. I hope it helps!!

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!

特集記事

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; }

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

LPC Microcontrollers Knowledge Base

ディスカッション

Useful LPC documents and questions

ECG Application Example using LPC4370 and LabTool Hardware

SCTimer implement traffic signal

LPC54608 LIN master basic usage sharing

LPC key feature_DualCore

example to use ARM TX Event to trigger ADC

LPC8N04: NFC Hands-on Lab Guide

Telephone answering machine design example

Audio player design example

[LPC] Why My Low Power Current Is Different From Manual Spec?

Code issue solutions in emWin_mcb1700_bsp

LPC key feature_SCT

MCUXpresso Config Tools is now available!

LPC key feature_SPIFI

LPC11C24 on chip CAN API should pay attention to RAM allocation

TN005_Heat LPC11U68 and reset it will enter hardfault.docx

FIR filter suite

Wide range automatic adjusting power measurement solution for MCU based on LPC55S69

LPC55S16 LIN basic usage example

How to start with SDK v.2.0 for LPC5411x using LPCXpresso IDE

LPC55S6x/S2x/S1x/S0x Vendor Usage Errata Update