Hi all,

anyone got a LPC2148 port of LPCUSB?
I'm trying to get it running on a Keil MCB2140 dev board which has the
SD slot on the SSP instead of the SPI.

Have made the changes to LPC2000_SPI but the SPISend, SPISendN and
SPIRecvN functions are SPI specfic. Have tried re-coding them for SSP
operation but no success yet.

Am attempting to integrate ELFS to LPCUSB. Got ELFS working fine, just
have to get the USB done now.

thanks,

Mark. Start a New Thread

> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of myfriendmarkis
> Sent: Wednesday, December 06, 2006 10:47 AM
> To: l...
> Subject: [lpc2000] LPCUSB port for LPC2148
> Hi all,
>
> anyone got a LPC2148 port of LPCUSB?
> I'm trying to get it running on a Keil MCB2140 dev board
> which has the
> SD slot on the SSP instead of the SPI.
>
> Have made the changes to LPC2000_SPI but the SPISend, SPISendN and
> SPIRecvN functions are SPI specfic. Have tried re-coding them for SSP
> operation but no success yet.
>
> Am attempting to integrate ELFS to LPCUSB. Got ELFS working
> fine, just
> have to get the USB done now.
>
> thanks,
>
> Mark.

LPCUSB supports the LPC2148 out of the box. There is no
need for another port. If your hardware is different than
what was intended, then you will need to make some changes.

Download EFSL from http://sourceforge.net/projects/efsl/ as this
is what the SD card interface in LPCUSB is based on. The EFSL
source supports both the SPI, and SSP. You will just need to
write the blockdev stub functions that call the SD card read
and write routines from EFSL and you will be up and running.

But, since you already have ELFS up and running, you could
probably just write the blockdev stubs to call functions you
already have. It should not be too difficult. ELFS must have
similar functions to what is done in the blockdev layer code.

The project I have uses EFSL as the internal file system layer,
on the SSP port, and LPCUSB to handle the mass storage interface,
and it all works together very nicely. Just make sure only one
device has access to the SD card at a time, or you will have a
lot of difficulty....

Mike Start a New Thread

>
>> -----Original Message-----
>> From: l...
>> [mailto:l...]On Behalf
>> Of myfriendmarkis
>> Sent: Wednesday, December 06, 2006 10:47 AM
>> To: l...
>> Subject: [lpc2000] LPCUSB port for LPC2148
>> Hi all,
>>
>> anyone got a LPC2148 port of LPCUSB?
>> I'm trying to get it running on a Keil MCB2140 dev board
>> which has the
>> SD slot on the SSP instead of the SPI.
>>
>> Have made the changes to LPC2000_SPI but the SPISend, SPISendN and
>> SPIRecvN functions are SPI specfic. Have tried re-coding them for SSP
>> operation but no success yet.
>>
>> Am attempting to integrate ELFS to LPCUSB. Got ELFS working
>> fine, just
>> have to get the USB done now.
>>
>> thanks,
>>
>> Mark.
>
>LPCUSB supports the LPC2148 out of the box. There is no
>need for another port. If your hardware is different than
>what was intended, then you will need to make some changes.
>
>Download EFSL from http://sourceforge.net/projects/efsl/ as this
>is what the SD card interface in LPCUSB is based on. The EFSL
>source supports both the SPI, and SSP. You will just need to
>write the blockdev stub functions that call the SD card read
>and write routines from EFSL and you will be up and running.
>
>But, since you already have ELFS up and running, you could
>probably just write the blockdev stubs to call functions you
>already have. It should not be too difficult. ELFS must have
>similar functions to what is done in the blockdev layer code.
>
>The project I have uses EFSL as the internal file system layer,
>on the SSP port, and LPCUSB to handle the mass storage interface,
>and it all works together very nicely. Just make sure only one
>device has access to the SD card at a time, or you will have a
>lot of difficulty....
>
>Mike

Hi Mike,

Thanks for the reply.

I thought it would be easy too! ELFS does support SPI1 (SSP) so that was simply a matter of setting up the config file however LPCUSB is coded just to use SPI0. As you say modifying the commands in Blockdev_sd.c to use the SPI1 should make it work on the SSP but it doesn't. I've modified SPISend, SPISendN & SPIRecvN to use the SSP registers without success. I also just tried substituting the ELFS commands if_spiSend & if_readBuf (as I know I can talk to the card with those) but that didn't work either.

