LPCxpresso: nice hardware made useless by bad software
Remember back in the mid-90s, when many of us used Microchip PICs for embedded control? Remember having to use a shoddy closed-source compiler, which only ran on one operating system/architecture? Remember having to use a particular set of tools, instead of whatever tools you were most comfortable with?
Fast-forward to 2010, and you can re-experience all these limitations with the NXP LPCxpresso board! This evaluation board for the NXP LPC ARM chips is...well, I'll let them speak for themselves:
This runs only on Windows, of course. Yes, folks, it's like 1995 all over again.Consensus among reverse engineers I've contacted is that the programming/debugging interface is cryptographically secured, to keep you from using it the way you want. (Edit: I've decided there's not enough evidence to support this claim.)
Not that Digikey tells you this before you buy, of course! At the time of this writing, even the LPCxpresso web site makes no mention of this, unless you drill down into the PDF Getting Started Guide. Fortunately, competing parts from both Atmel and ST Microelectronics have support for GCC and cross-platform programmers and debuggers. I'll be using these in my next design and sending the LPCxpresso back to the factory.
Update: Someone claiming to be from Code Red commented below, noting that they do have GCC support, but didn't address the other points (cross-platform compatibility being the main one). I based my initial complaints of "no command line compiler" and "no GCC support" on other users' summaries, since (not having Windows) I couldn't test that. My bad; these claims have been removed.
If Code Red does indeed provide cross-platform support (or OSS tools that could become cross-platform) I'll update this post!
Update 2: They do not, though they suggest I could run Windows in a VM. Missing the point, guys.
To be clear, I'm not a complete noob to embedded ARM systems, or Cortex-M3. Once I decided not to return this proprietary piece of circuit (because I'm terribly stubborn), I tried putting together a toolchain based on CS2009q3, writing a linker script, soldering on a USB connector, implementing the proprietary NXP checksum algorithm, chopping off the debug circuitry that I paid for and would sure like to use, etc. Never quite worked right - got consistent firmware corruption. My point is that I shouldn't have to do any of this stuff, or troll through forums trying to decide which contradictory answer is correct. I'm currently rather enamored with the mbed eval board, which, unlike the LPCxpresso, explicitly supports Mac and Linux out of the box.
Fast-forward to 2010, and you can re-experience all these limitations with the NXP LPCxpresso board! This evaluation board for the NXP LPC ARM chips is...well, I'll let them speak for themselves:
The LPCXpresso evaluation board is meant to be used only with the Code Red LPCXpresso, or Red Suite IDEs.
This runs only on Windows, of course. Yes, folks, it's like 1995 all over again.
Not that Digikey tells you this before you buy, of course! At the time of this writing, even the LPCxpresso web site makes no mention of this, unless you drill down into the PDF Getting Started Guide. Fortunately, competing parts from both Atmel and ST Microelectronics have support for GCC and cross-platform programmers and debuggers. I'll be using these in my next design and sending the LPCxpresso back to the factory.
Update: Someone claiming to be from Code Red commented below, noting that they do have GCC support, but didn't address the other points (cross-platform compatibility being the main one). I based my initial complaints of "no command line compiler" and "no GCC support" on other users' summaries, since (not having Windows) I couldn't test that. My bad; these claims have been removed.
If Code Red does indeed provide cross-platform support (or OSS tools that could become cross-platform) I'll update this post!
Update 2: They do not, though they suggest I could run Windows in a VM. Missing the point, guys.
To be clear, I'm not a complete noob to embedded ARM systems, or Cortex-M3. Once I decided not to return this proprietary piece of circuit (because I'm terribly stubborn), I tried putting together a toolchain based on CS2009q3, writing a linker script, soldering on a USB connector, implementing the proprietary NXP checksum algorithm, chopping off the debug circuitry that I paid for and would sure like to use, etc. Never quite worked right - got consistent firmware corruption. My point is that I shouldn't have to do any of this stuff, or troll through forums trying to decide which contradictory answer is correct. I'm currently rather enamored with the mbed eval board, which, unlike the LPCxpresso, explicitly supports Mac and Linux out of the box.
Labels: arm, lpc, proprietary