MCUXpresso IDE: Blinky and the NXP LPC800-DIP Board
The LPC800-DIP board is a small and breadboard-friendly development platform. Let's get a look at it in action with a simple blinky app.
Join the DZone community and get the full member experience.
Join For FreeDuring Embedded World 2017 in Nürnberg, I was lucky to get a handful of LPC800-DIP boards. To all students who were lucky enough to get one, here is a tutorial to make a ‘blinky’ application on that board:
This article is part of a series to get up to speed using the new NXP MCUXpresso IDE. Published so far are:
- MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers
- MCUXpresso IDE: S-Record, Intel Hex, and Binary Files
- MCUXpresso IDE: Importing Kinetis Design Studio Projects
Outline
This article shows to run your first ‘blinky’ (toggling LEDs on the board) on the LPC800-DIP board using Eclipse (MCUXpresso IDE) and the NXP LPCOpen library.
You need:
- An LPC800-DIP board or any other LPC8xx board, though in that case, you will need to change the LED pins in the source code
- MCUXpresso IDE V10.0.0 b344
- a micro USB cable
- An SWD/JTAG debug probe like the LPC-Link2
The LPC800-DIP board does not contain a debug interface, but the USB-2-UART bridge can be used with the FlashMagic (by Embedded Systems Academy) tool to program binaries. As I want to debug my application, I’m not using this tool in this article.
A link to all the project and source files is provided at the end of the article
The LPC800-DIP board is a tiny board with the NXP LPC824 microcontroller on it:
It has the LPC824M201JHI33 on it (32 bit Cortex-M0+, 32 KByte Flash, 4 KB RAM) in a breadboard friendly pin out. The microcontroller can be programmed using SWD or through the Silabs CP2102 UART-USB bridge: By pressing the ISP button, I can program the device through the USB connection to the host and the FlashMagic utility.
SDK: LPC Board and LPC Chip Projects
To start with the board, I need a software library or SDK. For the LPC800, NXP provides the LPCOpen library. That library already is installed with the MCUXpresso IDE:
Alternatively, I can find them here.
I import the library project into my workspace using the ‘Import project(s) from file system…’ from the quickstart panel in the MCUXpresso IDE:
Then browse for the LPCOpen archive file:
C:\nxp\MCUXpressoIDE_10.0.0_344\ide\Examples\LPCOpen\lpcopen_2_19_lpcxpresso_nxp_lpcxpresso_824.zip
Press Next. I get offered a selection of projects to import. I need the chip library, which I select:
The ‘chip’ library, as the name indicates, supports the given chip. I could also import the board library (but that one would be for that board) or the example projects. For my blinky project, all I need is the chip library, and I will do my ‘board support’ for the LEDs.
Press Finish and the chip library shows up in the workspace:
The next step is to create a new project for the board. I use again the quickstart panel with ‘New Project’:
Select the LPC824:
Press next. Select LPCOpen C project:
Press Next and give a project name:
In the next dialog box, it should detect the chip library I have present in my workspace:
Press Next. In the next dialogs, I use the defaults until I finish the wizard and the project gets created in the workspace:
Schematics and LEDs
Checking the schematics of the board, I can see that the three LEDs on the board are connected to PIO0_17, PIO0_16, and PIO0_15:
The LEDs are connected with the cathode side to the microcontroller. So this means I have to set the pin to LOW to turn the LED on (the LEDs are LOW-ACTIVE).
I add the following to the program:
#include "gpio_8xx.h"
/* GPIO pin numbers for LEDs */
#define RED_LED 15
#define GREEN_LED 16
#define BLUE_LED 17
This includes the header file for the GPIO peripheral, and I have added defines for the GPIO pins used by the three LEDs.
GPIO Initialization
To use the GPIO pins, I have to initialize them. I do this in a ‘BoardInit()’ function which does the following:
- Enable the clocking for the GPIO peripheral
- Configure the pins as output pins
- Initialize them with a logic for a HIGH level. The LEDs are LOW active, so putting a HIGH (or TRUE) will turn it off.
The following is my BoardInit() function:
static void BoardInit(void) {
/* Enable the clock GPIO */
Chip_Clock_EnablePeriphClock(SYSCTL_CLOCK_GPIO);
/* red */
Chip_GPIO_SetPinDIROutput(LPC_GPIO_PORT, 0, RED_LED);
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, RED_LED, true);
/* green */
Chip_GPIO_SetPinDIROutput(LPC_GPIO_PORT, 0, GREEN_LED);
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, GREEN_LED, true);
/* blue */
Chip_GPIO_SetPinDIROutput(LPC_GPIO_PORT, 0, BLUE_LED);
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, BLUE_LED, true);
}
Because I need to delay the blinking of the LEDs, I add a very simple delay routine, which burns CPU cycles:
static void delay(void) {
/* very simply delay routine */
volatile uint32_t cntr = 0x80000;
while(cntr>0) { /* burn some cycles */
cntr--;
__asm volatile("nop\n");
}
}
Board Initialization in main()
In main(), I call the BoardInit() to initialize the hardware:
Finally, we add some code to do the blinky inside main(). With...
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, RED_LED, true);
...the red LED is turned off, and with the following, it is turned on:
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, RED_LED, false);
Between the LED on/off, I have added the calls to the delay routine to slow down things inside main():
while(1) {
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, RED_LED, true);
delay();
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, RED_LED, false);
delay();
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, GREEN_LED, true);
delay();
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, GREEN_LED, false);
delay();
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, BLUE_LED, true);
delay();
Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, BLUE_LED, false);
delay();
i++ ;
}
Build
Use the ‘hammer’ in the Quickstart panel to build the project:
This should build without any errors :-).
The board has SWD/JTAG header. I prefer this way and do not program the board with FlashMagic, because that way I can debug it. But this requires an SWD/JTAG probe like the LPC-Link2, which I use here.
Connect the SWD cable to the SWD header on the LPC800-DIP board. In the bove case, I have the jumper JP2 on the LPC-Link2 set, so I power the board from the LPC-Link2. If using another probe, you might need to power the LPC800 board with its micro USB cable.
Start the debugger with the ‘blue’ debug icon in the quickstart panel, and it should recognize the debug probe:
Press OK, and I’m debugging the board:
Summary
The LPC800-DIP board is a small and breadboard friendly development platform with a Cortex-M0 on it, which makes it ideal for smaller projects. For the LPC8xx series, there is no MCUXpresso SDK (yet?). But MCUXpresso IDE comes with the LPCOpen SDK, which makes the implementation of a blinky possible in a very short time. I appreciate that it has an SWD debug header, so I can use it with my favorite JTAG/SWD debug probe and Eclipse.
I have been told by NXP that the LPC800-DIP board is not available for sale (yet?). NXP gave away many of these boards at the Embedded World 2017 show in Germany, so you might have been lucky and have a board on your desk you can use with this tutorial (or any other LPC800 board).
The project sources are on GitHub.
PS: I still have a few boards available at the Lucerne University of Applied Sciences and Arts, which I can give away. First come, first serve.
Happy DIPing!
Links
- LPC800-DIP Schematics: https://community.nxp.com/community/lpc/blog/2017/03/20/lpc800-dip-schematic?et=watches.email.blog and https://community.nxp.com/community/lpc/blog/2017/03/20/lpc800-dip-schematic
- MCUXpresso IDE web page: http://www.nxp.com/mcuxpresso/ide
- MCUXpresso IDE community: http://www.nxp.com/mcuxpresso/ide/forum
- LPC-Link2 Debug Probe: http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc1100-cortex-m0-plus-m0/lpc-link2:OM13054
- Project on GitHub: https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/MCUXpresso/LPC800-DIP
Published at DZone with permission of Erich Styger, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments