Skip to content

MCU Info Page: LPC1768

Jamie Smith edited this page Sep 20, 2023 · 15 revisions

LPC1768 MCU Overview

LPC1768 board

The LPC1768 was the very first MCU to receive support from Mbed back in 2009, and it's one of the only early MCUs that's still supported in the latest Mbed version. While it might be getting a little long in the tooth, with fairly high power consumption and small RAM compared to its modern competitors, it's still a capable chip with a large array of peripherals. Not to mention, it has a significant base of educational users who rely on the Mbed LPC1768 dev board for their courses and projects. Here's hoping we can keep this venerable chip supported for a long time coming!

Note: Confusingly, the LPC1768 MCU's dev board is also called the LPC1768. This seems to be an early naming standard that was later dropped. On this page I'll say "the dev board" when I specifically mean the LPC1768 PCB; otherwise I mean the microcontroller itself.

Feature Overview

CPU Flash/Code Memory RAM Communication Peripherals Other Features
Cortex-M3, up to 100MHz
(clocked at 96MHz on the dev board)
Total: 512 kiB
Available to user:* 481.5 kiB
Total: 32 kiB (SRAM) + 16 kiB (AHBSRAM0) + 16 kiB (AHBSRAM1)
Available to user:* 19.1kiB
See note about memory banks below
  • 3x I2C (2 pinned out on dev board)
  • 4x UART (3 pinned out on dev board), one has hardware flow control
  • 2x SPI
  • 1x CAN
  • 1x USB
  • 1x Ethernet
  • 1x DAC (AnalogOut)
  • 1x ADC (AnalogIn), 200kHz, 8 multiplexed inputs
  • 6x PWM outputs (must share a common pulse period)
  • RTC
  • 4x 32-bit hardware timers (one used by Mbed)
  • DMA (not supported by Mbed, but can be used through the MODDMA library)

*"Available to user" subtracts both regions of memory unusable by default Mbed OS projects and the baseline memory used by a minimal build of Mbed OS.

A note about LPC1768 memory banks

The LPC1768 divides its RAM into three banks: main SRAM, AHBSRAM0, and AHBSRAM1. The AHBSRAM banks are optimized for use with DMA, but are also usable as standard RAM. However, they are not contiguous with the first one, so the GNU linker is not able to automatically place items in these memory banks. Thus, only the first 32k bank is available to naive code.

To make use of these memory banks, you need to manually place items in them using an attribute declaration. If you have code like this:

SomeLargeObject obj;

change it to:

SomeLargeObject obj __attribute__((section("AHBSRAM0")));

This will move the object into the ABHSRAM0 bank. This can be used on both global variables and static variables inside functions.

Additionally, when Ethernet connectivity is used, Mbed automatically places the networking buffers into AHBSRAM1.

Dev Board Firmware Update (PLEASE READ)

As of 2022, new LPC1768 dev boards are still being shipped with very old firmware on their interface chips. Not only does this firmware not support debugging, it also makes thread sleeps run for an incorrect amount of time! You will find that your MCU sleeps for 10ms when you tell it to sleep for 1ms! No, I don't know why this happens, but I do know how to fix it.

To update the firmware, simply download this file and save it onto the LPC1768 dev board's USB drive. Then, unplug the USB connection to turn off the power and plug it back in again. Leave the board alone for a few seconds, and it should flash the firmware and boot like normal.

More details on the interface firmware here.

Configuring Clocking

Mbed OS currently uses a fixed clocking configuration for the LPC1768. A 12Mhz input clock is required, either by connecting a crystal between XTAL1 and XTAL2, or by connecting an external 1.8V oscillator to XTAL1. See the electrical datasheet section 15.2 for details.

Additionally, a 32.768kHz crystal can be connected to the RTCX1 and RTCX2 pins to provide a clock source to the RTC. However, this is optional, and the crystal is not even powered up until the RTC is used in code.

Semihosting and the LocalFileSystem

Thanks to being the original Mbed design, this board has a unique feature that is no longer found on any other Mbed targets: the LocalFileSystem. Most Mbed boards emulate a USB drive, allowing you to drag and drop bin files onto the board to program it. The LPC1768 dev board takes this a step further, and allows your code to actually read and write files on the very same virtual USB drive.

