LPC Microcontrollers Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC Microcontrollers Knowledge Base

Discussions

Sort by:
Contents 1. Introduction 1 2. USB Demo based on MCUXpresso SDK 1     2.1 Update USB device demo: USB0->USB1 2     2.2 Update USB host demo: USB0->USB1 2     2.3 Update USB ROM demo: USB0-> USB1 3 3. USB Demo based on LPCOpen 3 4. Notes and Recap 4  1.     Introduction Most of LPC devices integrate USB module. NXP LPC currently integrates full-speed USB (FS, Full Speed, 12Mbps) and high-speed (HS, High Speed, 480Mbps) USB. Specifically, for the LPC series: - Some LPCs such as LPC55xx and LPC54xxx integrate both HS USB and FS USB. Usually USB0 is FS USB and USB1 is HS USB. - Some LPCs such as LPC43xx and LPC18xx integrate two HS USBs, so USB0 and USB1 are both HS USBs. The two most well-known NXP software packages for LPC series are MCUXpresso SDK and LPCOpen. MCUXpresso SDK is mainly for LPC products launched in recent years, while LPCOpen is used for earlier LPC derivatives. The USB demos included in these two packages run on USB0 by default. Most of NXP USB demos are for USB0 by default. This article is to introduce how to switch a USB0 demo to USB1 demo based on different software packages. 2.     USB Demo based on MCUXpresso SDK (e.g. LPC54XXX, LPC55XX) The MCUXpresso SDK USB demo codes are categorized as: - USB as Device: e.g. usb_device_cdc_vcom, usb_device_hid_generic, etc. - USB as Host: e.g. usb_host_hid_mouse, usb_host_msd_fatfs, etc. - USB demo based on USB ROM API: e.g. usb_rom_device_audio,usb_rom_device_cdc, etc. 2.1  Update USB device demo: USB0->USB1 Taking usb_device_cdc_vcom demo as an example. To switch to USB1, simply change the corresponding code in usb_device_config.h file as follows. /*! @brief LPC USB IP3511 FS instance count*/ #define USB_DEVICE_CONFIG_LPCIP3511FS (0U) /*! @brief LPC USB IP3511 HS instance count*/ #define USB_DEVICE_CONFIG_LPCIP3511HS (1U) After the change, recompile the program to run. The program was updated to USB1 device demo. 2.2   Update USB host demo: USB0->USB1 Taking usb_host_hid_mouse demo code as an example, to switch to USB1, modify the macro definition in usb_host_config.h as follows: #defineUSB_HOST_CONFIG_KHCI (0U) #defineUSB_HOST_CONFIG_EHCI (0U) #define USB_HOST_CONFIG_OHCI (0U) #define USB_HOST_CONFIG_IP3516HS (1U)   The program is recompiled and run. The program was updated to USB1 host demo. 2.3  Update USB ROM demo: USB0-> USB1 ( e.g. LPC54XXX Series) USB ROM demo calls the USB ROM API, there is no way to switch the default USB0 to USB1 by modifying macro definitions. In order to update code to USB1 demo, the recommended steps are as below: -USB HS DEVICE and USB PHY clock configuration -Change to use USB HS ISR -Locate the related buffer into USB RAM. -Set the USB ROM handle to be HS If user has difficulties in revising the code by self, user can apply demo code from NXP LPC online support team by creating a private case. 3.     USB Demo based on LPCOpen (e.g. LPC43XX, LPC18XX) Some legacy LPCs run on LPCOpen, such as LPC43xx series, LPC18xx series. Their USB0 and USB1 are both high-speed. The default USB demo is for USB0 as well. To switch to USB1, we can uncomment #define USE_USB1 and comment #define USE_USB0 in app_usbd_cfg.h. // #define USE_USB0  #define USE_USB1 Taking usbd_rom_cdc_uart demo as an example:   Recompile and run, the program is updated to USB1 demo. 4.     Notes and Recap The focus of this article is on software modification of converting USB0 to USB1 on NXP SW package. Regarding the hardware, customer needs to check the specific demo board user guide. For example, when we use HS USB, it may be necessary to provide an external power supply, and the jumper also needs to be adjusted to build a well hardware environment for HS USB operation. I will not dwell on them here. This article summarizes methods of switching USB0 to USB1 for several commonly used LPC series on MCUXpresso SDK and LPCOpen package. customers who need USB1 demo code can find the corresponding modification methods in this article for their own software and chips. Official routines are only used for demo board demos and chip learning. If for commercial usage, user needs to learn USB in depth and be responsible for own application.  
View full article
Overview          Ping-pong is a special case of a linked transfer which typically used more frequently than more complicated versions of linked transfers. A ping-pong transfer usually uses at least two buffers. At any one time, one buffer is being loaded or unloaded by DMA operations. The other buffers have the opposite operation being handled by software, readying the buffer for use when the buffer currently being used by the DMA controller is full or empty. The Fig 1 illustrates an example of descriptors for ping-pong from a peripheral to two buffers in memory. Fig 1 Implementation detail         To continuous transfer the converted result of the ADC to RAM, I’m going to use four 4 DMA descriptors to work in Ping-Pong mode to achieve this goal as the Fig 2 shows. Fig 2 Data flow via Ping-Pong mode Hardware introduction         LPCXpressor54114 Board(OM13089) Fig 3 LPCXpressor54114 Board        Demo code: LPCOpen Library Example code        The code is based on the periph_adc demo, using the SCTimer output as the hardware trigger of ADC, meanwhile, the ADC converted value is transferred to the appointed area of RAM automatically. #include "board.h" #define SCT_PWM            LPC_SCT #define NUM_BUFFERS 4 #define DMA_TRANSFER_SIZE 8 #define ADC_INPUT_CHANNEL 1 #define SCT_PWM_RATE   10000          /* PWM frequency 10 KHz */ #define SCT_PWM_PIN_OUT    7          /* COUT7 Generate square wave */ #define SCT_PWM_OUT        1          /* Index of OUT PWM */ uint16_t adcOut; ALIGN(512) DMA_CHDESC_T ADC_TransferDescriptors[NUM_BUFFERS]; uint16_t CapturedData[32]; uint16_t DMA_Sum=0; /** * * ADC IRQ not Used right now... Only for testing */ void ADC_SEQA_IRQHandler(void) {             /* If SeqA flags is set i.e. data in global register is valid then read it */         Chip_GPIO_SetPinState(LPC_GPIO, 0, 6, true);         //DEBUGOUT("ADC Output = %d\r\n", adcOut);         Chip_GPIO_SetPinState(LPC_GPIO, 0, 6, false);         Chip_ADC_ClearFlags(LPC_ADC,0xFFFFFFFF); } void DMA_IRQHandler(void) {         static uint16_t DMA_Sum=0;                 DMA_Sum++;                  if(DMA_Sum ==8)          {            DMA_Sum=4;          }             Chip_GPIO_SetPinState(LPC_GPIO, 0, 7,true);      /* Rrror interrupt on channel 0? */      if ((Chip_DMA_GetIntStatus(LPC_DMA) & DMA_INTSTAT_ACTIVEERRINT) != 0)      {           /* This shouldn't happen for this simple DMA example, so set the LED              to indicate an error occurred. This is the correct method to clear              an abort. */           Chip_DMA_DisableChannel(LPC_DMA, DMA_CH0);           while ((Chip_DMA_GetBusyChannels(LPC_DMA) & (1 << DMA_CH0)) != 0) {}           Chip_DMA_AbortChannel(LPC_DMA, DMA_CH0);           Chip_DMA_ClearErrorIntChannel(LPC_DMA, DMA_CH0);           Chip_DMA_EnableChannel(LPC_DMA, DMA_CH0);           Board_LED_Set(0, true);      }      Chip_GPIO_SetPinState(LPC_GPIO, 0,7,false);      /* Clear DMA interrupt for the channel */      LPC_DMA->DMACOMMON[0].INTA = 1; }      /***       *      ____  __  __    _       *     |  _ \|  \/  |  / \       *     | | | | |\/| | / _ \       *     | |_| | |  | |/ ___ \       *     |____/|_|  |_/_/   \_\       *     / ___|  ___| |_ _   _ _ __       *     \___ \ / _ \ __| | | | '_ \       *      ___) |  __/ |_| |_| | |_) |       *     |____/ \___|\__|\__,_| .__/       *                          |_|       */ void DMA_Steup(void) {         DMA_CHDESC_T Initial_DMA_Descriptor;                 ADC_TransferDescriptors[0].source = (uint32_t)&LPC_ADC->SEQ_GDAT[0];      ADC_TransferDescriptors[1].source = (uint32_t)&LPC_ADC->SEQ_GDAT[0];      ADC_TransferDescriptors[2].source = (uint32_t)&LPC_ADC->SEQ_GDAT[0];      ADC_TransferDescriptors[3].source = (uint32_t)&LPC_ADC->SEQ_GDAT[0];      ADC_TransferDescriptors[0].dest = (uint32_t)&CapturedData[(0+1)*DMA_TRANSFER_SIZE-1];      ADC_TransferDescriptors[1].dest = (uint32_t)&CapturedData[(1+1)*DMA_TRANSFER_SIZE-1];      ADC_TransferDescriptors[2].dest = (uint32_t)&CapturedData[(2+1)*DMA_TRANSFER_SIZE-1];      ADC_TransferDescriptors[3].dest = (uint32_t)&CapturedData[(3+1)*DMA_TRANSFER_SIZE-1];      //The initial DMA desciptor is the same as the 1st transfer descriptor.   It      //Will link into the 2nd of the main descriptors.      ADC_TransferDescriptors[0].next = (uint32_t)&ADC_TransferDescriptors[1];      ADC_TransferDescriptors[1].next = (uint32_t)&ADC_TransferDescriptors[2];      ADC_TransferDescriptors[2].next = (uint32_t)&ADC_TransferDescriptors[3];      //Link back to the 1st descriptor      ADC_TransferDescriptors[3].next = (uint32_t)&ADC_TransferDescriptors[0];      //For a test,  stop the transfers here.   The sine wave will look fine.      //ADC_TransferDescriptors[3].next = 0;      ADC_TransferDescriptors[0].xfercfg = (DMA_XFERCFG_CFGVALID |                                DMA_XFERCFG_RELOAD  |                                DMA_XFERCFG_SETINTA |                                DMA_XFERCFG_WIDTH_16 |                                DMA_XFERCFG_SRCINC_0 |                                DMA_XFERCFG_DSTINC_1 |                                DMA_XFERCFG_XFERCOUNT(DMA_TRANSFER_SIZE));      ADC_TransferDescriptors[1].xfercfg = ADC_TransferDescriptors[0].xfercfg;      ADC_TransferDescriptors[2].xfercfg = ADC_TransferDescriptors[0].xfercfg;      ADC_TransferDescriptors[3].xfercfg = (DMA_XFERCFG_CFGVALID |                                DMA_XFERCFG_RELOAD  |                                DMA_XFERCFG_SETINTA |                               DMA_XFERCFG_WIDTH_16 |                               DMA_XFERCFG_SRCINC_0 |                               DMA_XFERCFG_DSTINC_1 |                               DMA_XFERCFG_XFERCOUNT(DMA_TRANSFER_SIZE));      Initial_DMA_Descriptor.source = ADC_TransferDescriptors[0].source;      Initial_DMA_Descriptor.dest =   ADC_TransferDescriptors[0].dest;      Initial_DMA_Descriptor.next =  (uint32_t)&ADC_TransferDescriptors[1];      Initial_DMA_Descriptor.xfercfg = ADC_TransferDescriptors[0].xfercfg;      /* DMA initialization - enable DMA clocking and reset DMA if needed */      Chip_DMA_Init(LPC_DMA);      /* Enable DMA controller and use driver provided DMA table for current descriptors */      Chip_DMA_Enable(LPC_DMA);      Chip_DMA_SetSRAMBase(LPC_DMA, DMA_ADDR(Chip_DMA_Table));      /* Setup channel 0 for the following configuration:         - High channel priority         - Interrupt A fires on descriptor completion */      Chip_DMA_EnableChannel(LPC_DMA, DMA_CH0);      Chip_DMA_EnableIntChannel(LPC_DMA, DMA_CH0);      Chip_DMA_SetupChannelConfig(LPC_DMA, DMA_CH0,     //(DMA_CFG_PERIPHREQEN     |                                    (DMA_CFG_HWTRIGEN        |                                     DMA_CFG_TRIGBURST_BURST |                                                          DMA_CFG_TRIGTYPE_EDGE   |                                        DMA_CFG_TRIGPOL_LOW    |    //DMA_CFG_TRIGPOL_HIGH                                        DMA_CFG_BURSTPOWER_1    |                                     DMA_CFG_CHPRIORITY(0)                                          )                                        );      //make sure ADC Sequence A interrupts is selected for for a DMA trigger      LPC_INMUX->DMA_ITRIG_INMUX[0] = 0;      /* Enable DMA interrupt */      NVIC_EnableIRQ(DMA_IRQn);      // The 1st descriptor is set up through the registers.      /* Setup transfer descriptor and validate it */      Chip_DMA_SetupTranChannel(LPC_DMA, DMA_CH0, &Initial_DMA_Descriptor);      //Use the transfer configuration for our 4 main descriptors      Chip_DMA_SetupChannelTransfer(LPC_DMA, DMA_CH0,     ADC_TransferDescriptors[0].xfercfg);      Chip_DMA_SetValidChannel(LPC_DMA, DMA_CH0);      } void SCT_PWM_Generate(void) {          /* Initialize the SCT as PWM and set frequency */      Chip_SCTPWM_Init(SCT_PWM);      Chip_SCTPWM_SetRate(SCT_PWM, SCT_PWM_RATE);      /* Setup Board specific output pin */      Chip_IOCON_PinMuxSet(LPC_IOCON, 1, 14, IOCON_FUNC3 | IOCON_MODE_INACT | IOCON_DIGITAL_EN | IOCON_INPFILT_OFF);      /* Use SCT0_OUT7 pin */      Chip_SCTPWM_SetOutPin(SCT_PWM, SCT_PWM_OUT, SCT_PWM_PIN_OUT);              /* Start with 50% duty cycle */      Chip_SCTPWM_SetDutyCycle(SCT_PWM, SCT_PWM_OUT, Chip_SCTPWM_PercentageToTicks(SCT_PWM, 10));      Chip_SCTPWM_Start(SCT_PWM);    }      /***            *         _    ____   ____            *        / \  |  _ \ / ___|            *       / _ \ | | | | |            *      / ___ \| |_| | |___            *     /_/__ \_\____/ \____|            *     / ___|  ___| |_ _   _ _ __            *     \___ \ / _ \ __| | | | '_ \            *      ___) |  __/ |_| |_| | |_) |            *     |____/ \___|\__|\__,_| .__/            *                          |_|            */ void ADC_Steup(void) {     /*Set Asynch Clock to the Main clock*/     LPC_SYSCON->ADCCLKSEL = 0;     //Set the divider to 1 and enable.  note,  the HALT bit (30) and RESET (29) are not in the manual     LPC_SYSCON->ADCCLKDIV = 0;      /* Initialization ADC to 12 bit and set clock divide to 1 to operate synchronously at System clock */     Chip_ADC_Init(LPC_ADC, ADC_CR_RESOL(3) | ADC_CR_CLKDIV(0)| ADC_CR_ASYNC_MODE);       //select ADC Channel 1 as input     Chip_IOCON_PinMuxSet(LPC_IOCON, 0, 30, IOCON_FUNC0 | IOCON_ANALOG_EN| IOCON_INPFILT_OFF);       LPC_ADC->INSEL = 0x01;     Chip_ADC_SetupSequencer(LPC_ADC,ADC_SEQA_IDX,                                                                          ADC_SEQ_CTRL_SEQ_ENA |                               ADC_SEQ_CTRL_CHANNEL_EN(ADC_INPUT_CHANNEL) |                                                 ADC_SEQ_CTRL_TRIGGER(2) |                               ADC_SEQ_CTRL_HWTRIG_POLPOS |                                                 ADC_SEQ_CTRL_HWTRIG_SYNCBYPASS |                               ADC_SEQ_CTRL_MODE_EOS |                                                 ADC_SEQ_CTRL_SEQ_ENA);     /* Enable Sequence A interrupt */     Chip_ADC_EnableInt(LPC_ADC, ADC_INTEN_SEQA_ENABLE);         /* Calibrate ADC */     if(Chip_ADC_Calibration(LPC_ADC) == LPC_OK) {         /* Enable ADC SeqA Interrupt */         NVIC_EnableIRQ(ADC_SEQA_IRQn);     }     else {         DEBUGSTR("ADC Calibration Failed \r\n");         return ;     } } int main(void) {       SystemCoreClockUpdate();     Board_Init();         DMA_Steup();     ADC_Steup();     SCT_PWM_Generate();         while(1)     {}     } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍  Verification      Building the project, then click the   to debug;        Generate the sine wave: 1 KHz, 幅度:0~2 V,feed the wave the ADC via the J9_1(P0_30-ADC1);         Setting the breakpoint (Fig 4) to observe the ADC converted value CapturedData[32]; Fig 4                        4. To verifying the result, I collect several group of data and use the Excel to make these data graphical for checking. Fig 6 is an example. Fig 5 Fig 6 Fig 7 Fig 8
View full article
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? 
View full article
This document is an introduction to the Programmable Logic Unit (PLU) provided for the LPC804 MCU device. PLU is used to create small combinatorial and/or sequential logic networks including simple state machines. This allows to replace external components like the 74xx series, which are used for the glue logic with the microcontroller and external devices, making simple the PCB and saving design costs. Figure 1. LPC80x MCU families The PLU is comprised of an array of 26 inter-connectable, 5-input Look-up Table (LUT) elements, and 4 flip-flops.  Each LUT element contains a 32-bit truth table (look-up table) register and a 32:1 multiplexer. During operation, the five LUT inputs control the select lines of the multiplexer. This structure allows any desired logical combination of the five LUT inputs. Figure 2. PLU Features The PLU is used to create small combinatorial and/or sequential logic networks including simple state machines. The PLU is comprised of an array of 26 inter-connectable, 5-input Look-up Table (LUT) elements, and 4 flip-flops. Eight primary outputs can be selected using a multiplexer from among all of the LUT outputs and the 4 flip-flops. An external clock to drive the 4 flip-flops must be applied to the PLU_CLKIN pin if a sequential network is implemented. Programmable logic can be used to drive on-chip inputs/triggers through external pin-to-pin connections. A tool suite is provided to facilitate programming of the PLU to implement the logic network described in a Verilog RTL design.   Advantages Some advantages of the PLU are: Replace the combinational logic of the 7400 series. State machine design using Flip-flop. Address decoder. Pattern match. Low-power application. PLU works in deep-sleep and power-down mode. Programmable so PLU can be reprogrammed and reused. Seamless connection using SWM and PLU. Pin description There are up to six primary inputs into the PLU module, one clock input, and eight primary outputs. All the inputs are connected directly to the package pins via chip-level I/O multiplexing.  All these pins can be enabled by configuring the relevant SWM register (PINASSIGN_FIXED0). A particular logic network may not require all of the available inputs or outputs. The user can specify which inputs and outputs to use, and which package pins those inputs and outputs will connect to as part of the overall top-level IO configuration. Registers Programming the PLU to implement a particular logic network involves writing to the various Truth Table registers to specify the logic functions to be performed by each of the LUT elements, programming the Input multiplexer registers to select the five inputs presented to each LUT, and programming the Output multiplexer register to select the eight primary outputs from the PLU module. Programming of all of these registers is performed only during initialization. Table 1. PLU registers PLU Shield board with LPCXpresso804 The OM40001 package includes a shield board for use with the LPCXpresso804 board when prototyping programmable logic unit (PLU) designs. The PLU shield provides the following features to assist with this type of development: 5 slide switches to enable 5 possible PLU inputs to be connected to VDD (marked as VCC on the Shield) or GND through a resistor (to set those inputs to a logic 1 or zero). 8 LEDs with jumpers to connect/disconnect possible PLU outputs for visual status indication. Push button option for momentary / edge signal inputs. Low-frequency oscillator with 1024Hz and 8Hz outputs. The PLU shield also includes a test circuit that can be used to implement a simple continuity tester. Several signals from the LPC804 used on the PLU Shield are shared with other functions on the main LPCXpresso804 board. Please review jumper settings on the LPCXpresso804 board carefully before installing the PLU Shield. https://www.nxp.com/docs/en/user-guide/UM11083.pdf  Figure 3. LPCXpresso804 + PLU Shield = PLU demo board   PLU input options On/off switches S1 through S5 connect possible PLU inputs to VDD or GND via a resistor, enabling those inputs to be driven to a known, fixed state. PIO0_8 is connected to a push button (S6) and a 100kohm pull up to VDD; PIO0_8 will be grounded when the button is pressed. Table below shows these connections. Table 2. PLU input on/off switches. A digital oscillator circuit is also included on the Shield, with 1.024kHz and 8Hz outputs available. LPC804 signal PIO0_1 can be connected to these oscillator signals in order to provide a low-speed clock to the flip-flops in the PLU block. The center pin (2) of JP12 connects to PIO0_1, so a jumper can be placed onto JP12 to connect this signal to the required clock (see markings on the Shield silk screen.) An external clock can be provided to the PLU by connecting it to the center pin of JP12. PLU output options LEDs are used to monitor the PLU outputs. Due to the limited number of pins on the chip/board, some of the inputs and outputs are shared. Table 3. PLU shield LEDs. PLU examples You have two options to find a PLU example: Using the SDK for the LPCXpresso804. You can download the SDK for the LPCXpresso804 from Welcome | MCUXpresso SDK Builder The PLU project is a simple demonstration program of the SDK PLU driver. In this example, a number of switches are used act as PLU inputs and LEDs are used to monitor the PLU outputs to demonstrate the configuration and use of the Programmable Logic Unit (PLU). Using the LPC804 Example Code Bundle. Code Bundle, containing source code for drivers, example code and project files. You can download it from LPCXpresso804 board for LPC804 Microcontroller (MCU)|NXP  It is recommended to use the PLU configuration tool. Please check the following links for more details. PLU Tool Direct, LUT-based design: https://www.nxp.com/video/part-2-plu-tool-direct-lut-based-design:Part2-PLU-config-tool-verilog PLU Tool Schematic design: https://www.nxp.com/video/part-3-plu-tool-schematic-design:Part3-PLU-config-tool-schematic PLU Tool Importing Verilog files: https://www.nxp.com/video/part-4-plu-tool-importing-verilog-files:Part4-PLU-config-tool-directlut
View full article
    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.    
