Review of NXP LPC4330-Xplorer Board

Table of contents

RoadTest: NXP LPC4330-Xplorer Board

Author: bbolo1

Creation date:

Evaluation Type: Independent Products

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: STM32 Discovery series, TI Cortex-M4 Launchpad

What were the biggest problems encountered?: The development tools needs to be more mature to support multi-core microcontroller parts (especially LPCXpresso).

Detailed Review:

First of all, I would like to thank NXP and Element14 for giving me the opportunity to test out this product.

Package content


The package I received contained the LPC4330 board together with a couple of USB cables (1 x USB micro B to USB A receptacle and 1x USB A plug to USB micro B).

Together with the board, I have found another bag containing the ULINK ME debugger adapter and its USB A plug to USB micro B cable.



The received package




Keil ULINK-ME debugger




NGX LPC4330 board and its accessories




NGX LPC4330-Xplorer leaflet-front




NGX LPC4330-Xplorer leaflet-back


Getting the support materials and tools

I found the links on the Element14 RoadTest webpage very useful since I was able to download the important materials I needed for this board.

However, during my searches I have found some additional materials that helped me understand more about the LPC4330 and its supporting tools.

I will list all the references in a separate section below.

Installing tools

NGX Technologies offers code examples for LPCXpresso, Keil and IAR tools. However, the provided debugger works only with Keil tools. If anybody in the audience knows about a possibility to use this debugger with LPCXpresso or IAR tools, please give more details in the comment section. Thank you!


I have registered on the Keil website in order to be able to download the tools. Keil tools have 32KB limit for the compiled code.

The provided debugger, ULINK-ME should work ok with these tools. In order to be able to create firmware images beyond this limit, a temporary licence should be offered to the selected RoadTest participants. There was a promise of temporary licences offered by Keil to the selected group. I will contact Element14 to get a temporary licence.

The version of the Keil tools is:




LPC4330 board and ULINK-ME debugger


Next, I have continued with the LPCXpresso from Code Red Technologies. You have to create an account on their website in order to be able to download the tools.

I have downloaded the LPCXpresso 4.3.0 (Build 1023) tools and proceeded with their installation which went fine.

LPCXpresso is an Eclispe-based IDE which can be used with the NXP’s LPC series of ARM microcontrollers. After registration with Code Red Technologies, LPCXpresso has a limit of 128KB for code downloading.

However, I couldn’t find a possibility to use the provided ULINK debugger with this IDE. Since I already had an LPC-Link debugger available, I decided to give it a try with the LPC4330 board.


One of the issues I have found, at least with my kit, was that the debugger cable that came with the ULINK debugger had some notches into the both connectors.

These notches were fine with the ULINK debugger connector since this one had a missing pin that was in the same position with the notch.

On the LPC4330 board side, all the debugger pins were present. My choice was either to remove one of the pins on the board or remove the notch from the debugger cable.

Since I had an available LPC-Link (to be used with LPCXpresso tools) and on this board, all the debugger pins were present, I have decided to remove the notches on the provided debugger cable, rather than taking out the notched pins from the LPC4330 board and the LPC-Link.




LPC4330 board and LPC-Link

Getting started with the provided examples


I have used the provided LPC4330 examples to evaluate the tools and see how they’re coping with the debug of this new breed of dual-core microcontrollers.

Since I was limited to 32KB of code I started with just a simple example (Blinky).

Then, I really wanted to see the debugging capabilities for dual-core (maybe multi-core) devices.

The “LPC4330_Xplorer_DualCore” project actually contains 2 sub-folders, each having a Keil project for the cores.

The debugging works for both cores in parallel by doing the following:

  • Open a Keil uVision instance and compile the M0 project. It will output a binary content which will also be exported as an unsigned char vector contained in a C file (“CM0_Image.c”)
  • Open a 2nd instance of Keil uVision and open the M4 project. The “CM0_Image.c” file is then used within the M4 project and to be incorporated in the M4 binary
  • The M4 binary is then written into the external SPI flash which is used by the M4 at boot-time
  • Start then the debugging session on the M4 and run the code till after the image for M0 is loaded and the M0 core is taken out of reset.
  • Start the debugging process on the 1st instance being opened with the M0 project. Since the M4 execution is halted immediately after taking the M0 out of reset, you can also reset the M0 to have a common starting point between the 2 cores. The M0 debugging session won’t load any code since this was done by the M4 at runtime.
  • Now, you can debug and step-through the code (in each uVision instance) on each core independently


  I tried to use the “Blinky” example with this IDE. It worked as expected. 

