EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

LPC2368 USB MSC Device for SD/MMC card attached on a custom board.

Started by burhani95 June 29, 2013
Hello Everyone,

I am working on a project which involves detecting the SDCARD attached to the SD/MMC interface on a custom LPC2368 based board.

I have the LPC23xx MSC USB Bulk Only files from the NXP website. I tried out their code by generatinf and flashing the hex file and was successful in implementing it. Windows detected the device and I could see a Readme.txt file too. The size of the MSC device was 16KB.

I went through the code and found that the memory being treated as a MSC Device is actually a part of the RAM-16KB in the form a char type array of size 16KB-Memory[16KB].

In the main function of their code, the data is copied from the actual device (which is a DiskImage of 16KB stored in the Flash of the LPC2368) to the Memory[16KB] array in the RAM.

Using this, everything works great.

However, If I want the sdcard to beahve in a similar way, I would have to copy the entire sdcard to a local Memory[] type array too. The sdcard is 2GB in size.

I don't understand the work flow that I should consider for making the SDCARD contents appear in windows after it is detected.

If anyone has worked on this or have some guideline/suggestions to share, It would be wonderful, and I would appreciate it.

Reagards,
Yusuf Husainy

An Engineer's Guide to the LPC2100 Series

http://www.lpcware.com/content/blog/lpcxpresso-lpc11u14-usb-sd-card-exmple
On Sat, Jun 29, 2013 at 9:57 AM, burhani95 wrote:

> **
> Hello Everyone,
>
> I am working on a project which involves detecting the SDCARD attached to
> the SD/MMC interface on a custom LPC2368 based board.
>
> I have the LPC23xx MSC USB Bulk Only files from the NXP website. I tried
> out their code by generatinf and flashing the hex file and was successful
> in implementing it. Windows detected the device and I could see a
> Readme.txt file too. The size of the MSC device was 16KB.
>
> I went through the code and found that the memory being treated as a MSC
> Device is actually a part of the RAM-16KB in the form a char type array of
> size 16KB-Memory[16KB].
>
> In the main function of their code, the data is copied from the actual
> device (which is a DiskImage of 16KB stored in the Flash of the LPC2368) to
> the Memory[16KB] array in the RAM.
>
> Using this, everything works great.
>
> However, If I want the sdcard to beahve in a similar way, I would have to
> copy the entire sdcard to a local Memory[] type array too. The sdcard is
> 2GB in size.
>
> I don't understand the work flow that I should consider for making the
> SDCARD contents appear in windows after it is detected.
>
> If anyone has worked on this or have some guideline/suggestions to share,
> It would be wonderful, and I would appreciate it.
>
> Reagards,
> Yusuf Husainy
>
>
>

--
/* Jumping Flowers */
[Non-text portions of this message have been removed]

Hi Fx and everyone else,

Thanks for the help.

I went through the code in the given link and modified it to suit the LPC2368. I used the mmc/sdfatfs & USB-MSC implementation from NXP's site and the USB implementation from the link, mergeed it together and worked to make it work for the past 4-5 days.

In the link's implementation, which is for the cortex-m0 processor, in theMSC_MemoryRead() function, in mscuser.c, the disk_read() disk I/O api is called to read data from the SD CARD.

However, the link's implementation is using DMA transfers, which uses the same USB RAM that is needed for the USB part implementation.

Now, the problem is, I turned off the flag which is used for including all the DMA related code during the preprocessor stage, so essentially, the disk_read should perform in a manner expected from a non-DMA perspective. disk_read polls for a flag, waiting for it to be cleared, specifically the
MCI_Block_End_Flag variable. However, this is cleared only by a routine(MCI_DATA_END_InterruptService) called by the ISR of the SD/MMC subunit. This routine is called when DMA transfers are enabled, meaning it is associated with transfering the sdcard data from the FIFO to the USB-RAM(the same RAM to be used for DMA access, which is shared with the USB subunit, also in use).

However, the routine(MCI_FIFOInterruptService) called by the ISR, when DMA transfers are disabled, does not clear this flag at all, so disk_read would poll infinitely and never return.