View full article
This document describes how to create a new LPC project using LPCOpen v2.xx, LPCXpresso v8.2.2 and LPC11U24 LPCXpresso board. In addition describes how to create 2 simple example codes. Blinking LED. Set the LED using a push bottom.  LPCOpen 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. After install LPCXpresso, the LPCOpen packages for supported board(s)/device(s) can be found at the path: <install_path>\lpcxpresso\Examples\LPCOpen > This directory contains a number of LPCOpen software bundles for use with the LPCXpresso IDE and a variety of development boards. Note that LPCOpen bundles are periodically updated, and additional bundles are released. Thus we would always recommend checking the LPCOpen pages to ensure that you are using the latest versions. This example was created using the LPC11U24 LPCXpresso board in this case the drivers selected is lpcopen_v2_00a_lpcxpresso_nxp_lpcxpresso_11u14.zip Importing libraries In order to create a new project, it is necessary to first import the LPCOpen Chip Library for the device used and optionally the LPCOpen Board Library Project. For do that it is necessary to follow these steps: 1. Click on Import project(s). 2. Select the examples archive file to import. In this case, the projects imported are contained within archives .zip.  3. For this example the LPC11U14 LPCXpresso board is selected. Click Open. Then click Next 4. Select only the LPCOpen Chip Library and LPCOpen Board Library Project. Click Finish. The same steps are required for any LPC device and board you are used. Creating a new LPC project.   The steps to create a new LPC project are described below: 1. In Quickstar Panel, click "New project"   2. Choose a wizard for your MCU. In this case LPC1100/LPC1200 -> LPC11Uxx -> LPCOpen-C Project This option will link the C project to LPCOpen. Then click Next.   3. Select the Project name and click Next.   4. Select the device used (LPC11U24 for this case) and click Next.   5. Select the LPCOpen Chip Library and LPCOpen Board Library, these projects must be present in the workspace.   6. You can set the following option as default clicking Next, then click Finish.   7. At this point, a new project was created. This project has a src (source) folder, the src folder contains: cr_startup_lpc11uxx.c: This is the LPC11Uxx Microcontroller Startup code for use with LPCXpresso IDE. crp.c: Source file to create CRP word expected by LPCXpresso IDE linker. sysinit.c: Common SystemInit function for LPC11xx chips. <name of project> my_first_example: This file contains the main code.     8. LPCXpresso creates a simple C project where it is reading the clock settings and update the system core clock variable, initialized the board and set the LED to the state of "On". 9. At this point you should be able to build and debug this project.   Writing my first project using LPCXpresso, LPCOpen and LPC11U24.   This section describes how to create 2 simple example codes. Blinking LED. Set the LED using a push bottom. The LPCOpen Chip Library (in this case lpc_chip_11uxx_lib) contains the drivers for some LPC peripherals. For these examples, we will use the GPIO Driver. The LPCOpen Board Library Project (in this case nxp_lpcxpresso_11u14_board_lib) contains files with software API functions that provide some simple abstracted functions used across multiple LPCOpen board examples. The board_api.h contains common board definitions that are shared across boards and devices. All of these functions do not need to be implemented for a specific board, but if they are implemented, they should use this API standard.   After create a new project using LPCXpresso and LPCOpen, it is created a simple C project where it is initialized the board and set the LED to the state of "On" using the Board_LED_Set function.   int main(void) {   #if defined (__USE_LPCOPEN)     // Read clock settings and update SystemCoreClock variable     SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)     // Set up and initialize all required blocks and     // functions related to the board hardware     Board_Init();     // Set the LED to the state of "On"     Board_LED_Set(0, true); #endif #endif       // TODO: insert code here       // Force the counter to be placed into memory     volatile static int i = 0 ;     // Enter an infinite loop, just incrementing a counter     while(1) {         i++ ;     }     return 0 ; }       a. Blinking LED. In board_api.h file there is an API function that toggle the LED void Board_LED_Toggle(uint8_t LEDNumber);  LEDNumber parameter is the LED number to change the state. The number of the LED for the LPCXpresso LPC11U24 is 0. It is easy to create a delay function using FOR loops. For example: void Delay (unsigned int ms) {         volatile static int x,y;           while (ms)         {                 for (x=0; x<=140; x++)                 {                         y++;                 }                 ms--;         } } In order to have the LED blinking, it is necessary to call these functions in an infinite loop. while(1) {                 Board_LED_Toggle(0);                 Delay (10000);         } Complete code (Blinking LED). int main(void) { #if defined (__USE_LPCOPEN)         // Read clock settings and update SystemCoreClock variable         SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)         // Set up and initialize all required blocks and         // functions related to the board hardware         Board_Init();         // Set the LED to the state of "On"         Board_LED_Set(0, true); #endif #endif          while(1) {                 Board_LED_Toggle(0);                 Delay (10000);         }         return 0 ; }  void Delay (unsigned int ms) {         volatile static int x,y;         while (ms)         {                 for (x=0; x<=140; x++)                 {                         y++;                 }                 ms--;         } }      b. Set the LED using a push bottom. For this example it is necessary to configure a pin as input.  The gpio_11xx_1.h file contains all the function definitions for the GPIO Driver. The example uses the pin 16 of port 0 to connect the push bottom. The function Chip_GPIO_SetPinDIRInput(LPC_GPIO_T *pGPIO, uint8_t port, uint8_t pin) sets the GPIO direction for a single GPIO pin to an input. In order to configure the Port 0, pin 16 as input we can use this function: Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 16); Then, it is necessary to check the status of this pin to turn-on/turn-off the LED. The function Chip_GPIO_GetPinState(LPC_GPIO_T *pGPIO, uint8_t port, uint8_t pin) gets a GPIO pin state via the GPIO byte register. This function returns true if the GPIO is high, false if low. State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 16);   Complete code (Set the LED using a push bottom). int main(void) {         bool State_Input;   #if defined (__USE_LPCOPEN)     // Read clock settings and update SystemCoreClock variable     SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)     // Set up and initialize all required blocks and     // functions related to the board hardware     Board_Init();     Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 16);     // Set the LED to the state of "On"     Board_LED_Set(0, false);  #endif  #endif      while(1) {           State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 16);              if (State_Input==0){                 Board_LED_Set(0, true);             }             else {                 Board_LED_Set(0, false);             }     }     return 0 ; }   I hope this helps!! Regards Soledad
View full article