Hacking an existing example seems like a difficult proposition, so I decided to RTFM and create a project from scratch. The ARM/Keil MDK environment seems to be a lot more sophisticated than the IAR IDE, so that’s where I’ll start. One big complaint about the IDE, is that the wheel button on my mouse doesn’t scroll the source code windows.
I started up the uVision4 IDE, clicked on Project->New uVision Project, gave it a starting directory and a name (‘Test’ seemed reasonable). It then brought up a dialog box to allow me to select the target device, so I picked the NXP LPC1343. It then asked me if I wanted it to copy the CPU boot code into the project. Hell yes I do! I know from lots of experience, that writing CPU boot code is a pain in the butt and would require me to hook up my logic analyzer, read hundreds of pages of documentation, and then post lots of questions on various internet forums when the chip didn’t perform like the documentation specified it would. Using their CPU boot code will drastically reduce my frustration.
To make things easy, I’m going to create firmware that makes maximum use of the built-in wizards and libraries. I want to gain some experience with USB firmware in this environment, so I’m going to make the board appear as a simple HID device. The manual
instructs the user to copy the source files from the RTX_HID sub-directory under \ARM\Boards\…\…\RL\USB. Looking through the \ARM\Boards directory, there aren’t any boards from Olimex that are supported. This shouldn’t be a problem because I don’t need to talk to anything outside the CPU (USB support is built-in). Obviously, I need to start with code written for the LPC1343, so I selected the C:\Keil\ARM\Boards\Keil\MCB1000\MCB1343\RL\USB\Device\HID directory, because it is the only supported board that has an LPC1343 on it.
I copied the *.c and *.h files to my project directory (I didn’t copy the startup_LPC13xx.s (CPU boot code) from the board directory, I am going to use the one that the project wizard put into my project for me), and added the *.c files to my project by right-clicking on “Source Group 1” in my project tree, and selected Add Files to Group.
Step 4 in “Using the RL-USB HID Template” help provides instructions on configuring the RL-USB software stack, and makes reference to the file usbcfg.h. Well, that file was not part of the template code. Looking at further steps in the instructions, there are references to other files that don’t exist. Sigh.
OK, I’ll just take the code as is, and try it. I clicked on the Build button, and received a bunch of object files – and lots of link errors. I suspect there is a missing library reference in the project. Looking further ahead in the instructions to step 9, I am instructed to change the project options to use some RTX Kernel. So, I set that, pressed Build again…
and received even more link errors. The ARM/Keil MDK documentation may be
voluminous, but it is certainly not complete!
I removed the RTK Kernel option, because there were fewer link errors without it. I then closed my project and opened the project that was the source of the files for my project. Listed in the project tree was USB_CM3.lib. Ah ha! I closed the project and went back to my project, right-clicked on ‘Target 1’ and selected Add Group…, and created a group named Libraries. I then right-clicked on the Libraries group, and selected Add Files
to Group ‘Libraries’, and a file selection dialog box popped up. I navigated to C:\Keil\ARM\RV31\LIB, changed the file type to ‘Library’, and selected USB_CM3.lib.
I clicked Build, and it linked without errors. I looked in my Test directory, and all the files were there, including the objects and lots of other generated files. I guess you have to tell it where to put the output files. Wading through the mass of files, I started looking for my firmware. Of course, it created a Test.axf (ELF) file, which isn’t useful as far as the LPC1343 is concerned, because the LPC1343 doesn’t understand ELF. I remember seeing something about a tool that Keil provides for converting from .AXF to .BIN. It is named FromELF and is in C:\Keil\ARM\BIN40. Using the command “C:\Keil\ARM\BIN40\fromelf.exe –bin test.axf –output Firmware.bin” gave me a file suitable for the LPC1343. I copied the firmware to the board, and it didn’t work… Oops, my bad, I forgot to set the CRC. Using the LPCRC tool, I set the CRC, copied the firmware to the board, and it worked – at least it showed up as a HID device.
I ran the HID test program (C:\Keil\ARM\Utilities\HID_Client\Release\HIDClient.exe),
and I was able to control the LEDs by clicking on the check-boxes in the application.
Pressing right-most button on the board will also register as input button 0. The mapping of the LEDs on the Olimex LPC-P1343 is not quite the same as the ARM MCB1343, so only LED bits 4-7 work. Also, the “sense” is backward; if a bit is on, then it turns an LED off.
Looking through some of the source files, such as usb_config.c, there is an interesting comment in the beginning: <<< Use Configuration Wizard in Context Menu >>>. Hmm. I right-clicked on usb_config.c in the project tree, but there wasn’t any Configuration Wizard in the context menu. I guess their definition of what constitutes a context menu
is different from the rest of us. However, I did notice a tab below the source window labeled Configuration Wizard. Clicking on the Configuration Wizard tab, I found a nice tree control for various options related to the USB configuration (naturally), which can be selected and edited.
I then proceeded to look at the Configuration Wizard tab for each of the source files in my project. Hey! This is pretty cool! I went back to the Configuration Wizard for usb_config.c, and clicked on the value for Manufacturer String and gave it a new string, and likewise for the Product String. Rebuilt the firmware, and copied it to the board, and ran it. USBview
showed the changes I made using the Wizard. This is starting to show some promise.
So, what did I learn through all this?
- The ARM/Keil documentation isn’t accurate
- A little bit about the IDE
- Creating and building projects
- The Configuration Wizard is pretty cool and allows you to make changes to their code without actually changing their code
- Windows PowerShell does not like drives showing up and disappearing beneath it. Once a drive disappears, and then reappears it is not accessible again via PowerShell. Jeez, what a bunch of crap!