Embedded Hacking Weekend 2

Tea, music, electronics and code.

I’ve gotten back into the ARM Cortex M3 embedded stuff (yes, again), specifically with the NXP LPC1768 chip.   I’ve had this Blue Board development board hanging around for a couple of years, and I’ve made a couple of attempts at getting some of the open source toolchains (e.g. CodeSourcery Lite) working with the Eclipse IDE and some extensions.

There was enough off-the-shelf-ism, and layers upon layers of abstraction that I never really dove in that much to understand what was going on under the hood, and thus had a hard time debugging anything when it went wrong.  Despite best intentions, the desire to hack around on the platform waned pretty quickly.  This time around I’m a bit more serious about things,  diving in a lot deeper than I have in my last couple of attempts.  I hope to share the details at a later time, but I wanted to talk a bit about where I’m heading with it.  Here are the highlights of what I’ve accomplished so far.

  • Built my own GNU toolchain using crosstool-ng (gcc and all associated tools) under Linux x86_64 (Scientific Linux 6.x) . This is a change from the Windows XP environment I had been using in previous attempts, and a change from using a pre-built toolchain (which nearly all of the online how-to documents suggest using).
  • Using newlib as a replacement for the GNU standard C++ library (ct-ng takes care of most of the details).
  • Adapted a borrowed Makefile from one of the many different example projects I’ve run across.
  • After equal parts flailing, reading, learning, and experimenting I finally put together a bastardized linker script that seems to work, and I have a much greater understanding of that whole mechanism and how it integrates with the compiler, newlib, etc.
  • Unearthed my OpenOCD debugger setup exactly as I had been using it last year – it’s running on a Windows machine and talking to a USB JTAG interface.  It’s accessible over the network when it’s running, so I can telnet into it and execute debugger commands to flash new code into the chip, reset the part, read and write memory, etc.
  • Ported some old skeleton code to this new environment.  This is basically the same code that I left off experimenting with last year, and basically connects two of the on-board UARTs back-to-back.
  • Built the full NXP CMSIS LPC17xx driver library under my Linux environment after a fair amount of un-Windows-ing the build system.  This has reference drivers for all of the hardware on the LPC17xx, so this will save a boatload of time not having to re-invent the wheel.  I’m not wild about the coding style, but one cannot look such a generous gift horse in the mouth.
  • Successfully linked the statically-built CMSIS library to my skeleton code, and successfully got interrupt-driven I2C working in my code using their I2C library.
  • Wrote some rough 24LC256 EEPROM driver code which uses the I2C library; successfully reading/writing the EEPROM on the BlueBoard.

Still lots I’d like to do, though:

  • Continue integrating CMSIS stuff; get rid of the UART driver I have in my code and use theirs.
  • Fully integrate newlib’s system functions
  • Consider getting Eclipse going again, since I do generally like working in that environment.  This time I think I’ll stick with a Makefile-based project instead of using the gnu-arm-eclipse builder tools.  It’s just too hard to know what’s really going on with those, and seemingly 50 different buried GUI menus where settings need to be made.
  • Get gdb working for debugging!  This one is pretty huge.  At one point last year, I did have remote gdb working with the Eclipse environment, which gave me a pretty nice visual debugger environment.  That’s ideal, and I’d like to get back there.  If I don’t go the Eclipse route, maybe see if going old school with ddd is an option in a cross-compiler environment.
  • Integrate FreeRTOS or some other available RTOS like eCOS (though that’s pretty old at this point).

This is easily the most depth and progress I’ve made on this thing yet, and it’s satisfying to dig into a smaller embedded processor again.  Much of my professional work has moved to larger ARMs running on Linux, and while that has plenty going for it, it still lacks the directness of writing code to run right on the bare metal.  If anything feels like old-school hacking on my old Atari or the early DOS PC days, this is it.  I do have a specific goal in mind with this, but I’m going to hold off on providing details about that for now… but stay tuned!

Here’s some thrilling debug output dumping the first 256 bytes of the on-board EEPROM chip:


Tangent Audio LPC17xx Skeleton
wrote i2c addr=00C0 len=14
0000: DE CA FB AD 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  ................
0010: 10 11 12 13 14 DE AD BE EF 19 1A 1B 1C 1D 1E 1F  ................
0020: 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F   !"#$%&'()*+,-./
0030: 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F  0123456789:;<=>?
0040: 54 68 69 73 20 69 73 20 61 20 74 65 73 74 4E 4F  This is a testNO
0050: 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F  PQRSTUVWXYZ[]^_
0060: 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F  `abcdefghijklmno
0070: 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F  pqrstuvwxyz{|}~.
0080: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
0090: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
00A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
00B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
00C0: 54 68 69 73 20 69 73 20 61 20 74 65 73 74 FF FF  This is a test..
00D0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
00E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
00F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................

2 thoughts on “Embedded Hacking Weekend

  1. Reply Alan Feb 20, 2013 9:54 AM

    Hi Steve,
    I discovered your site today thanks to the microscope post at HackaDay.

    I used LPC1768 (mbed board) some time ago and then I discovered a RTOS called NuttX. NuttX is posix-like RTOS and follows Linux file-system standard including a shell terminal. Search for it on google and you will discover interesting things about NuttX.

    I implemented an emulated steer-by-wire system controlling a force-feedback joystick (yes, NuttX has USB host support) using LPC1768:
    https://www.youtube.com/watch?v=z_-RAFdQd0s

    It all spent less than 64KB of Flash.

    I hope you appreciate it.

    []‘s Alan

    • Reply steve Feb 22, 2013 4:50 PM

      Thanks for the tip on NuttX! I took a look through the website today, looks pretty nice. I may pull the code down soon and see if I can get it going.

Leave a Reply