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
Yes it is part of CARM V2.40. Reinhard
Hi Reinhard, The USB write problem is still present in the CARM 2.40a release. If you want to write to Flash then the MSC_Write function fails due to a time out. Just enter a 200 instruction wait to test for yourself. Looking forward to the next release :-) Cheers, Malcom.
Hi all, I've also observed this problem, and developed a (horrible, but functioning) workaround: In MSC_MemoryWrite(), store the data to a buffer (64Bytes is sufficient, since that's the max USB bulk packet size), store the write address and data size, and set a "do I need to write to the MMC/SD?" flag in global scope. In both USB_ReadEP() and USB_WriteEP(), just after the variables are declared, call an "MMC write servicer" function, then call either a totally blank function or putchar(). (these can be done in reverse order, but they must be done right here and you can't have even a single additional function call between them and the rest of the function's code...) In your new MMC write servicer function, check the global "do I need to write to the MMC/SD?" flag, and if its true, perform the SPI/SSP data transfer and reset the flag. (data has now been written to the MMC/SD) I don't have a clue why this works, as I've never developed an embedded system before, so if you have any insight, please speak up! It's very slow, and took 13 minutes to store a 16MB video file (maybe because my naive MMC_Write() function has to read a 512B block and update only 64B at a time every time a 64B (or less) data write segment comes in from Windows...).
I've also been stumped about why neither the original demo nor my modified version allow the Windows disk format utility to format the memory (RAM, and MMC respectively) for Fat16/32. If I stick the MMC into a USB-based card reader, then Windows can reformat it, but through the demo/modification, the format utility hangs, then fails. Any input from the Keil Apps team on this one?
It depends what demo code you are talking about. The USB Mass storage device example that Keil wrote has no handling for formatting media. This command is part of the SCSI 3 specification which is a seperate layer from the USB handling. The MSC write problem is a different problem. SCSI spec includes a Read Format command where you are given the opportunity to tell windows about the media, specifying access time and spool time. Sending the correct information to this command would prevent windows from timing out the write command so quickley but you could fudge it by reading the data into a buffer and stalling the endpoint whist you deal with it. Keil said some time ago that they had fixed the access problem but the current demo code still has the same problem. They also said that some FAT/MMC code for the MCB2140 dev board would be available in October so I guess that are busy fixing the problems as their MMC code wont work either. Either way, good luck. Malcom