Beginning LPC1114FN28 with Arch

It's cool that LPC1114FN28 based on ARM Cortex M0 uses DIP package. We enjoy playing LPC1114 with a breadboard, wires, LEDs and etc. And programming LPC1114 is quite easy with an Arch as an mbed interface. To download a new binary into LPC1114 is just to drag-n-drop the binary file into "MBED" drive.

Arch&LPC1114

Hardware

Use Arch as an mbed interface and connect Arch with LPC1114 through SWD interface or UART interface.

pins

ArchPin Function
P0_11nRESET
P0_12SWCLK
P0_13SWDIO
P0_18RX
P0_19TX

Turn an Arch into an mbed interface

Arch is not just an mbed enabled development board for rapid prototyping, but also an mbed interface(SWD/JTAG debug adapter, USB2UART bridge). Turning an Arch into an mbed interface is quite easy.

  1. Download mbed interface firmware for Arch.
  2. Connect Arch with PC, long press Arch's button and replace firmware.bin with the new firmware in "CRP DISABLD" drive.
  3. Quick press the button. "MBED" drive will pop up.
  4. Install the mbed interface driver to enable USB2UART function

Development

  1. In "MBED" drive, there is a "MBED.HTM" file which will lead to mbed.org.
  2. Add LPC1114FN28 to mbed compiler.
  3. On mbed compiler, it's easy to write code, import libraries and share programs.
  4. Compile and download a binary into "MBED" drive. The program will run!

compiler overview

Resources


Report

7 comments on Beginning LPC1114FN28 with Arch:

09 Feb 2014

This is a great concept of an mbed interface for a DIP chip without USB bootloader. Some weird problems occurred though: It worked for me only a couple of times. I have set everything up exactly as described in the article above and managed to flash an SD data logger program on an LPC1114FN28, which worked perfectly fine. After debugging and flashing it a couple of times and it stopped working out of a sudden. The strangest thing is that a simple blinky program can still be flashed on the LPC1114 and still works (also with different GPIO pins), but the more complicated things involving peripherals like UART or SPI just don't. Since I own a second chip I started using it and exactly the same problem occurred again. Is it possible that the chips got bricked in some way?

Does anyone have an idea or had similar trouble with this setup?

Arthur

10 Feb 2014

Hi Arthur,

It seems that the interface firmware has a bug, drag-n-drop larger than 4k binary is not supported. A solution is exporting the program to keil project, and programming lpc1114 using keil.

I will try to solve the bug. And the official mbed interface project is on https://github.com/mbedmicro/CMSIS-DAP, a fork for LPC11U24 is on https://github.com/xiongyihui/CMSIS-DAP/tree/lpc11u24. You can get involved with it if you like to.

Best, Yihui

10 Feb 2014

Hi Arthur,

I just fix the bug and update the interface firmware. Re-download the firmware and have a try. : )

Best, Yihui

11 Feb 2014

Dear Yihui, thank you very much for fixing the Arch firmware! My LPC1114 breadboard data logger is working perfectly fine now :) /media/uploads/insanity_wolf/lpc1114fn28_sd_light_data_logger_with_arch.jpg

All the best, Arthur

12 Feb 2014

Hi Arthur,

Well done! It seems that you used a extra usb2uart module. The Arch board contains drag-n-drop programming and usb2uart functions at the same time. Install the interface driver(http://mbed.org/handbook/Windows-serial-configuration#1-download-the-mbed-windows-serial-port) to enable usb2uart function.

  • Arch P0_18 - RX
  • Arch P0_19 - TX

Best, Yihui

12 Feb 2014

Hi Yihui,

thank you for the great advice. I tried it out and it worked immediately. Very convenient to have SWD and UART on one device... Learned something again ;) Looking forward to building more exciting stuff with those ARM chips.

Cheers,

Arthur

10 Jun 2014

Hi Yihui,

If I were to use the LPC11U24FHI33/301 (package: HVQFN33 [5x5]) with the ID 0x2988 402B instead of the LPC11U24FBD48/401 (package LQFP48) with the ID 0x2980 002B as the interface processor, would there need to be a change to the interface firmware? Despite the fact that the processors are basically the same, I am encountering a reason to believe that, not only is the Target ID important, but the interface ID is equally important.

Sincerely,

Aron

Please log in to post comments.