Do you want to know more about one of our hottest products in the LPC800 series portfolio? Take a look at this technical presentation featuring the LPC84x MCU family. Based on the Arm Cortex-M0+ core, the LPC84x Family of MCUs is a low-cost, 32-bit MCU operating at frequencies of up to 30 MHz. The LPC84x MCU family supports of up to 64 KB of flash memory and 16 KB of SRAM. In addition, to make things easier, the LPC800 series McUs are supported by our free example code bundles and now, they're also supported by the MCUXpresso Software Develpment Kit (SDK).  Fig 1. LPC84x MCU Family Block Diagram

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 

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 &amp; emWin Graphics;  Capacitive Touch example using the LPC845 Breakout Board  OLED Display Application Example using LPC845 Breakout Board and SPI  Mixed-Signal Logic Analyzer &amp; 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? 

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!  

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

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.

#lpc‌ #dualcore‌ #feature‌ Attached doc is the LPC MCU Serial dual core feature introduction and application

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

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

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.

lpc‌ feature‌ sct‌ Attached doc is the LPC MCU Serial SCT feature introduction and application Contents Timer/State machine basics SCT introduction SCT availability SCT tools & resources SCT application analysis

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.

lpc‌ feature‌ spifi‌ Attached doc is the LPC MCU Serial SPIFI feature introduction and application Topics • SPIFI introduction • SPIFI performance • SPIFI debug • SPIFI library • Introduction to SPIFI flash content protection

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.    

