Table of contents

RoadTest: LPCXpresso 51U68 Dev Board

Author: Fred27

Creation date: 28 Sep 2018

Evaluation Type: Development Boards & Tools

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?: There are many other manufacturers making ARM Cortex M0 and M0+ microcontrollers. The most obvious competitors would be the STM NUCLEO-L073RZ. NXP have a large range of other M0+ boards.

What were the biggest problems encountered?: A buggy crash-prone IDE.

Detailed Review:

• How I'll approach this road test
• Where I'm starting from
• The road test
  • Getting started
  • Getting an IDE up and running
  • Device support for the 51U68
    • Some example code
    • A template for your own application
  • Device support for my older LPC4337
• Conclusion

How I'll approach this road test

There are lots of very capable microcontrollers out there. An electronic engineer of a few decades ago would not be able to believe the amazing features we have to play with and the incredibly low price we now expect to pay. There are 16 and even 8 bit microcontroller out there, but it often seems that a 32-bit ARM microcontroller is the new baseline. The average hobby microcontroller project is over-spec'd just because we can. For that reason I'm not going to focus too heavily on what the LPC51U68 can do. It's very capable and unless you have something very intensive in mind or require a specific feature then I'm sure it will do the job.

I feel that a microcontroller product line stands or falls as much on the quality of the IDE, SDK and supporting documentation than on the hardware. It's not difficult to find hardware that is "overqualified" for what a developer needs. What's really important is how easy it is to get up and running with clocks and peripherals configured and ready for use. So that's what I'll concentrate on. How easy is it to get up and running with some sample code.

Where I'm starting from

Not everyone will have the same experience starting development on the LPC15U68. Everyone's got a different background and a different level of knowledge of the concepts. So it will be useful to know where I'm starting from. I'm reasonably experienced with microcontroller development. I've played with various 16 and 32-bit microcontrollers over the last 5 years or so. Most of my experience is with TI parts. There's nothing magical about TI - it's just that as the ecosystem is important to getting up and running I decided to concentrate on just one. I find jumping around between them isn't productive if you don't have to.

I have however had some experience with NXP. It got involved with the Smoothieboard project and have written some C++ components for that. I got an LPC1769 LPCXpresso development board for that and bought an LPCXpresso4337 board because that was where v2.0 was heading. They're been gathering dust for a while, but they may get pull back into service if they help with this road test. I'm particularly interested in how NXP support older devices because that will tell you where your 51U68 board is likely to be in a few years. Will it be fully supported or will you have to dig out old IDEs and debuggers just to use it? In my experience with TI, when a newer version of something comes out, the documentation and examples for the older stuff can get a little confused and overwritten.

The road test

Getting started

I'm not normally one for padding out a road test with a lengthy unboxing. However, it would be mean of me to not show the box as it seems that NXP (or is it Embedded Artists) have put a bit of effort into restyling their packaging. One thing to look out for though is a couple of small jumpers for 0.1" headers on the board. These are taped to the box underneath the board. It didn't come with a micro USB cable but I think this is a good thing. I'm sure like me you have loads of them cluttering up your workspace. Supplying them with every little thing is wasteful. Good on NXP for saving the planet just a tiny bit.

I plugged the board in using one of the two micro USB sockets on the board - the central one J5 which seems to be marked Target PWR (although this marking could be for a nearby jumper). The out-of-the-box demo started. It was a fairly standard affair with a flashing LED that changed colour and frequency as you press button SW1, SW2 and SW3. The only remarkable thing was that it was obviously also operating in USB HID (Human Input Device) mode and making my mouse pointer move in a continuous square pattern. A fairly standard demo of capabilities. The USB capability of the LPC51U68 isn't heavily promoted so it's good that this is highlighted. Looking a little deeper into the feature set it seems that it can operate without a crystal for USB too, which may be handy. A Real Time Clock (requiring a 32kHz crystal) is probably the only other unusual feature on this ARM M0+ processor. A full list of features is available here.

Getting an IDE up and running

First things first, you will need an IDE. Whilst Keil and IAR are supported, I'm going to stick with NXP's own IDE. This is https://www.nxp.com/mcuxpresso. (Note that the link in the getting started guide is incorrect.) It's been so long since I used it that back then it was called LPCXpresso. Much like TI did with their CCS development environment, NXP have decided to make the fully featured Pro version available to all for free since May 2018. Great.

So, here I hit a small hitch. I had to register with NXP and confirm my email address before I could down load the IDE. The confirmation email didn't come through. I hit resend. 30 minutes later it eventually arrived, but this first email was now invalid. I had to wait another 30 minutes for the second one. I got it installed in the end, but having to wait an hour for some free software was a bit frustrating.

