Massive Data Loss … and Recovery!

The lull in posting to this blog is because I suffered a massive data loss, from which I eventually made a full recovery. This entry will describe the problem and how I solved it. First, I’ll start with a description of my system:

I built this machine from scratch last July. It contains:

  • MSI-7666 X-Power BigBang motherboard
  • Intel Core i7-960
  • 12GB of very fast memory
  • 120GB Corsair CSSD-F120GB2 flash disk, used to hold the operating system (Win7)
  • 4 1-TB Seagate Constellation SATA disks
  • 2 Nvidia GTX 470 graphics controllers, driving 2 HP LP2475w displays
  • Realtek sound controller
  • LG Blu-ray/DVD/CD reader/writer
  • Corsair power supply
  • Housed in a nice Corsair tower
  • The whole thing is protected by a CyberPower CP1500AVRLCD

Yes, it is a kick-butt machine, and maxes out most of the categories in the Windows experience ratings. Putting the operating system on a flash disk makes a huge difference in speed.

I bound the 4 disks as two 2-TB RAID0 volumes using the Intel RAID controller. I didn’t realize it when I built the machine, but the “Intel Rapid Storage Technology” RAID controller on the motherboard (in the ICH10R) is not a real RAID controller, at all – everything is done in software by their driver (the ICH10R just hides the drives from the rest of the system). So, it is a Fake-RAID controller. Had I known this, I would have never, ever, used it. My bad, for not completely researching the configuration and capabilities of my machine.

I use this machine for work, so to protect my client’s data from theft, all drives (including the Corsair) are encrypted with BitLocker.

Here’s what happened:

On Sunday night, I needed to reboot my system as a result of some updates. The system started to boot Windows, flashed a blue screen too fast to read, and reset itself. After trying a few more times to get it to boot, I turned off the machine and went to bed.

Monday morning, I tried again, and got the same result (wasn’t it Einstein that once said that the definition of insanity was trying the same thing over and over, and expecting a different result?). Looking more closely at the BIOS POST (Power-On Self Test) screens, I noticed that the Intel RAID page was showing that my two RAID0 volumes had failed. Not good.

I tried booting the Win7 installation CD, and tried to get it to recover my system, but it kept coming back with “unknown error” and failing. Thanks guys.

I needed to get the system to boot, so I could examine the drives. When I initially installed the system, I purposely left 23GB of unpartitioned space on the system disk, for exactly this sort of emergency. I installed a fresh copy of Win7 in the unpartitioned space, and booted up the machine. Not surprisingly, the data volumes were nowhere to be found, but I verified that the system partition was OK.

I did a lot of searching on Google/Bing, looking for people with similar experiences. I did find one here: ( I followed the directions, but I was not getting the same results with the TestDisk program. I tried the latest and greatest version of TestDisk, and the current beta version. No luck.

I then embarked upon a program of downloading and trying more than half a dozen different commercial and freeware disk recovery products. Not one of them could even diagnose the problem; much less do anything about it. I was on my own.

At this point, I had two RAID0 volumes again (from following the instructions on web site, above), neither or which would mount in Windows. Disk Manager couldn’t detect a file system, so only physical (raw) I/O was possible.

I decided to start from first principles and work my way toward the problem. When I built the system, I chose the GUID Partition Table (GPT) as the partitioning scheme (as opposed to Master Boot Record), formatted the volumes with NTFS, and then enabled BitLocker. I know that Windows places a “protective” MBR in sector zero of a GPT disk, which helps older disk utilities to recognize the disk as having been formatted, even if they don’t understand the GPT layout. The protective MBR contains just a single partition table entry, which describes the entire disk. The next sector contains the GPT header, followed by entries for each of the partitions.

I downloaded the demo version of WinHEX to look at my volumes, and I found that the MBR had been squashed by the BIOS when I bound the disks back into RAID0 volumes. The MBR still had the 55 AA signature at the end of the sector and a disk signature, but that was it. The next sector was indeed the GPT header, and I could see the GPT partition entries (one for a 128MB Microsoft reserved partition, and the other was my data partition consuming the rest of the disk). I couldn’t see any of my files, because the data partition was encrypted, but I did see the BPB at the beginning describing the partition and specifying the file system as –FVE-FS- which is what Microsoft uses on a BitLockered volume.

When Windows looks at a disk, it always looks at sector zero for the MBR, and this MBR didn’t have any entries for partitions. Hmmm. What if I create an entry in the partition table? Then Windows would at least see the volume, and maybe it would look further at the GPT entries. It was worth a shot.

I entered the changes to sector zero with WinHEX, but it wouldn’t let me write the changes to the disk, because this was a demo version. Sigh. Back to Google/Bing, and I found the HxD disk editor, and it allowed me to edit the disk.

Here are is the structure of the MBR:

 // Cylinder, Sector, and Head fields

 typedef struct
     UCHAR     head;        // Head number
     UCHAR    sector;       // Head is bits 0:5, bits 6:7 are bits 8:9 of cylinder
     UCHAR    cylinder;    // Bits 0:7 of cylinder
     } CHS, *pCHS;
 // Partition Entry
 // Each MBR disk has a table of 4 partition entries near the end of the
 // first block on the device

 typedef struct
             UCHAR not_used:7;    // First 7 bits are unused
             UCHAR active:1;          // Partition is bootable
         UCHAR status;               // Entire value

 CHS start_chs;              // Address of first block of the partition in CHS format
 UCHAR type;                // Partition type
 CHS end_chs;              // Address of last block of the partition in CHS format
 ULONG start_pbn;    // Physical block number of the beginning of the partition (aka "LBA")
 ULONG size;               // Number of blocks in the partition
 // Master Boot Record
 // This is the first block on a boot device

 typedef struct
     UCHAR code [440];                                        // Initial Program Load code
     ULONG disk_sig;                                            // Disk signature
     USHORT disk_sig_2;                                     // Rest of disk signature
     PARTITION_ENTRY partition_table [4];   // Disk partition table
     USHORT mbr_sig;                                          // MBR signature
     } DISK_MBR, *pDISK_MBR;

All I needed to do was fill in the first partition entry. The disk was not bootable, so I didn’t need to set the Active bit in the Status byte. The start and end CHS fields haven’t been used by anything in probably a decade, so I could ignore those, too. The only fields that are important are the Type field, which must be set to 0xEE for a GPT protective MBR entry, the Starting sector, and the Size of the partition.

So, using HxD, I set the Type field to 0xEE (magenta), the Start sector to 0x01 (yellow), and the Size to 0xFFFFFFFF (green). Wow, just 6 bytes. Here is what it should look like:

Of course, the very next thing I did was to backup all the important data from my two volumes to a 2TB external drive I just bought from WalMart for $130. It is fitting that I’m performing my first backup on this machine on World Backup Day.

The next thing I’m going to do is buy a 3ware RAID controller, and ditch the crappy Intel Fake-RAID “controller”. The 3ware controllers are very, very fast and reliable, and I helped design it (I designed the host-controller interface), so I might as well use it.

Posted in Uncategorized | Tagged , , , | Leave a comment

Giving up on the ARM/Keil MDK

I now have a flat-spot on my head from beating it against the wall that is the ARM/Keil Microcontroller Development Kit (MDK), so I am taking the hint and I’m abandoning it. The MDK has a pretty nice IDE, an extensive library, and lots of samples, but the samples are all pretty much identical, just ported to different boards and CPUs. The library while powerful (supporting HID, Mass Storage, Audio (out), CDC (serial), and supposedly
vendor-specific classes), is woefully incomplete in that it does not support USB
isochronous IN transactions (data going from the device to the host), and the support in the framework is almost completely absent for vendor-specific – beyond allowing you to specify that your device implements vendor-specific commands and then requiring you to supply a vendor.h file. Nowhere in the documentation is there information on what you need to provide if you select the vendor-specific  class, nor are there any examples.

I sent questions to ARM technical support, but thus far, I have not heard back from them. I also submitted questions to NXP’s technical support, and did receive some responses, but one didn’t provide any more detail than what is provided in the marketing documentation, and the other (regarding vendor-class) claimed to have a .C file attached showing the usage, but there was no attachment. I requested the attachment and they responded very quickly; however the attachment was just a new version of usbcore.c (for use with IAR) with support for the vendor –specific device class, but again, nothing on how to use it. Sigh.

I have gone back to the IAR IDE even though it is less sophisticated than the MDK, and what do you know? There is a sample that does isochronous IN transactions. Somehow I had missed or forgotten this example. IAR provides a framework that is similar to that of the MDK, but it is a bit easier to follow. My next post will cover getting my firmware more-or-less running using the IAR tools.

Posted in Olimex LPC-P1343 | Tagged , , | Leave a comment

Starting From Scratch With The ARM/Keil MDK

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!
Posted in Olimex LPC-P1343 | Tagged , , | Leave a comment

USB Example for LPC-P1343

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

Posted in Olimex LPC-P1343 | Tagged , , | Leave a comment

IAR Embedded Workbench development kit

The examples in the Keil MDK won’t work without some changes (perhaps minor, perhaps major, but at this time, I don’t know). I chose to try the MDK first because it is much newer and far more comprehensive in terms of examples than what are available on the Olimex web site. Time to try Olimex’s examples.