Then, I wanted to run the Dual-M0 and Dual-M4 projects hoping to do a side-by-side debug session (“Dual4_M0” and “Dual4_M4_SPIFI” projects). After reading some supporting materials here, I found out LPCXpresso is unable to do parallel debug for M4 and M0.

You can only have one debug session at a moment!

I think this is quite a limitation from a development tool. Debugging is cumbersome in projects where M4-M0 interaction is being used extensively.


I haven’t tested this set of tools since I didn’t have the required debugging tools (I-Jet or Segger J-Link).



Here are the issues I have found so far:

  • The notches on the debug cable prevent it being connected to the LPC4330 board. To be able to connect it, I had to remove the notches. Having in mind the LPC-Link has all the pins present on its debug connector, it is easiest to remove the notches on the cable rather than eliminating the surplus pins on the LPC4330 board and the LP-Link
  • Even though the LPC43xx dual-core series are present, the development tools aren’t mature enough.
    • Even though Keil has the capability of debugging multi-core applications by launching multiple IDE instances, I still believe there’s work to be done here.
    • LPCXpresso doesn’t have the capability to debug both cores in parallel, so in this case there is still a lot of work to be done in order to fully support these new breed of microcontrollers (dual or multi-core)



  • The M4/M0 combination is wonderful and interesting since it allows one core to handle the peripherals (e.g. M0), while the other (e.g. M4) can focus on data processing
  • I like the fact that NGX (the board’s manufacturer) tries to put value on the chip’s peripherals by supplying the board with whatever extra parts were needed (audio codec, ETH magnetics, USB connectors). I believe the addition of these parts is making the board suitable to be integrated with existing or prototype boards.


  • The lack of proper support from the development tools for multi-core microcontrollers
  • The board itself tends to be a bit pricey compared with similar microcontroller boards (e.g. STM32 boards, TI’s M4 Launchpads,…). Anyway, the competitor boards mentioned here aren’t providing the extra parts needed for certain peripherals (e.g. ETH magnetics, audio codec, micro-SD card connector)

Feedback for NXP

My personal belief is that the combination between the M4 and the M0 is a wonderful idea.

I would use the M0 core to perform all the peripheral related tasks (drivers, data presentation) to create a very simple and intuitive data source/sink for the M4. The M4 will be then free to process the incoming/outgoing data without being involved with the actual transport of the data to peripherals.

One interesting idea would be for NXP to provide some sort of a driver framework project that would use the M0 to take care of peripherals. By using a communication mechanism between the M4/M0 cores and memory buffers for data exchange, the user can focus on the M4 processing.

Having such a project for M0 would really help the developers implementing their own ideas on the M4, thus saving maybe 50% of their development time.

In fact, the M0 and its driver framework can be considered by the users as a black-box that does all the hard work setting-up and talking to the peripherals and then presents the buffers used for data exchange between the cores. The users can focus next on developing their main projects on the M4.

Of course, the users would also modify the M0 driver project to include support for other peripherals or external chips.

In conclusion, a driver framework/M0 core pair would be thought by the users as a highly configurable complex peripheral that does all the work to present the data buffers from various peripherals.

If somebody from NXP wants to talk some more about these ideas, please feel free to contact me.



Keil uVision4


Support Documents

LPCXpresso Getting started

LPC43x0 datasheet

LPC43xx user manual

Board’s user manual (NGX)

Using the NGX LPC4330 board with Keil

Using the NGX LPC4330 board with LPCXpresso

Code-Red Technologies (LPCXpresso) support page

Code-Red Technologies (LPCXpresso) support for LPC43xx

Code-Red Technologies (LPCXpresso) support - Setting up dual-core projects

Setting up dual-core projects with LPCXpresso

Related materials

Board support page (NGX)

Keil sample code (NGX)

LPCXpresso sample code (NGX)

IAR sample code (NGX)


NGX Forum


LPC support community




I think the LPC4330 is a very important chip and deserves a lot more attention. That’s why I think this review should continue and I will come back with additions on mine.