It installed OK. It's Eclipse-based (much like TI's equivalent) so felt reasonably familiar. It uses Eclipse Oxygen 4.7 - released June 2107. Right now 4.9 is the current build so it's a little out of date. I have learned in the past with Eclipse that it doesn't always like being installed in "Program Files" on Windows even though that's where things should go. Stick with the default install directory if you want to avoid problems later. I didn't try using a Mac or Linux but those are supported. For Linux it's a deb install file, so you may be limited to Debian based builds (including the popular Ubuntu).

Device support for the 51U68

I plugged in the board to start coding and got a bit of a surprise. I used a different micro USB connector to my previous power-up - marked Link - in order to check that drivers for the onboard Link2 debugger were loaded.The OOB demo fired up again - including the mouse movement. Oh dear - this is going to make it hard to open up the IDE and reprogram the microcontroller! Luckily, this seemed to happen because the drivers for the Link2 probe weren't yet loaded. After unplugging the board then it behaved a little more as expected - the mouse movement only happens using one of the USB ports. Good job too otherwise this road test may have been a bit shorter and the score a little lower! Other than the unexpected bahaviour on first plug-in it was a fairly  seamless affair. Windows automatically installed the appropriate drivers and the IDE was happy to acknowledge it.

To code against newer NXP devices it seems you have to create an SDK. This seems reasonable. However it isn't obvious how to do this - or that you need to at all - unless you read the User guide for MCUXpresso. The link is a little lost lower down the welcome page but is also available by selecting Help / MCUXpresso User Guide. This will take you to http://mcuxpresso.nxp.com/  and then on to down load SDK builder. The experience was marred a little by the fact that NXP have let their SSL certificate expire and Chrome gave plenty of warning

about the security of the site. Not the end of the world, but fairly unprofessional.

Once you have the SDK downloaded, you need to import it into the IDE by dropping the ZIP file onto the "Instaled SDKs" view. I must admit it took me quite a while to find this view. The image in the guide wasn't any help. It was too small to see and the item indicated with an arrow seemed to be entirely the wrong thing. It turns out it is one of the tabs in the lower right of the IDE window. It's obvious when you find it, but not obvious when you're not sure what you're looking for.

Whilst I'm not immediately taken with the usability of the IDE, I decided that a reasonable test would be to see if I can find and follow the examples for some peripheral setup - always the difficult bit with a new microcontroller in my opinion. I will see how easy it is to set up a clock, use this to cause an interrupt and alter the PWM output on a pin. Let's get an LED "breathing" instead or flashing by changing the brightness. Does that sound like a fair test? I think so.

Some example code

I find the easiest way to get started with a new board is to take a peek and the example code provided in the SDK. I clicked "Import SDK example(s)...", then the 51U68 and got an extensive list of  samples with and without an RTOS or CMSIS drivers. A good start. Perhaps my test project has been pretty much written for me already?

For those who aren't familiar with ARM development, CMSIS stands for Cortex Microcontroller Software Interface Standard and is ARM's way of trying to ensure code portability between different manufacturers. They should all expose the same functions for peripheral use. RTOS stands for Real Time Operating System and is helpful if you code is complex enough to need coordination between different components.

Unfortunately I was then met with a bug in the MCUXpresso IDE and it crashed. It wasn't the only time I had problems with the IDE. It also locked up when closing it later. After playing around with a clean project I managed to get the samples to work again, so I'll put it down to a temporary glitch. Still not impressing me though, NXP.

Once I got the sample project loaded, I managed to compile and debug it. All you need to do is click the blue bug icon. It felt very familiar to TI's CCS IDE as they're both Eclipse based.

Unfortunately the project the crashed out at an assert statement because it couldn't determine the clock frequency to use for the debug console. I didn't screenshot this and it now seems to have resolved itself, but once again things didn't run smoothly.

On the plus side, this particular example - found under driver-examples / ctimer / ctimer_pwm_interrupt_example - did exactly what I'd decided that my test would be. I have to give NXP credit for that. Rather than recreate my own and probably do it badly, let's dig into their sample code and see if it makes sense and it actually helpful.

First, of course we have the main C function. I've missed out all the usual includes, prototypes and variables for brevity.

int main(void)
{
    ctimer_config_t config;
    uint32_t srcClock_Hz;

    /* Init hardware*/
    /* attach 12 MHz clock to FLEXCOMM0 (debug console) */
    CLOCK_AttachClk(BOARD_DEBUG_UART_CLK_ATTACH);

    /* Enable the asynchronous bridge */
    SYSCON->ASYNCAPBCTRL = 1;

    /* Use 12 MHz clock for some of the Ctimers */
    CLOCK_AttachClk(kFRO12M_to_ASYNC_APB);

    BOARD_InitPins();
    BOARD_BootClockFROHF48M();
    BOARD_InitDebugConsole();

    /* CTimer0 counter uses the AHB clock, some CTimer1 modules use the Aysnc clock */
    srcClock_Hz = BUS_CLK_FREQ;

    PRINTF("CTimer example to generate a PWM signal\r\n");
    PRINTF("This example uses interrupts to update the PWM duty cycle\r\n");

    CTIMER_GetDefaultConfig(&config);

    CTIMER_Init(CTIMER, &config);

    CTIMER_RegisterCallBack(CTIMER, &ctimer_callback[0], kCTIMER_SingleCallback);
    CTIMER_SetupPwm(CTIMER, CTIMER_MAT_OUT, dutyCycle, 2000, srcClock_Hz, true);
    CTIMER_StartTimer(CTIMER);

    while (1)
    {
    }
}