So, I added a line to clear this flag, and disk_read did come out from the loop and return. But another problem that occurred was that the functioncheck_fs() returned failure which actually called the disk_read, and itself was called by auto_mount(), to be used for mounting when f_open()'ing an existing file. Hence, f_open fails and subsequent f_read() calls fail. I was doing f_read() to check whether it works or any disk related access api's work if I disable the DMA' transfers using the macro-#define MCI_DMA_ENABLED as 0 or 1 in the mci.h file.

The f_read, f_open works with DMA enabled, but then the disk_read() from the MSC_MemoryRead() does not work, in the sense that the disk_read never returns, maybe because the USB-RAM is shared with DMA subunit.

So I presume I cannot use both. But the f_open and family calls fail if I disable DMA. At this point, I haven't gone further to test the MSC_MemoryRead() calling the disk_read() function, beacuse, when DMA disabled, f_open ot auto_mount itself fails. And I haven't pinpointed this problem too, to the disk_read() called inside the auto_mount() called functions.

It seems the problem is copying data from the SD?MMC FIFO to the memory.

If anyone has faced a similar situation, I would appreciate their feedbacks, and also anyone else's.

Regards,
Yusuf Husainy.

________________________________
From: Fx
To: l...
Sent: Sunday, 30 June 2013 5:00 AM
Subject: Re: [lpc2000] LPC2368 USB MSC Device for SD/MMC card attached on a custom board.


http://www.lpcware.com/content/blog/lpcxpresso-lpc11u14-usb-sd-card-exmple
On Sat, Jun 29, 2013 at 9:57 AM, burhani95 wrote:

> **
> Hello Everyone,
>
> I am working on a project which involves detecting the SDCARD attached to
> the SD/MMC interface on a custom LPC2368 based board.
>
> I have the LPC23xx MSC USB Bulk Only files from the NXP website. I tried
> out their code by generatinf and flashing the hex file and was successful
> in implementing it. Windows detected the device and I could see a
> Readme.txt file too. The size of the MSC device was 16KB.
>
> I went through the code and found that the memory being treated as a MSC
> Device is actually a part of the RAM-16KB in the form a char type array of
> size 16KB-Memory[16KB].
>
> In the main function of their code, the data is copied from the actual
> device (which is a DiskImage of 16KB stored in the Flash of the LPC2368) to
> the Memory[16KB] array in the RAM.
>
> Using this, everything works great.
>
> However, If I want the sdcard to beahve in a similar way, I would have to
> copy the entire sdcard to a local Memory[] type array too. The sdcard is
> 2GB in size.
>
> I don't understand the work flow that I should consider for making the
> SDCARD contents appear in windows after it is detected.
>
> If anyone has worked on this or have some guideline/suggestions to share,
> It would be wonderful, and I would appreciate it.
>
> Reagards,
> Yusuf Husainy
>
>
>

--
/* Jumping Flowers */
[Non-text portions of this message have been removed]

I dealed with a similar problem long ago and decided tu just get rid of the
dma transfers for the sd cards and opt for the interrupts way.
I'm not quite sure what your code looks like but the mass storage part of
your code shouldn't be calling chan's fatfs code.
On Fri, Jul 5, 2013 at 9:16 AM, Yusuf Husainy wrote:

