Today, I thought I’d try to build the other examples provided by Olimex. Buoyed by my success last night in getting the blinky lights example to work, I jumped immediately to the most complex example: LPC-P1343_VirtualComPort_LEDs&Buttons, because I want to start working on the USB isochronous stuff. I set the OutputConvert tab in the Project-> Options to create Firmware.bin, and told it to build. I guess I should have known better, given the quality of the Olimex example firmware that I had encountered so far. Of course it failed. In fact, it failed to build, with the compiler returning 7 errors and 1 warning. Clearly Olimex hasn’t built their examples with the latest and greatest version of the IAR compiler (v6.10).
Most of the errors have to do with undefined identifiers, many of which reference the JTAG port. I’m not using the JTAG port, so I just commented them out in the source file. The remaining error is for an undefined field in a register structure, specifically, some field named BYPASS in the System PLL Control Register (0x40048008), SYSPLLCTRL_bit.BYPASS. Looking in my LPC13xx User Manual Revision 2, 7 July 2010, I do not see a field named BYPASS in the register. My initial thought was that the routine in the example came from an example for another processor, so I Googled/Binged 0x40048008, and received a lot of non-relevant hits about the 4004 and 8008 CPUs. Looking in the user manual, I see that they put a space between the two words, so I then
searched for “0x4004 8008”, and found Revision 00.10, 19 October, 2009 of the PRELIMINARY User Manual, where there is indeed a BYPASS field within the register.
OK, so it looks like someone wrote some code and headers using old, preliminary information about the LPC1343. I looked up the definition of SYSPLLCTRL_bit, and found it in iolpc1342.h, which comes with the IAR compiler. So, in this case the fault is with IAR for not updating their headers when the final version of the LPC1343 documentation was published and Olimex for not building the example with an up-to-date version of the IAR tool chain. I suspect that the missing JTAG definitions are also the result of this
same problem. Clearly, IAR and Olimex have quality control issues with their products.
I commented out the two lines of code in SYS_GetMainClk in the module main.c that made reference to the BYPASS bit, and it built with just one warning about a variable that was declared but never used. The project Post-Build action automatically sets the CRC in the Firmware.bin file, so I copied it to the board, and it worked – at least, it showed up as a
Communications Device Class (serial port) device according to USBview (located in the \Program Files\Debugging Tools for Windows directory), but it wasn’t completely compliant with the CDC spec, so the Windows CDC class driver didn’t get loaded. It also used some weird VID (0x15ba) and PID (0x0030) combination for which Windows does not have an .INF file.
Using USBview, I examined the USB configuration descriptors (under Options, select Config Descriptors, and then click on the device in the tree in the left pane). There appear to be some issues with the LPC1343 firmware, because USBview shows several Unknown Descriptors. Again, hardly surprising given the quality of the software from Olimex and IAR, but I suppose it could be a problem with USBview.
The important thing is that I now have a framework on which to build. More later