Digging in the USB protocal shows that the device enumerates OK and shows up as a removable drive but doesn't show size or contents which comes from the read10 command.

I've had a lot of experience with the keil USBMem code so know my way around the USB/SCSI specs. USBMem doesn't work with anything other than RAM access as Keils implementation cant cope with long access delays (no function for stalling endpoints whilst waiting for a response), so I was really wondering if LPCUSB suffers in the same way?

All I'm trying to do right now is prove that LPCUSB works on the SPI1 interface... If I could get that working then I would just treat LPCUSB and ELFS as seperate modules to combine the functionality as you suggest.

Thanks again,

Mark. Start a New Thread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

m...@hotmail.com wrote:
>>> -----Original Message----- From: l...
>>> [mailto:l...]On Behalf Of myfriendmarkis Sent:
>>> Wednesday, December 06, 2006 10:47 AM To: l...
>>> Subject: [lpc2000] LPCUSB port for LPC2148 Hi all,
>>>
>>> anyone got a LPC2148 port of LPCUSB? I'm trying to get it running
>>> on a Keil MCB2140 dev board which has the SD slot on the SSP
>>> instead of the SPI.
>>>
>>> Have made the changes to LPC2000_SPI but the SPISend, SPISendN
>>> and SPIRecvN functions are SPI specfic. Have tried re-coding them
>>> for SSP operation but no success yet.
>>>
>>> Am attempting to integrate ELFS to LPCUSB. Got ELFS working fine,
>>> just have to get the USB done now.
>>>
>>> thanks,
>>>
>>> Mark.
>> LPCUSB supports the LPC2148 out of the box. There is no need for
>> another port. If your hardware is different than what was
>> intended, then you will need to make some changes.
>>
>> Download EFSL from http://sourceforge.net/projects/efsl/ as this is
>> what the SD card interface in LPCUSB is based on. The EFSL source
>> supports both the SPI, and SSP. You will just need to write the
>> blockdev stub functions that call the SD card read and write
>> routines from EFSL and you will be up and running.
>>
>> But, since you already have ELFS up and running, you could probably
>> just write the blockdev stubs to call functions you already have.
>> It should not be too difficult. ELFS must have similar functions
>> to what is done in the blockdev layer code.
>>
>> The project I have uses EFSL as the internal file system layer, on
>> the SSP port, and LPCUSB to handle the mass storage interface, and
>> it all works together very nicely. Just make sure only one device
>> has access to the SD card at a time, or you will have a lot of
>> difficulty....
>>
>> Mike
>
> Hi Mike,
>
> Thanks for the reply.
>
> I thought it would be easy too! ELFS does support SPI1 (SSP) so that
> was simply a matter of setting up the config file however LPCUSB is
> coded just to use SPI0. As you say modifying the commands in
> Blockdev_sd.c to use the SPI1 should make it work on the SSP but it
> doesn't. I've modified SPISend, SPISendN & SPIRecvN to use the SSP
> registers without success. I also just tried substituting the ELFS
> commands if_spiSend & if_readBuf (as I know I can talk to the card
> with those) but that didn't work either.
>
> Digging in the USB protocal shows that the device enumerates OK and
> shows up as a removable drive but doesn't show size or contents which
> comes from the read10 command.
>
> I've had a lot of experience with the keil USBMem code so know my way
> around the USB/SCSI specs. USBMem doesn't work with anything other
> than RAM access as Keils implementation cant cope with long access
> delays (no function for stalling endpoints whilst waiting for a
> response), so I was really wondering if LPCUSB suffers in the same
> way?
>
> All I'm trying to do right now is prove that LPCUSB works on the SPI1
> interface... If I could get that working then I would just treat
> LPCUSB and ELFS as seperate modules to combine the functionality as
> you suggest.

I don't see any reason why the SSP code from EFSL wouldn't work (It
may take a bit of work though).