> **
> Hi Fx and everyone else,
>
> Thanks for the help.
>
> I went through the code in the given link and modified it to suit the
> LPC2368. I used the mmc/sdfatfs & USB-MSC implementation from NXP's site
> and the USB implementation from the link, mergeed it together and worked to
> make it work for the past 4-5 days.
>
> In the link's implementation, which is for the cortex-m0 processor, in
> the MSC_MemoryRead() function, in mscuser.c, the disk_read() disk I/O api
> is called to read data from the SD CARD.
>
> However, the link's implementation is using DMA transfers, which uses the
> same USB RAM that is needed for the USB part implementation.
>
> Now, the problem is, I turned off the flag which is used for including all
> the DMA related code during the preprocessor stage, so essentially, the
> disk_read should perform in a manner expected from a non-DMA perspective.
> disk_read polls for a flag, waiting for it to be cleared, specifically the
> MCI_Block_End_Flag variable. However, this is cleared only by a
> routine(MCI_DATA_END_InterruptService) called by the ISR of the SD/MMC
> subunit. This routine is called when DMA transfers are enabled, meaning it
> is associated with transfering the sdcard data from the FIFO to the
> USB-RAM(the same RAM to be used for DMA access, which is shared with the
> USB subunit, also in use).
>
> However, the routine(MCI_FIFOInterruptService) called by the ISR, when DMA
> transfers are disabled, does not clear this flag at all, so disk_read would
> poll infinitely and never return.
>
> So, I added a line to clear this flag, and disk_read did come out from the
> loop and return. But another problem that occurred was that the
> function check_fs() returned failure which actually called the disk_read,
> and itself was called by auto_mount(), to be used for mounting when
> f_open()'ing an existing file. Hence, f_open fails and subsequent f_read()
> calls fail. I was doing f_read() to check whether it works or any disk
> related access api's work if I disable the DMA' transfers using the
> macro-#define MCI_DMA_ENABLED as 0 or 1 in the mci.h file.
>
> The f_read, f_open works with DMA enabled, but then the disk_read() from
> the MSC_MemoryRead() does not work, in the sense that the disk_read never
> returns, maybe because the USB-RAM is shared with DMA subunit.
>
> So I presume I cannot use both. But the f_open and family calls fail if I
> disable DMA. At this point, I haven't gone further to test the
> MSC_MemoryRead() calling the disk_read() function, beacuse, when DMA
> disabled, f_open ot auto_mount itself fails. And I haven't pinpointed this
> problem too, to the disk_read() called inside the auto_mount() called
> functions.
>
> It seems the problem is copying data from the SD?MMC FIFO to the memory.
>
> If anyone has faced a similar situation, I would appreciate their
> feedbacks, and also anyone else's.
>
> Regards,
> Yusuf Husainy.
>
> ________________________________
> From: Fx
> To: l...
> Sent: Sunday, 30 June 2013 5:00 AM
> Subject: Re: [lpc2000] LPC2368 USB MSC Device for SD/MMC card attached on
> a custom board.
>
> http://www.lpcware.com/content/blog/lpcxpresso-lpc11u14-usb-sd-card-exmple
>
> On Sat, Jun 29, 2013 at 9:57 AM, burhani95 wrote:
>
> > **
>
> >
> >
> > Hello Everyone,
> >
> > I am working on a project which involves detecting the SDCARD attached to
> > the SD/MMC interface on a custom LPC2368 based board.
> >
> > I have the LPC23xx MSC USB Bulk Only files from the NXP website. I tried
> > out their code by generatinf and flashing the hex file and was successful
> > in implementing it. Windows detected the device and I could see a
> > Readme.txt file too. The size of the MSC device was 16KB.
> >
> > I went through the code and found that the memory being treated as a MSC
> > Device is actually a part of the RAM-16KB in the form a char type array
> of
> > size 16KB-Memory[16KB].
> >
> > In the main function of their code, the data is copied from the actual
> > device (which is a DiskImage of 16KB stored in the Flash of the LPC2368)
> to
> > the Memory[16KB] array in the RAM.
> >
> > Using this, everything works great.
> >
> > However, If I want the sdcard to beahve in a similar way, I would have to
> > copy the entire sdcard to a local Memory[] type array too. The sdcard is
> > 2GB in size.
> >
> > I don't understand the work flow that I should consider for making the
> > SDCARD contents appear in windows after it is detected.
> >
> > If anyone has worked on this or have some guideline/suggestions to share,
> > It would be wonderful, and I would appreciate it.
> >
> > Reagards,
> > Yusuf Husainy
> >
> >
> > --
> /* Jumping Flowers */
>
> [Non-text portions of this message have been removed]
>
>
--- In l..., Yusuf Husainy wrote:
>
> Hi Fx and everyone else,
>
> Thanks for the help.
>
> I went through the code in the given link and modified it to suit the LPC2368.
>I used the mmc/sdfatfs & USB-MSC implementation from NXP's site

Please post the link to this code, Thank You.

don

Hello all,
Donald:
Here are the links:

LPC2368 USB MSC implementation:http://www.keil.com/download/docs/336.asp (I was mistaken, I had got it from the Keil website, not NXP).
USB-SD card implementation: http://www.lpcware.com/content/blog/lpcxpresso-lpc11u14-usb-sd-card-exmple
SD/FAFTS imlementation: I can't find the exact link but, it is Chan's implementation of the FATFS.

