Review of NXP LPC4330-Xplorer Board

Name: NXP LPC4330-Xplorer Board
Rating: 4.70 (6 reviews)

bbolo1 over 12 years ago

RoadTest: NXP LPC4330-Xplorer Board

Author: bbolo1

Creation date: 24 Nov 2012

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!

Keil

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: 4.60.0.0

LPC4330 board and ULINK-ME debugger

LPCXpresso

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

Keil

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 2^nd 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 1^stinstance 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

LPCXpresso

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.

IAR

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

Conclusions

Issues

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)

Pros

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.

Cons

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.

Review of NXP LPC4330-Xplorer Board

Table of contents

Package content

Getting the support materials and tools

Installing tools

Keil

LPCXpresso

Getting started with the provided examples

Keil

LPCXpresso

IAR

Conclusions

Issues

Pros

Cons

Feedback for NXP

Links

Tools

Keil uVision4

LPCXpresso

Support Documents

Related materials