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
MOre on this thread... Have been trying to trace the problem and have found that if you create copies of the Readme.txt on the board it crashes after the 4th copy, think this might be a file name length problem because if you shorten the file name it allows more copying? Also I can copy larger files (6k tested) onto the drive and the properties report the correct values so ignor the comment about 1k size limit. Debugging using print statements to serial port has helped but interestingly the orginal problem with access time reoccurs if a print statement is inserted into the MSC_MemoryWrite function. Will report back if I get to the bottom of this!
We have found this problem and we will publish a modified example within the next few days. Reinhard
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.
"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
We have found this problem and we will publish a modified example within the next few days. Is the modified example already available for download? Michael
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