Fx:

Ok, I see, but my current implementation is based on interrupts itself, meaning, the interrupts received from the sd/mmc subunit of LPC2368. So, I did not get what you meant that you got rid of the DMA transfers and used interrupts. Looking in the lpcware link code above, you can see that when DMA is disabled, we do get interrupts from the sd/mmc subunit. So, what exactly did you do to make it work?

Also, I am not calling any of Chan's fatfs API's when an endpoint in/out event occurs. I call directly the lower level disk_read(), when an IN request comes from the host PC.

Also, sorry about the most previous thread I posted just before this, it was a duplicate, it got sent to the group mistakenly.

Regards,
Yusuf Husainy

________________________________
From: Donald H
To: l...
Sent: Friday, 5 July 2013 7:58 PM
Subject: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on a custom board.

 
--- In l..., Yusuf Husainy wrote:
>
> Hi Fx and everyone else,
>
> Thanks for the help.
>
> I went through the code in the given link and modified it to suit the LPC2368.
>I used the mmc/sdfatfs & USB-MSC implementation from NXP's site

Please post the link to this code, Thank You.

don


[Non-text portions of this message have been removed]

Please post the relevant part of your code to be discussed.
On Sat, Jul 6, 2013 at 3:07 AM, Yusuf Husainy wrote:

> **
> Hello all,
>
> Donald:
> Here are the links:
>
> LPC2368 USB MSC implementation:http://www.keil.com/download/docs/336.asp (I
> was mistaken, I had got it from the Keil website, not NXP).
> USB-SD card implementation:
> http://www.lpcware.com/content/blog/lpcxpresso-lpc11u14-usb-sd-card-exmple
> SD/FAFTS imlementation: I can't find the exact link but, it is Chan's
> implementation of the FATFS.
>
> Fx:
>
> Ok, I see, but my current implementation is based on interrupts itself,
> meaning, the interrupts received from the sd/mmc subunit of LPC2368. So, I
> did not get what you meant that you got rid of the DMA transfers and used
> interrupts. Looking in the lpcware link code above, you can see that when
> DMA is disabled, we do get interrupts from the sd/mmc subunit. So, what
> exactly did you do to make it work?
>
> Also, I am not calling any of Chan's fatfs API's when an endpoint in/out
> event occurs. I call directly the lower level disk_read(), when an IN
> request comes from the host PC.
>
> Also, sorry about the most previous thread I posted just before this, it
> was a duplicate, it got sent to the group mistakenly.
>
> Regards,
> Yusuf Husainy
>
> ________________________________
> From: Donald H
> To: l...
> Sent: Friday, 5 July 2013 7:58 PM
> Subject: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on
> a custom board.
>
> --- In l..., Yusuf Husainy wrote:
> >
> > Hi Fx and everyone else,
> >
> > Thanks for the help.
> >
> > I went through the code in the given link and modified it to suit the
> LPC2368.
> >I used the mmc/sdfatfs & USB-MSC implementation from NXP's site
>
> Please post the link to this code, Thank You.
>
> don
>
> [Non-text portions of this message have been removed]
>
>
>

--
/* Jumping Flowers */
[Non-text portions of this message have been removed]

Oh, I thought it were the links from where i got the code.

OK here are my parts of the code relevant to the problem:

http://pastie.org/8115232
It is a bit long, but most probably easy to grasp.

The thing not working is the copying of the sd/card received data from the MCI FIFO to memory(USB-RAM), when DMA is diabled.
The pointers,
volatile BYTE *WriteBlock = (BYTE *)(DMA_SRC); /* treat WriteBlock as a constant address */
volatile BYTE *ReadBlock = (BYTE *)(DMA_DST); /* treat ReadBlock as a constant address */

actually define the memory region where the received data will be put from MCI FIFO as well as the from where the pick-up of data will be done to write to the MCI FIFO.

These pointers are used as the sole arguments of MCI_ReadFifo and MCI_WriteFifo, implemented as assembly routines in the file readfifo.s(this is given in the above link), when DMA is disabaled, and used as the destination and source addresses when DMA is enabled. This memory region is defined to be in the USB-RAM space as defined in dma.h file here:
#define DMA_SRC0x7FD00000/* This is the area original data is stored
or data to be written to the SD/MMC card. */
#define DMA_DST0x7FD01000/* This is the area, after writing to the SD/MMC,
// data read from the SD/MMC card. */