A lot of this is setting up the clocks, pins, debug console and finally the timer in PWM mode with a frequency of 2000Hz and a duty cycle that starts at 99.

You'll also notice a callback function which fires on every PWM cycle. This ends up here, where you'll notice that the duty cycle ramps up and down slowly between 69% and 99%, giving the breathing effect I was after.

void pwm_match_callback(uint32_t flags)
{
    static uint32_t count = 0;
    static uint8_t decrement = 1;

    if ((flags & (1 << CTIMER_MAT_OUT)) && (++count > 100))
    {
        count = 0;
        CTIMER_UpdatePwmDutycycle(CTIMER, CTIMER_MAT_OUT, dutyCycle);
        dutyCycle = dutyCycle + 1 - decrement * 2;
        if (dutyCycle == 69)
        {
            decrement = 0;
        }
        else if (dutyCycle == 99)
        {
            decrement = 1;
        }
    }
}

The only thing that struck me as odd was that there was no obvious place where the output pin for the LED was specified. I get how the PWM is working and changing, but where does it go? Eventually I found it as part of the BOARD_InitPins() function.

void BOARD_InitPins(void) { /* Function assigned for the Cortex-M0P */
  CLOCK_EnableClock(kCLOCK_Iocon);                           /* Enables the clock for the IOCON block. 0 = Disable; 1 = Enable.: 0x01u */
  // Other pin config omitted for brevity

  const uint32_t port0_pin29_config = (
    IOCON_PIO_FUNC7 |                                        /* Pin is configured as CTIMER0_MAT1 */
    IOCON_PIO_MODE_INACT |                                   /* No addition pin function */
    IOCON_PIO_INV_DI |                                       /* Input function is not inverted */
    IOCON_PIO_DIGITAL_EN |                                   /* Enables digital function */
    IOCON_PIO_INPFILT_OFF |                                  /* Input filter disabled */
    IOCON_PIO_OPENDRAIN_DI                                   /* Open drain is disabled */
  );
  IOCON_PinMuxSet(IOCON, PORT0_IDX, PIN29_IDX, port0_pin29_config); /* PORT0 PIN29 (coords: 11) is configured as CTIMER0_MAT1 */
}

I expect this to just be setting port direction, default values, etc. but it seems this was doing a little more. The LPX51U68 datasheet states "Each digital pin may support up to four different digital functions and one analog function, including General Purpose I/O" and this is the key to wiring up port 0 pin 29 to the timer output. OK - it might not be blindingly obvious that FUNC7 is what you need for PWM output, but probably no worse that any other microcontroller.

A template for your own application

Example code is all very well, but you may want to use a few different peripherals. How do you go about that? Well, if you click "New project..." rather than importing a sample, you get a fairly nice wizard that lets you select what peripherals you want set up for you. It seems pretty good although that small error message at the top doesn't seem great. It's hard to spot and if I only want to use ctimer, then why do I need flexcomm, usart and debug_console? Clock and common were automatically for me, so why no gpio and others that I do need? Select those it suggests and all is good. It beats looking through a datasheet and working it all out from scratch!

Device support for my older LPC4337

I know this is a road test of the 51U68, but I think it's important to see how a manufacturer deals with older devices. I decided to make sure you could still get some simple examples up and running for this board. Once again - device support for the CMSIS-DAP debugger was simple. Let's move onto the software.

Strangely older devices are supported without needing to create a SDK. Pick "New project" again and now chose a preinstalled MCU. A more long winded wizard gets you get up with a new empty project. Not so much in the way of examples or templated peripheral setup here. It makes you realise how much the SDKs give you - even if they're not perfect!

Conclusion

Whilst there were a few glitches in setup, I was generally impressed at how LPCXpresso gives you a good start with their newer range of microcontrollers. I haven't said too much about the LPC51U68 because as you'd expect it is an impressively capable ARM Cortex M0+ microcontroller. We expect a great deal of these little chunks of silicon. If there's something specific you need from it, then you'd better check the datasheet but otherwise I'm sure you'll find it won't disappoint you. For me it's all about usability and getting up to speed and for this I'd say that it's broadly speaking a success.