I have decided to start with the examples provided by ARM, and therefore I will be using their Keil (now a part of ARM) Microcontroller Development Kit (MDK). The Lite version is free, and may be found on the ARM web site, but requires registration. The MDK includes an IDE, lots of documentation, and a boatload of example programs for a variety of ARM processors and development boards.
When installing the MDK, I took all of the defaults, except I did not have it install the driver near the end of the installation process. From what I can tell, the driver is used for downloading the firmware for a lot of different boards and chips using the JTAG interface. The LPC1343 looks like a flash disk in program mode, so that wasn’t necessary.
I decided to start with the USB HID example in the C:\Keil\ARM\Boards\Keil\MCB1000\MCB1343\USBHID directory. I double-clicked on the HID.uvproj file, which brought up the IDE. On the Project menu is the Build command. The MDK has a USB class library that supports CDC (serial port), HID (Human Interface Device), Mass Storage (flash disk), Audio (speaker and microphone), and Vendor (which allows you to create your own custom commands) classes.
Clearly, the Audio class supports isochronous endpoints, so once I have gotten familiar with the MDK’s development environment, I will play around with the Vendor class and try adding an isochronous endpoint.
In the meantime, I have built the HID example, but I don’t see anything that looks like a firmware bin file. The Flash subdirectory contains quite a few files, including the object files, linker map, and so on. When I build the HID example, the IDE outputs seem to indicate that the output file is named HID.axf, the code was 5072 bytes, and the data was about 1K. Looking at HID.axf with Notepad, I can see that it is an ELF file, which the LPC1343 won’t understand (and is too big to download anyways; remember, the LPC1343 only has a 32KB flash memory) the HID.axf file is 71KB, so it clearly needs some sort of post processing. Time to RTFM.
After a little poking around, I found C:\Keil\ARM\BIN40\FromELF.exe which converts an ELF (Executable and Linkable Format; an old Unix System V ABI (Application Binary Interface) specification used by a lot of CPU vendors) file into a bin file that the LPC1343 wants. Using the command “FromELF –bin –output Firmware.bin HID.axf” gave me a bin file that I copied to the LPC1343. I put the board in ‘run’ mode, and … no joy, the board still looks like a flash disk. Clearly, there must be more to creating the Firmware.bin file.
After a lot more poking around, I found section 19.7 “Criterion for Valid User Code” (page 292) of the LPC1311/13/42/43 User manual, which specifies how the LPC1343 determines whether or not the Firmware.bin file is valid, and FromELF does not do the magic (writing a CRC to the file). Really? “Hey, let’s create a big elaborate IDE for building software for our platform, but we’re only going to provide 95% of what the users need, and let them write the rest.” I am speechless. Who would consider this a valid design decision?
After a great deal of poking around, I found a tool named LPCRC which will write the CRC to the Firmware.bin file created by FromELF. You need to download the LPC1343 Code Base from microBuilder.eu. You will find the tool in \LPC1343CodeBase\tools\lpcrc\bin directory.
After setting the CRC, I copied the Firmware.bin file to the development board, I put it into ‘run’ mode (I removed the jumper and pressed the reset button). The flash disk disappeared, and was replaced by a HID device. Woo-hoo! There is a simple Windows application named HIDClient.exe in C:\Keil\ARM\Utilities\HID_Client\Release. I ran the program, used the drop-down box to select the board, and then … it didn’t work.
The HIDClient program ran, but pressing the buttons on the development board didn’t do anything to either the LEDs or the HIDClient. The drop-down box on HIDClient allows you to select which device to use, and it listed Keil MCB1000 HID as the board. That is also part of the directory path where the example code lives. I chose that directory, because Olimex was not listed in the development boards under C:\Keil\ARM\Boards directory, and I thought C:\Keil\ARM\Boards\Keil\MCB1000\MCB1343\USBHID might be close enough to the OLIMEX LPC-P1343, because they are both for LPC1343 chips. Well, it is close, but no cigar.
So far, the MDK is a bust in terms of getting a functional firmware example running on my LPC-P1343. Time to look elsewhere. The adventure continues…
Gadget Engineering 