The hardware interface that EFSL uses is the SPI interface. For USB
mass storage you need a simple block device. Although EFSL also has
the concept of a block device, I didn't want to put all of the EFSL
specific stuff in the USB mass storage application.

W.r.t. to STALLing: STALL is not the proper thing to do for an
USB mass storage device while it is fetching data from flash.
The LPCUSB mass storage application simply does not respond to any
USB activity while getting the data. The USB device hardware then
automatically takes care of any host requests for data by NACKing
those requests (the host will retry them with a timeout).
The USB bulk-only-transport protocol *does* use STALLs for other
purposes and it is quite tricky to get this exactly right.
(The stack currently passes the usb.org chapter9 and USB MSC tests)

Kind regards,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFeF5fETD6mlrWxPURAgC1AJ9FC93rcNLaLkOsAN+Q8dWAMS/RXQCfQLRL
hn0XPW/6G46xSCjLxdDUJBI=0NTQ
-----END PGP SIGNATURE----- Start a New Thread

> Hi Mike,
>
> Thanks for the reply.
>
> I thought it would be easy too! ELFS does support SPI1 (SSP)
> so that was simply a matter of setting up the config file
> however LPCUSB is coded just to use SPI0. As you say
> modifying the commands in Blockdev_sd.c to use the SPI1
> should make it work on the SSP but it doesn't. I've modified
> SPISend, SPISendN & SPIRecvN to use the SSP registers without
> success. I also just tried substituting the ELFS commands
> if_spiSend & if_readBuf (as I know I can talk to the card
> with those) but that didn't work either.
>
> Digging in the USB protocal shows that the device enumerates
> OK and shows up as a removable drive but doesn't show size or
> contents which comes from the read10 command.
>
> I've had a lot of experience with the keil USBMem code so
> know my way around the USB/SCSI specs. USBMem doesn't work
> with anything other than RAM access as Keils implementation
> cant cope with long access delays (no function for stalling
> endpoints whilst waiting for a response), so I was really
> wondering if LPCUSB suffers in the same way?
>
> All I'm trying to do right now is prove that LPCUSB works on
> the SPI1 interface... If I could get that working then I
> would just treat LPCUSB and ELFS as seperate modules to
> combine the functionality as you suggest.
>
> Thanks again,
>
> Mark.
>

Hi Mark,

All I did was rewrite the BlockDev_sd.c layer, by calling the
interface layer functions from EFSL. You shouldn't have to
make any other changes.

Here is the code I use:

***************** BlockDev.c *********************************
#include "BlockDev.h"
#include
int BlockDevInit(void)
{
efs_init(&efs, 0);

return(0);
}
int BlockDevWrite(unsigned long dwAddress, unsigned char *pbBuf)
{
return(if_writeBuf(&efs.myCard, dwAddress, pbBuf));
}
int BlockDevRead(unsigned long dwAddress, unsigned char *pbBuf)
{
return(if_readBuf(&efs.myCard, dwAddress, pbBuf));
}
int BlockDevGetSize(unsigned long *pdwDriveSize)
{
return(if_getDriveSize(&efs.myCard, pdwDriveSize));
}
**************************************************************
***************** BlockDev.h *********************************
#ifndef __BLOCKDEV__
#define __BLOCKDEV__

#include
extern EmbeddedFileSystem efs;

#undef DBG

int BlockDevInit(void);
int BlockDevWrite(unsigned long dwAddress, unsigned char *pbBuf);
int BlockDevRead(unsigned long dwAddress, unsigned char *pbBuf);
int BlockDevGetSize(unsigned long *pdwDriveSize);
#endif
**************************************************************

Obviously, you will need to declare efs somewhere.

I made almost no changes to either library (other than the
blockdev code above) to get this to work.

If you want the SSP to work at high speed, you may want to
implement the patches I made for EFSL to support the FIFO.
This speeds up the transfer rate by about 3x on fast cards.
Take a look in the patches section in the sourceforge project.
This is supposed to be in the next release (which I was helping
with), but I'm not sure when it will be released. Martin Thomas
has a release candidate copy on his site, I think.

Hopefully this works for you,

Mike Start a New Thread