If anyone has more questions on the implementation of my code, feel free to ask.

And also, I appreciate everyone's help and response.
Regards,
Yusuf Husainy

________________________________
From: Fx
To: l...
Sent: Saturday, 6 July 2013 4:00 PM
Subject: Re: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on a custom board.


Please post the relevant part of your code to be discussed.
On Sat, Jul 6, 2013 at 3:07 AM, Yusuf Husainy wrote:

> **
> Hello all,
>
> Donald:
> Here are the links:
>
> LPC2368 USB MSC implementation:http://www.keil.com/download/docs/336.asp (I
> was mistaken, I had got it from the Keil website, not NXP).
> USB-SD card implementation:
> http://www.lpcware.com/content/blog/lpcxpresso-lpc11u14-usb-sd-card-exmple
> SD/FAFTS imlementation: I can't find the exact link but, it is Chan's
> implementation of the FATFS.
>
> Fx:
>
> Ok, I see, but my current implementation is based on interrupts itself,
> meaning, the interrupts received from the sd/mmc subunit of LPC2368. So, I
> did not get what you meant that you got rid of the DMA transfers and used
> interrupts. Looking in the lpcware link code above, you can see that when
> DMA is disabled, we do get interrupts from the sd/mmc subunit. So, what
> exactly did you do to make it work?
>
> Also, I am not calling any of Chan's fatfs API's when an endpoint in/out
> event occurs. I call directly the lower level disk_read(), when an IN
> request comes from the host PC.
>
> Also, sorry about the most previous thread I posted just before this, it
> was a duplicate, it got sent to the group mistakenly.
>
> Regards,
> Yusuf Husainy
>
> ________________________________
> From: Donald H
> To: l...
> Sent: Friday, 5 July 2013 7:58 PM
> Subject: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on
> a custom board.
>
> --- In l..., Yusuf Husainy wrote:
> >
> > Hi Fx and everyone else,
> >
> > Thanks for the help.
> >
> > I went through the code in the given link and modified it to suit the
> LPC2368.
> >I used the mmc/sdfatfs & USB-MSC implementation from NXP's site
>
> Please post the link to this code, Thank You.
>
> don
>
> [Non-text portions of this message have been removed]
>
>
>

--
/* Jumping Flowers */
[Non-text portions of this message have been removed]

Hi all,

I have made some progress. I was successful in reading from the sd card while DMA is disabled and also I shifted the src and dest addresses which were used to write to and read from the MCI FIFO respectively, to the normal RAM from the USB-RAM.

Now, should it be that I should call the low level disk api disk_read() when a MSC_MemoryRead() request comes from the host(i.e., SCSI_READ requests?). I am asking this because,. when i call disk_read() from MSC_MemoryRead(), it necer returns, meaning, the flag it loops for getting cleared never gets cleared by of the interrupt handler. This is beacuse, the interrupt never occurs. So, what I think is that, I should be calling disk_read() in a way that the host would expect, not as Chan's FATFS f_read() would expect. Am I correct here? 

I mean, what way should I read data from the disk_read(), so that the host would expect it to be in a correct format? 

This does not happen if I use normal f_read() call from my main() function, to read a line from an existing file. An interrupt does occur, and disk_read() returns successfully.

Regards,
Yusuf Husainy.
________________________________
From: Yusuf Husainy
To: "l..."
Sent: Saturday, 6 July 2013 4:42 PM
Subject: Re: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on a custom board.

 
Oh, I thought it were the links from where i got the code.

OK here are my parts of the code relevant to the problem:

http://pastie.org/8115232

It is a bit long, but most probably easy to grasp.

The thing not working is the copying of the sd/card received data from the MCI FIFO to memory(USB-RAM), when DMA is diabled.
The pointers,
volatile BYTE *WriteBlock = (BYTE *)(DMA_SRC); /* treat WriteBlock as a constant address */
volatile BYTE *ReadBlock  = (BYTE *)(DMA_DST); /* treat ReadBlock as a constant address */

actually define the memory region where the received data will be put from MCI FIFO as well as the from where the pick-up of data will be done to write to the MCI FIFO.