Looking at the examples downloaded from the Olimex site that are specifically for the LPC-P1343, I see that they prefer to use the IAR Embedded Workbench 6.10 development kit. EW comes in three variants:

  1. 30-day evaluation edition. Fully functional, but only for one month
  2. Kickstart edition. Fully functional, but with code size limitations, and no time limit
  3. Full version. Of course, they don’t list the price on their web site, but I’ll bet it is beaucoup bucks! To be fair, it appears to be a rich development environment with good debugging support, but I don’t have the JTAG debugger so it won’t be useful to me.

The 30-day and Kickstart editions may be downloaded from

I looked up the size limitations on the Kickstart edition, and what do you know, the size limitation is 32KB, which isn’t a limitation at all for the LPC1343. So, I filled out the registration form (thereby guaranteeing that I can look forward to even more spam in the near future), received a confirmation email which contained a link to the download page containing my license key, and downloaded yet another 500MB development kit.

Wow, this thing is huge! It has 66,784 files consuming 1.67GB, with 2400 examples. The Keil MDK was 17,896 files consuming 1.2GB. The Keil IDE is a LOT more powerful than the IAR IDE.

I downloaded the LPC-P1343 examples, went into the \LPC-P1343_Examples\LPC-P1343_LEDs_Running_Light&Buttons directory and double-clicked on the .EWW file, which brought up the Embedded Workbench and loaded the project. On the Project menu, I clicked on Rebuild All, and the build failed. Someone at Olimex had used absolute paths to identify where some of the files are located. If you see an error in the output of the IDE referring to D:\PENKO_D\Penko_Projects_Olimex\ARM\LPC\LPC-P1343\Software\LPC-P1343_Examples\LPC-P1343_LEDs_Running_Light\LPC1343_Flash.icf
then edit the .EWP file, and remove the path, leaving just the filename LPC1343_Flash.icf and it will then build. Obviously, no one tested this before release. Very, very sloppy Olimex!

The build defaults to the Debug build, so I changed that to the Release build (because I don’t have a JTAG debugger), by clicking on the Projects menu and then on Edit Configurations, and selecting Release. This creates a sub-directory named Release, and puts the output file in the Exe subdirectory. The default output file has an .OUT file extension, and is 31KB. Copying the .OUT file to the board didn’t work. Having been through this with the MDK, I suspect that the CRC needs to be set. Well, that didn’t work.  Looking at the project options, I found an Output Converter tab, and configured it to create a binary output file Firmware.bin. I tried copying the Firmware.bin to the board, but that didn’t work, so I tried setting the CRC (with the LPCRC program I wrote about in my previous blog), and copied that to the board. No dice.

I was incredulous that someone would ship an example program that wouldn’t build! After thinking about it a bit, I reverted to the Debug build, set the Output Converter, set the CRC, and copied it to the board. Woo-hoo! It worked.  Obviously, the Debug project settings differ in some important way from the Release settings. Again, Olimex was extremely sloppy. Embarrassingly sloppy.

OK, so after an entire day, I was able to get the LPC-P1343 to blink its lights. I hope that this isn’t indicative of how the rest of the project will go!

Posted in Olimex LPC-P1343 | Tagged , , | Leave a comment

ARM Microcontroller Development Kit

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 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…

Posted in Olimex LPC-P1343 | Tagged , , | Leave a comment

Finding a starting point

Given that this firmware project is an enabler for a Windows device driver course, and is not an end in and of itself, I don’t want to spend more than the absolute minimum amount of time on the firmware. Therefore, I want to find some example code that is as close as possible to what I need, and hack in my changes. There just isn’t time to learn all the ins and outs of the ARM LPC1343 and write the entire USB stack myself.

I have located a lot of NXP ARM code on a variety of web sites, including that of Olimex
(each board has its own software downloads), NXP, onARM (registration required to access CMSIS sources),, and 32bitmicro. Unfortunately, each uses a different tool chain, and the tool chains appear to be incompatible; although much
of the code from NXP seems to support multiple compilers.

So, my next task is to identify an example that is close to what I need, and that will determine which tool chain I will use. Unfortunately, I haven’t found any examples that implement USB isochronous endpoints on the LPC1343. I have found some examples that do implement isochronous, but for other ARM chips with possibly different internal hardware configurations. I’m going to have to see what sort of commonality exists and
see if I can modify one of the LPC1343 examples to support isochronous. This will be a very tedious job, and I hate jobs that are tedious.

Posted in Olimex LPC-P1343 | Tagged , , | Leave a comment