>> Hi Mike,
>>
>> Thanks for the reply.
>>
>> I thought it would be easy too! ELFS does support SPI1 (SSP)
>> so that was simply a matter of setting up the config file
>> however LPCUSB is coded just to use SPI0. As you say
>> modifying the commands in Blockdev_sd.c to use the SPI1
>> should make it work on the SSP but it doesn't. I've modified
>> SPISend, SPISendN & SPIRecvN to use the SSP registers without
>> success. I also just tried substituting the ELFS commands
>> if_spiSend & if_readBuf (as I know I can talk to the card
>> with those) but that didn't work either.
>>
>> Digging in the USB protocal shows that the device enumerates
>> OK and shows up as a removable drive but doesn't show size or
>> contents which comes from the read10 command.
>>
>> I've had a lot of experience with the keil USBMem code so
>> know my way around the USB/SCSI specs. USBMem doesn't work
>> with anything other than RAM access as Keils implementation
>> cant cope with long access delays (no function for stalling
>> endpoints whilst waiting for a response), so I was really
>> wondering if LPCUSB suffers in the same way?
>>
>> All I'm trying to do right now is prove that LPCUSB works on
>> the SPI1 interface... If I could get that working then I
>> would just treat LPCUSB and ELFS as seperate modules to
>> combine the functionality as you suggest.
>>
>> Thanks again,
>>
>> Mark.
>>
>
>Hi Mark,
>
>All I did was rewrite the BlockDev_sd.c layer, by calling the
>interface layer functions from EFSL. You shouldn't have to
>make any other changes.
>
>Here is the code I use:
>
>***************** BlockDev.c *********************************
>#include "BlockDev.h"
>#include
>int BlockDevInit(void)
> {
> efs_init(&efs, 0);
>
> return(0);
> }
>int BlockDevWrite(unsigned long dwAddress, unsigned char *pbBuf)
> {
> return(if_writeBuf(&efs.myCard, dwAddress, pbBuf));
> }
>int BlockDevRead(unsigned long dwAddress, unsigned char *pbBuf)
> {
> return(if_readBuf(&efs.myCard, dwAddress, pbBuf));
> }
>int BlockDevGetSize(unsigned long *pdwDriveSize)
> {
> return(if_getDriveSize(&efs.myCard, pdwDriveSize));
> }
>**************************************************************
>***************** BlockDev.h *********************************
>#ifndef __BLOCKDEV__
>#define __BLOCKDEV__
>
>#include
>extern EmbeddedFileSystem efs;
>
>#undef DBG
>
>int BlockDevInit(void);
>int BlockDevWrite(unsigned long dwAddress, unsigned char *pbBuf);
>int BlockDevRead(unsigned long dwAddress, unsigned char *pbBuf);
>int BlockDevGetSize(unsigned long *pdwDriveSize);
>#endif
>**************************************************************
>
>Obviously, you will need to declare efs somewhere.
>
>I made almost no changes to either library (other than the
>blockdev code above) to get this to work.
>
>If you want the SSP to work at high speed, you may want to
>implement the patches I made for EFSL to support the FIFO.
>This speeds up the transfer rate by about 3x on fast cards.
>Take a look in the patches section in the sourceforge project.
>This is supposed to be in the next release (which I was helping
>with), but I'm not sure when it will be released. Martin Thomas
>has a release candidate copy on his site, I think.
>
>Hopefully this works for you,
>
>Mike
>

Hi Mike,

Thanks for the code segment.

It appears there is another problem as this didn't fix it...
I can read/write to the card using ELFS and veriy the files by using a card reader. So the problem must be in the LPCUSB code itself. I had coded the BlockDev and your segment confirmed what I wrote (I thought I might have overlooked fifo usage or something).

The only lead I have is that I'm using target-20061124.tar.gz which is very recent. Maybe something has got in on this release?

I'll investigate and get back to you.

Again, thanks for your help. It's much appreciated.

mark. Start a New Thread