These pointers are used as the sole arguments of MCI_ReadFifo and MCI_WriteFifo, implemented as assembly routines in the file readfifo.s(this is given in the above link),  when DMA is disabaled, and used as the destination and source addresses when DMA is enabled. This memory region is defined to be in the USB-RAM space as defined in dma.h file here:
#define DMA_SRC0x7FD00000/* This is the area original data is stored
or data to be written to the SD/MMC card. */
#define DMA_DST0x7FD01000/* This is the area, after writing to the SD/MMC,
// data read from the SD/MMC card. */

If anyone has more questions on the implementation of my code, feel free to ask.

And also, I appreciate everyone's help and response.

Regards,
Yusuf Husainy

________________________________
From: Fx
To: l...
Sent: Saturday, 6 July 2013 4:00 PM
Subject: Re: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on a custom board.
Please post the relevant part of your code to be discussed.

On Sat, Jul 6, 2013 at 3:07 AM, Yusuf Husainy wrote:

> **
> Hello all,
>
> Donald:
> Here are the links:
>
> LPC2368 USB MSC implementation:http://www.keil.com/download/docs/336.asp (I
> was mistaken, I had got it from the Keil website, not NXP).
> USB-SD card implementation:
> http://www.lpcware.com/content/blog/lpcxpresso-lpc11u14-usb-sd-card-exmple
> SD/FAFTS imlementation: I can't find the exact link but, it is Chan's
> implementation of the FATFS.
>
> Fx:
>
> Ok, I see, but my current implementation is based on interrupts itself,
> meaning, the interrupts received from the sd/mmc subunit of LPC2368. So, I
> did not get what you meant that you got rid of the DMA transfers and used
> interrupts. Looking in the lpcware link code above, you can see that when
> DMA is disabled, we do get interrupts from the sd/mmc subunit. So, what
> exactly did you do to make it work?
>
> Also, I am not calling any of Chan's fatfs API's when an endpoint in/out
> event occurs. I call directly the lower level disk_read(), when an IN
> request comes from the host PC.
>
> Also, sorry about the most previous thread I posted just before this, it
> was a duplicate, it got sent to the group mistakenly.
>
> Regards,
> Yusuf Husainy
>
> ________________________________
> From: Donald H
> To: l...
> Sent: Friday, 5 July 2013 7:58 PM
> Subject: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on
> a custom board.
>
> --- In l..., Yusuf Husainy wrote:
> >
> > Hi Fx and everyone else,
> >
> > Thanks for the help.
> >
> > I went through the code in the given link and modified it to suit the
> LPC2368.
> >I used the mmc/sdfatfs & USB-MSC implementation from NXP's site
>
> Please post the link to this code, Thank You.
>
> don
>
> [Non-text portions of this message have been removed]
>

>

--
/* Jumping Flowers */

[Non-text portions of this message have been removed]

Hello All,

I have finally done it!!

The sd-card is detected by Windows as 1.83GB volume showing all the files on it. I can read and write to it also. I can cut, copy and paste data to and from the sd-card too!!!

The problem was, I has nested interrupts disabled as soon as a USB interrupt occured. So the sd/mmc unit of lpc2368 was unable to interrupt the processor core. I enabled interrupts at the start of the udb isr, and then disabled just before the ISR returned.

Everything is working great now!!

Onlly, I would like to change the volume name of the sd-card. I know I can do it on Windows, but how would I do it in code, I mean what register or something would I have to program of the sd/mmc unit to change the volume name when it is detected by Windows?

I appreciate everyone's help and response.

Regards,
Yusuf Husainy.
________________________________
From: Yusuf Husainy
To: "l..."
Sent: Monday, 8 July 2013 5:27 PM
Subject: Re: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on a custom board.

 
Hi all,

I have made some progress. I was successful in reading from the sd card while DMA is disabled and also I shifted the src and dest addresses which were used to write to and read from the MCI FIFO respectively, to the normal RAM from the USB-RAM.

Now, should it be that I should call the low level disk api disk_read() when a MSC_MemoryRead() request comes from the host(i.e., SCSI_READ requests?). I am asking this because,. when i call disk_read() from MSC_MemoryRead(), it necer returns, meaning, the flag it loops for getting cleared never gets cleared by of the interrupt handler. This is beacuse, the interrupt never occurs. So, what I think is that, I should be calling disk_read() in a way that the host would expect, not as Chan's FATFS f_read() would expect. Am I correct here? 

