This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

USBMem Mass Storage example quirks

Hello experts,

I have been testing the Mass Storage example for the MCB2140 and found some strange behaviour.

Example, the storage shows 14kB of space but if I try and copy a 3kB txt file the board crashes. File transfers appear to be limited to 1kB at a time?

In addition I attempted to modify the example so that the storage was based on SPI FLASH. I copied the Disk Image to the Flash and redirected the MSC_MemoryRead/Write command to FLASH.

Reading works fine and the test file appears in windows explorer. But writing fails due to some timing constraint.

This timing problem can be recreated by just putting a small delay inside the MSC_MemoryWrite function of the example code.

{int counter = 200; while(counter--);}

My thoughts are that the Mode Sense(6) command as not been implemented so no Flexible disk page data is offered giving transfer rate caperbility.

Would appreciate your experiences on this.

Many thanks,

Malcom

Parents
  • Hi Reinhard,

    Thanks for that, I was just in the process of boxing up the MCB4140 to send back to you as my testing has revealed more problems....

    Yesterday I was able to write files larger than 1K to the device, today I cant? Obivously the bus timing is critical but I'm just using an unmodified version of your example code to try and find the problem. At the moment the errors seem completley random but all relate to the Write handling. I guess either bus timing, access time or other CBWs arriving during the Write stream data are corrupting the isr sequence that has been implemented.

    To get round the access time problem start processing the first write data packet and just NAK the USB messages until you are ready for the next packet.

    I have no clue why yesterday I could write 3k files and today I cant, it doesn't give me much confidence about using this chip...

    If I find anything else I'll get back. Looking forward to your new USB code in a few days time. Please post here so that I'll know it's ready.

Reply
  • Hi Reinhard,

    Thanks for that, I was just in the process of boxing up the MCB4140 to send back to you as my testing has revealed more problems....

    Yesterday I was able to write files larger than 1K to the device, today I cant? Obivously the bus timing is critical but I'm just using an unmodified version of your example code to try and find the problem. At the moment the errors seem completley random but all relate to the Write handling. I guess either bus timing, access time or other CBWs arriving during the Write stream data are corrupting the isr sequence that has been implemented.

    To get round the access time problem start processing the first write data packet and just NAK the USB messages until you are ready for the next packet.

    I have no clue why yesterday I could write 3k files and today I cant, it doesn't give me much confidence about using this chip...

    If I find anything else I'll get back. Looking forward to your new USB code in a few days time. Please post here so that I'll know it's ready.

Children
  • "doesn't give me much confidence about using this chip..."

    Do you also have doubts about the chip itself, or is it just the software?

  • The chip is fine. It is just software.

    Reinhard

  • Hi Neil,

    I've had quite allot of experience using various USB chips. I developed a Mass Storage Device on the Infineon C164 before this and there is more to USB than software. The manufacturer chooses the level of access to the bus protocal and passes a subset of the transfers to software which might or might not give access to the bit you're trying to affect.

    USB code is very much chip specific.

    An example of this is the SPI and SSP buses on the LPC214x,

    SPI code running on SPI0 cannot be used without modification on the SSP used in SPI mode (effectley SPI1) as the SSP is buffered which corrupts the normal SPI bit bashing methods.

    Thanks,

    Malcom