经常有客户在使用LPC55S69的过程中遇到读 Flash进入异常HardFault中断的现象。如果在Flash Mass Erase之后从未对Flash扇区进行过写操作，直接用指针通过AHB读Flash地址会导致程序跳入HardFault 中断而无法继续正常运行。 原因    刚出厂的LPC55Sxx FLASH处于全零的全擦除状态，没有设置ECC。当芯片通过LinkServer 和MCUXpresso IDE建立连接时，先擦除要下载代码用到的扇区，再把代码下载到对应位置，并对相应存储区的ECC值同时进行更新。代码以外的区域仍然是无ECC设置的擦除状态。 当LPC55Sxx 通过AHB总线直接读取Flash内存区域时（例如，mytemp = *(uint32_t*)0x4000）要对Flash ECC进行校验。这一指令对于读有效代码区是没有问题的， 因为这一区域的ECC在下载代码时早已设置好。但是一旦读取没有代码的扇区，由于没有检测到正确的ECC，导致Flash读取失败，并跳转到下图中的HardFault_Handler()异常中断：   我们在Sector Erase后通过AHB读取Flash内存内容，也会遇到同样的HardFault异常跳转，出问题的原因都是一样的。 解决方法 针对这一问题我们有如下两种解决方法： 先执行Flash写操作，再读取Flash 与Flash 擦除操作不同，执行Flash写操作后对应的ECC值也同步更新。这样，ECC校验通过后，通过下面的代码就可以对Flash直接进行AHB读取。 volatile uint32_t mytemp; …… mytemp = *(uint32_t*)0x1000;//read memory content 0x1000 to mytemp 请注意：0x1000必须是一个已经写过的地址。 如果Flash的某个扇区处于被擦除的状态，我们只需要在通过AHB总线读取内存区域之前对该区域执行写操作，这样ECC校验位更新正确后，就可以正常读Flash。 Flash的写操作可以参考MCUXpresso SDK自带的flashiap例程，函数FLASH_Program。   使用Flash控制指令读取Flash区内容 使用Flash控制指令进行读操作不会导致硬件错误（请参阅UM11126 “Command listing (CMD)”章节）。这是用户手册中推荐的读Flash正确打开方式。 请注意：CPU只有在频率低于100MHz时，才能进行Flash操作（读，写，擦除，校验，等等），当CPU频率超过100MHz时是不能实现上述操作的。 目前，官方没有提供上用控制指令读取Flash内容的例程，因此需要您根据下面步骤创建自己的读Flash程序。 开发环境： IDE: MCUXpresso IDE v11.1.0 SDK MCUXpresso SDK v2.7.0 步骤： 在MCUXpresso IDE中导入一个基础例程，如led_blinky 在下图所述选项中添加iap组件   选择iap1,点击OK   点击完OK之后，fsl_iap_ffr.h, fsl_iap.c, fsl_iap.h文件将自动添加到工程中   在source文件夹中添加附件中的memory.h和memory.c文件   4) 使用Flash 控制指令时，需要在源文件中添加memory.h, fsl_iap.h   5) 调用memory初始化和memory读取函数   6）调试，单步执行（step over）到memory_read()，查看结果  

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

  需求： 客户需要对Image文件做出完整性检测，利用IDE固有功能添加这类信息简便且可靠，以往有类似的link提到了这些配置，对于LPC55系列，需要做一些更新。 CRC Checksum Generation with MCUXpresso IDE - NXP Community Solution 基于MCUX环境 下载 SRecord http://srecord.sourceforge.net/ srec_cat.exe是下载后我们主要使用的工具，通过为其添加一个系统变量名，将SRecord目录加入系统路径     重启MCUX IDE之后可以在工程配置中看到该变量：       创建一个脚本文件crc_add.txt，放在debug目录下，用于填充app后的flash空余位置为0xFF, 并后续生成CRC32值并放置0x00037FFC位置。最终生成的srec文件为包含所有内容的image。           # srec_cat command file to add the CRC and produce application file to be flashed # Usage: srec_cat @filename #first: create CRC checksum lpcxpresso55s06_hello_world_image_length_MCUX.srec # input file #-fill 0xFF 0x00000000 0x00038000 # fill blank code area with 0xff from 0x00000000 to 0x00038000 (0x00038000是把LPC55S06的末尾地址稍往前提，实际因为0x0003D7FF） -fill 0xFF 0x00000000 0x00037FFC #填充0-0x37FFC区间的未用地址为0xff -crop 0x00000000 0x00037FFC # just keep code area for CRC calculation below , 保留这段区间的内容，排除除此范围内的其他数据 #-CRC16_Big_Endian 0x00037FFE -CCITT # calculate big endian CCITT CRC16 at given address.， 为以上空间数据计算CRC16，并放置在0x00037FFE地址，2字节 -CRC32_Little_Endian 0x00037FFC -CCITT #CRC32 -crop 0x00037FFC 0x00038000 # keep the CRC itself #second: add application file lpcxpresso55s06_hello_world_image_length_MCUX.srec # input file -fill 0xFF 0x00000000 0x00037FFC # fill code area with 0xff -crop 0x00000000 0x00037FFC #-crop 0x10000000 0x10000170 0x10000172 0x10010000 #keep all except CRC #finally, produce the output file -Output # produce output lpcxpresso55s06_hello_world_image_length_MCUX_crc.srec      创建一个crc_file_convert.txt文件，也放在debug目录下，用于将上一步生成的最终image的srec文件转换为bin文件，用于生成或者比对 # srec_cat command file to add the CRC and produce application file to be flashed # Usage: srec_cat @filename #third: create bin file lpcxpresso55s06_hello_world_image_length_MCUX_crc.srec -o lpcxpresso55s06_hello_world_image_length_MCUX_crc.bin -binary 在IDE的Post build栏目添加如下命令：     arm-none-eabi-size "${BuildArtifactFileName}"   默认自带的统计image size功能 arm-none-eabi-objcopy -v -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin"    将image转成bin文件，用于后续使用和比对 arm-none-eabi-objcopy -v -O srec "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.srec" & srec_cat.exe @CRC_add.txt 填充image，计算CRC32，整合成新的srec image srec_cat.exe @CRC_file_convert.txt  将上一步得到的srec image转化为bin文件，用于后续使用和比对   《hello_world_image_length_MCUX》例程会自行统计应用程序的CRC32值，并于IDE产生的CRC32值做比对   这里需要注意的是，由于MCUX IDE是借助于外部工具来填充flash和计算CRC32，所以默认IDE调试和下载选择afx文件并不包含这些信息。当校验程序开始运行，会发生： 读写未写入的flash，对于LPC55系列会发生hardfault CRC32值并不存在 所以测试这个程序需要单独下载包含所有的srec文件或者bin文件，而不是默认的afx文件。