Mass Storage read/write performance on LPC18xx

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Mass Storage read/write performance on LPC18xx

1,020 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ngraum on Sun Nov 04 14:08:38 MST 2012
Hello, I am using nxpUSBlib v0.97 in host mode on the LCP1830 Xplorer development board. I am wondering if there are current known outstanding issues/todo's in the library that will provide substantial speed improvements with later releases. A little backstory:

In my application I wasn't seeing very good transfer rates (~30kB/s), so I wrote a small app based off the MassStorageHost example to benchmark nxpUSBlib. The application simply does loops of MS_Host_ReadDeviceBlocks or MS_Host_WriteDeviceBlocks, similar to the SD Card example provided for the Xplorer. What I found was maximum transfer rates not a lot higher than what I had been seeing.

I began poking around the library to see where the bottleneck could be. The first thing I noticed is that the LPC1830 was not actually running at its maximum clock rate of 180MHz. I modified CGU_Init() to run the processor at this speed and verified it was indeed running at 180MHz. This did increase my benchmarks, as one would expect, to values around 130kB/s.

Next I tried reading multiple sectors at once. I found that this greatly helped performance, which was now around 250-260kB/s. However, writing multiple sectors at once doesn't seem to be implemented in the library yet (the app freezes). If you look in the source for nxpUSBlib, it becomes apparant as to why due to the differences in implementation in PipeStream_LPC.c between Pipe_Read_Stream_LE() and Pipe_Write_Stream_LE().

Digging deeper, I found what appears to be a todo item in EHCI.c: Inside HcdDataTransfer() there is a comment which reads "/* For simplicity, this only queue one TD only */" with a call to AllocQTD, where QueueQTDs is commented out. I tried uncommenting it and commenting AllocQTD, but performance suffered slightly. There are other todo's to be seen in the code, particularly in Pipe_LPC.h (about things to implement later) as well as some in EHCI.c.

I don't want this to sound like a rant (nxpUSBlib is really quite a nice library to be provided free of charge). However, I would like to know, does the nxpUSBlib team maintain a list of known issues and their potential effect on performance and/or reliability of the library? I would be very interested in getting a copy of this information or at least what is planned for releases in the near future. Thank you!
Labels (1)
0 Kudos
Reply
4 Replies

949 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ngraum on Sun Feb 24 10:43:44 MST 2013
As another update, I've managed find why MS_Host_WriteDeviceBlocks fails with more than one sector. It has to do with the implementation of Pipe_Write_Stream_LE. All that I needed to do was change it to be more like how Pipe_Read_Stream_LE works (automatically clearing the endpoint once it becomes full), and multiple sector writes now work pefectly. The changes are below (I couldn't find a way to submit suggestions, but I could file this as a bug if that's preferred so it's tracked):

<code>
uint8_t Pipe_Write_Stream_LE(const uint8_t corenum,
                             const void* const Buffer,
                             uint16_t Length,
                             uint16_t* const BytesProcessed)

{
   uint8_t* DataStream = (uint8_t*) Buffer;
   if(BytesProcessed != NULL)
   {
      Length -= *BytesProcessed;
      DataStream += *BytesProcessed;
   }

   while(Length)
   {
      if (Pipe_IsReadWriteAllowed(corenum))
      {
         Pipe_Write_8(corenum, *DataStream);
         DataStream++;
         Length--;
      }
      else
      {
         Pipe_ClearOUT(corenum);
         while (!(Pipe_IsOUTReady(corenum)))
         {
            if (USB_HostState[corenum] == HOST_STATE_Unattached)
              return PIPE_RWSTREAM_DeviceDisconnected;
         }
      }
   }
   return PIPE_RWSTREAM_NoError;
}
</code>

After making this change I was able to see around 200KB/s transfer rates with -Os turned on. Yay!!
0 Kudos
Reply

949 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ngraum on Sun Dec 02 16:33:37 MST 2012
Just an update on this, I've been using 0.98 and the dual-host mode is working nicely on the 1830, nice work! Speeds are about the same as they were before, though.

I have found one issue I thought I should bring to light. MS_Host_ReadDeviceBlocks handles reading any number of 512-byte blocks from my USB stick just fine. However, MS_Host_WriteDeviceBlocks hangs with any number of blocks above 1. I'm just wondering if anyone else has run into this issue or if it is a known issue. I have a hunch that being able to write multiple blocks at once would improve transfer rates quite a bit.

Thanks for your ongoing support of this library!
0 Kudos
Reply

949 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by ngraum on Wed Nov 07 17:24:15 MST 2012
That sounds great, I look forward to the release!
0 Kudos
Reply

949 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by NXP_Support on Wed Nov 07 16:44:00 MST 2012
Hi ngraum,

Thank you for your detailed post. :)
We have found these same issues and will include some improvements in our upcoming release.  We understand there is a lot of work to still do on our USB library and we are continuing to develop and improve it. 
0 Kudos
Reply