How does this work? Well, it's a bit complicated. Essentially, the interface chip (the second MCU on the bottom of the LPC1768 dev board) is always debugging the LPC1768, even when you do not have a debugger connected. This interface chip is also connected to a 2MB flash that stores the virtual USB drive's data. When you interact with the LocalFileSystem, code inside Mbed stores magic values in certain registers, then issues a "bkpt" instruction to manually trigger a debugger break. The interface chip detects this breakpoint, carries out the requested operation (e.g. reading from a file), stores the data into the LPC1768's memory, and then unpauses the MCU. This Rube Goldbergian mechanism (using debugger breakpoints to transfer data) is called semihosting, and can also be used to transfer text between a host PC and a microcontroller (replacing a UART terminal). It was used on a lot of earlier ARM dev tools, but seems less common these days, perhaps because it has serious performance penalties.

However, there is a pretty major problem with LocalFileSystem as currently implemented: sleep mode. When the LPC1768 goes to sleep, the mbed interface debugger gets disconnected, and the semihosting connection is broken. This means that LocalFileSystem, and other semihosting features, will no longer be operational.

This is a serious issue because there are a lot of potential places the MCU can go to sleep. If you are using mbed-baremetal, sleeps will only really happen when you call ThisThread::sleep_for() or one of the other sleep functions, so you just need to avoid those (wait_us() is safe). But if you are using mbed-os, sleeps occur whenever the idle thread runs -- basically, whenever a blocking operation like a sleep or a wait for a mutex happens and there is no thread that's able to execute. So, if you really want semihosting to work, you need to ensure that there is always at least one thread able to run at any given time in your application. One workaround is to create your own idle thread with a higher priority than the Mbed idle thread which does not sleep:

[[noreturn]] void sleeplessIdleFunc()
{
	while(true) {}
}
Thread sleeplessIdleThread(osPriorityLow, OS_STACK_SIZE, nullptr, "Sleepless Idle Thread");

void main()
{
    sleeplessIdleThread.start(&sleeplessIdleFunc);
    ...
}

Despite these issues, LocalFileSystem might still be useful if you just want to make a simple application which saves data onto the dev board memory, with minimal code and no external storage. For an example of how to use this API, see the Mbed CE LocalFileSystem example!

Other Notes

TIM3 Usage

One of the 32-bit timers, TIM3, is used to implement the Mbed us_ticker. The other three timers, TIM0 through TIM2, are available for application usage.

Debugging the LPC1768 Dev Board

This dev board is a bit harder to debug than most Mbed targets. First of all, the debugging interface didn't exist until the latest interface chip firmware revision. So, make sure to do the "Dev Board Firmware Update" section first. Additionally, while pyOCD used to work with this device, a change in version 0.11 broke something, so only 0.10 and older work (and those versions only run on Python 2.7, blech!). So, as of 2022, the only supported debugger option is OpenOCD (with some workarounds implemented by Mbed CE). If you install OpenOCD and use -DUPLOAD_METHOD=OPENOCD, you should be able to flash and debug the LPC1768 just fine.

Interrupts

The LPC1768 can make use of interrupts (InterruptIn) on any of the port 0 or port 2 I/O pins (on the dev board, that's every pin except p19 and p20). However, each port shares a single interrupt for all its pins, so performance might not be great if you have a lot of different interrupts firing on different pins, since the interrupt handler has to read the interrupt registers to figure out which pin(s) triggered the interrupt.

There are also four external interrupt (EINT0-3) pins which have dedicated interrupts, but these are not supported natively by Mbed. Note also that the EINT3 interrupt number is shared with regular GPIO interrupts, so only EINT0-2 are usable as truly dedicated interrupts.

Deep Sleep

The current Mbed OS implementation for this MCU does not support deep sleep, due to an LPC1768 issue which prevents the MCU from waking up if a debugger is connected when it enters deep sleep.

See AN10915 section 4.4.6 for details.

Disabling Semihosting on Custom Boards

If you make a custom board with the LPC1768 MCU, and you compile your code for the LPC1768 Mbed target, you will probably get random-seeming crashes. The reason for this is, operations like sleeping attempt to interact with the Semihosting API, which tries to communicate with the Mbed interface chip using BKPT instructions (see above). If this chip is not present, bad things happen.

To fix this problem, create a custom target (e.g. STANDALONE_LPC1768) with a custom_targets.json file like this:

{
  "STANDALONE_LPC1768": {
    "inherits": ["LPC1768"],
    "device_has_remove": ["LOCALFILESYSTEM", "SEMIHOST"]
  }
}

This turns off the semihosting features, allowing code to run without an interface chip present. Needless to say, the semihosting and LocalFileSystem APIs will be unavailable.

Using Ethernet with the Dev Board

The LPC1768 dev board includes an integrated Ethernet PHY, but needs external magnetics and an ethernet jack in order to actually communicate over the network. One easy way to do this is using a SparkFun MagJack breakout, hooked up per the diagram here.

Datasheets