This is a general question:
Has anybody successfully implemented the RTX USB MSC together with the MMC interface of FlashFS on an LPC2148 having a microSD card connected to SPI1 ?
I used \Keil\ARM\Boards\Keil\MCB2300\RL\USB_FlashFS\SD_File as a starting point.
SPI data rates are 400 kBit/s and 15 MBit/s (LPC2148 operated @60 MHz).
MicroSD card access via FlashFS itself works fine. Also USB MSC enumerates correctly (windows recognizes the device and shows it as drive).
But accessing the drive in Windows leads to erroneous behavior varying from XP to 7.
Are there general performance issues with the above architecture?
I would realy appreciate some hints from the USB / RTX Guru ...
Thank you very much in advance.
Oliver
It's working! It was the Task Stack Size. Had to be increased, the 0x200 bytes weren't sufficient.
This is a general problem: Lack of information about resource requirements of the RL-ARM code.
But, anyway, there's a new question now:
Using a 2GB microSD card it appears that only half the capacity can be accessed.
Windows format dialog reports 1,85 GB when the SD card is connected directly to the PC.
In contrast using the (SD-Card <-> SPI <-> MMC-Driver <-> USB-MSC) chain Windows format dialog only reports something like 951 MB (varying from card to card!).
Since the RL-ARM documentation says that SD Cards up to 4GB are supported by FlashFS, I assume "something" in the USB-MSC part?
Has anybody come across this, too?
Regards,
I don't use this code, but with quick look on the source,
1) USB host queries the capacity of the drive using ReadCapacity (or ReadFormatCapacity) SCSI command. This firmware processes this query in MSC_ReadCapacity or MSC_ReadFormatCapacity() (mscuser.c). In these routines, MSC_BlockCount variable holds the total number of blocks (sectors).
2) MSC_BlockCount is set up in the main loop of main() (memory.c) MSC_BlockCount = mmcfg.blocknr;
3) mmcfg.blocknr is read out from CSD registar of the SD card, as follows.
MCI_23xx.c BOOL mci_read_config (MMCFG *cfg) { ... ... /* Total Number of blocks */ switch ((rval[0] >> 30) & 3) { /* Bits 126..127 */ case 0: /* SD card, CSD v1.0 */ case 2: /* MMC card, CSD v1.2 */ v = ((rval[1] << 2) | (rval[2] >> 30)) & 0x0FFF; m = (rval[2] >> 15) & 0x07; cfg->blocknr = (v + 1) << (m + 2); // <------------ break; case 1: /* SD card, CSD v2.0 */ v = ((rval[1] << 16) | (rval[2] >> 16)) & 0xFFFF; cfg->blocknr = (v + 1) << 10; // <------------ break; default: return (__FALSE); }
Using debugger, trace the values of MSC_BlockCount and mmcfg.blocknr
As of CSD register, refer this chapter of the SD card spec www.sdcard.org/.../ 5.3.3 CSD Register (CSD Version 2.0)
Tsuneo
The setup of MSC_BlockCount in the Keil example is based on a fixed block size of 512.
This appears to be correct for SD cards up to 1GB.
As stated in the SD card spec, particularly for a 2GB card, the value returned in mmcfg.blocknr can be related to other block sizes as reported by mmcfg.read_blen .
Since the mmc_init() sets the block size actually used to 512 bytes, MSC-BlockCount has to be calculated as shown in my example:
void checkMicroSdCard(void) { MMCFG mmcfg; if (mmc_init()) { mmc_read_config(&mmcfg); MSC_BlockCount = mmcfg.blocknr * ( mmcfg.read_blen >> 9 ); ... } }
Now the correct capacity is shown in the Windows format dialog.