I mean, what way should I read data from the disk_read(), so that the host would expect it to be in a correct format? 

This does not happen if I use normal f_read() call from my main() function, to read a line from an existing file. An interrupt does occur, and disk_read() returns successfully.

Regards,
Yusuf Husainy.

________________________________
From: Yusuf Husainy
To: "l..."
Sent: Saturday, 6 July 2013 4:42 PM
Subject: Re: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on a custom board.
 
Oh, I thought it were the links from where i got the code.

OK here are my parts of the code relevant to the problem:

http://pastie.org/8115232

It is a bit long, but most probably easy to grasp.

The thing not working is the copying of the sd/card received data from the MCI FIFO to memory(USB-RAM), when DMA is diabled.
The pointers,
volatile BYTE *WriteBlock = (BYTE *)(DMA_SRC); /* treat WriteBlock as a constant address */
volatile BYTE *ReadBlock  = (BYTE *)(DMA_DST); /* treat ReadBlock as a constant address */

actually define the memory region where the received data will be put from MCI FIFO as well as the from where the pick-up of data will be done to write to the MCI FIFO.

These pointers are used as the sole arguments of MCI_ReadFifo and MCI_WriteFifo, implemented as assembly routines in the file readfifo.s(this is given in the above link),  when DMA is disabaled, and used as the destination and source addresses when DMA is enabled. This memory region is defined to be in the USB-RAM space as defined in dma.h file here:
#define DMA_SRC0x7FD00000/* This is the area original data is stored
or data to be written to the SD/MMC card. */
#define DMA_DST0x7FD01000/* This is the area, after writing to the SD/MMC,
// data read from the SD/MMC card. */

If anyone has more questions on the implementation of my code, feel free to ask.

And also, I appreciate everyone's help and response.

Regards,
Yusuf Husainy

________________________________
From: Fx
To: l...
Sent: Saturday, 6 July 2013 4:00 PM
Subject: Re: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on a custom board.

Please post the relevant part of your code to be discussed.

On Sat, Jul 6, 2013 at 3:07 AM, Yusuf Husainy wrote:

> **
> Hello all,
>
> Donald:
> Here are the links:
>
> LPC2368 USB MSC implementation:http://www.keil.com/download/docs/336.asp (I
> was mistaken, I had got it from the Keil website, not NXP).
> USB-SD card implementation:
> http://www.lpcware.com/content/blog/lpcxpresso-lpc11u14-usb-sd-card-exmple
> SD/FAFTS imlementation: I can't find the exact link but, it is Chan's
> implementation of the FATFS.
>
> Fx:
>
> Ok, I see, but my current implementation is based on interrupts itself,
> meaning, the interrupts received from the sd/mmc subunit of LPC2368. So, I
> did not get what you meant that you got rid of the DMA transfers and used
> interrupts. Looking in the lpcware link code above, you can see that when
> DMA is disabled, we do get interrupts from the sd/mmc subunit. So, what
> exactly did you do to make it work?
>
> Also, I am not calling any of Chan's fatfs API's when an endpoint in/out
> event occurs. I call directly the lower level disk_read(), when an IN
> request comes from the host PC.
>
> Also, sorry about the most previous thread I posted just before this, it
> was a duplicate, it got sent to the group mistakenly.
>
> Regards,
> Yusuf Husainy
>
> ________________________________
> From: Donald H
> To: l...
> Sent: Friday, 5 July 2013 7:58 PM
> Subject: [lpc2000] Re: LPC2368 USB MSC Device for SD/MMC card attached on
> a custom board.
>
> --- In l..., Yusuf Husainy wrote:
> >
> > Hi Fx and everyone else,
> >
> > Thanks for the help.
> >
> > I went through the code in the given link and modified it to suit the
> LPC2368.
> >I used the mmc/sdfatfs & USB-MSC implementation from NXP's site
>
> Please post the link to this code, Thank You.
>
> don
>
> [Non-text portions of this message have been removed]
>

>

--
/* Jumping Flowers */

[Non-text portions of this message have been removed]


The 2024 Embedded Online Conference