>> > Hi Mike,
>> >
>> > Thanks for the reply.
>> >
>> > I thought it would be easy too! ELFS does support SPI1 (SSP)
>> > so that was simply a matter of setting up the config file
>> > however LPCUSB is coded just to use SPI0. As you say
>> > modifying the commands in Blockdev_sd.c to use the SPI1
>> > should make it work on the SSP but it doesn't. I've modified
>> > SPISend, SPISendN & SPIRecvN to use the SSP registers without
>> > success. I also just tried substituting the ELFS commands
>> > if_spiSend & if_readBuf (as I know I can talk to the card
>> > with those) but that didn't work either.
>> >
>> > Digging in the USB protocal shows that the device enumerates
>> > OK and shows up as a removable drive but doesn't show size or
>> > contents which comes from the read10 command.
>> >
>> > I've had a lot of experience with the keil USBMem code so
>> > know my way around the USB/SCSI specs. USBMem doesn't work
>> > with anything other than RAM access as Keils implementation
>> > cant cope with long access delays (no function for stalling
>> > endpoints whilst waiting for a response), so I was really
>> > wondering if LPCUSB suffers in the same way?
>> >
>> > All I'm trying to do right now is prove that LPCUSB works on
>> > the SPI1 interface... If I could get that working then I
>> > would just treat LPCUSB and ELFS as seperate modules to
>> > combine the functionality as you suggest.
>> >
>> > Thanks again,
>> >
>> > Mark.
>> >
>>
>> Hi Mark,
>>
>> All I did was rewrite the BlockDev_sd.c layer, by calling the
>> interface layer functions from EFSL. You shouldn't have to
>> make any other changes.
>>
>> Here is the code I use:
>>
>> ***************** BlockDev.c *********************************
>> #include "BlockDev.h"
>> #include
>> int BlockDevInit(void)
>> {
>> efs_init(&efs, 0);
>>
>> return(0);
>> }
>> int BlockDevWrite(unsigned long dwAddress, unsigned char *pbBuf)
>> {
>> return(if_writeBuf(&efs.myCard, dwAddress, pbBuf));
>> }
>> int BlockDevRead(unsigned long dwAddress, unsigned char *pbBuf)
>> {
>> return(if_readBuf(&efs.myCard, dwAddress, pbBuf));
>> }
>> int BlockDevGetSize(unsigned long *pdwDriveSize)
>> {
>> return(if_getDriveSize(&efs.myCard, pdwDriveSize));
>> }
>> **************************************************************
>> ***************** BlockDev.h *********************************
>> #ifndef __BLOCKDEV__
>> #define __BLOCKDEV__
>>
>> #include
>> extern EmbeddedFileSystem efs;
>>
>> #undef DBG
>>
>> int BlockDevInit(void);
>> int BlockDevWrite(unsigned long dwAddress, unsigned char *pbBuf);
>> int BlockDevRead(unsigned long dwAddress, unsigned char *pbBuf);
>> int BlockDevGetSize(unsigned long *pdwDriveSize);
>> #endif
>> **************************************************************
>>
>> Obviously, you will need to declare efs somewhere.
>>
>> I made almost no changes to either library (other than the
>> blockdev code above) to get this to work.
>>
>> If you want the SSP to work at high speed, you may want to
>> implement the patches I made for EFSL to support the FIFO.
>> This speeds up the transfer rate by about 3x on fast cards.
>> Take a look in the patches section in the sourceforge project.
>> This is supposed to be in the next release (which I was helping
>> with), but I'm not sure when it will be released. Martin Thomas
>> has a release candidate copy on his site, I think.
>>
>> Hopefully this works for you,
>>
>> Mike
>>Hi Mike,
>
>Thanks for the code segment.
>
>It appears there is another problem as this didn't fix it...
>I can read/write to the card using ELFS and veriy the files by using a card reader. So the problem must be in the LPCUSB code itself. I had coded the BlockDev and your segment confirmed what I wrote (I thought I might have overlooked fifo usage or something).
>
>The only lead I have is that I'm using target-20061124.tar.gz which is very recent. Maybe something has got in on this release?
>
>I'll investigate and get back to you.
>
>Again, thanks for your help. It's much appreciated.
>
>mark.
Hi again,

Just to follow up I sorted out the problem. It was a timing issue caused by MAM usage....

LPCUSB and ELFS integrated and working now on Keil, MCB2400 SSP.

Thanks again,

Mark. Start a New Thread