Author Topic: FTP access to SD card  (Read 9521 times)

Offline martinh

  • Newbie
  • *
  • Posts: 25
    • View Profile
FTP access to SD card
« on: September 06, 2013, 12:15:09 PM »
Hello,

with my LPC2468 project, which is based on uTasker vs.4, I am able to update the code using ftp (BARE MINIMUM BOOTLOADER).
Now I have implemented mass_storage.c from uTasker vs.8 and I can create files and perform write and read operations to/from a 32GB SD card.

The problem is that it is no longer possible to get a FTP connection.
That means the Bare Minimum Bootloader cannot be used any longer (which was fine before) and there is no access to the SD card via FTP of course.

fnConfigureFtpServer() still is reached (invoked from the application task), but fnFTPListener() is not.
I have tracked the problem down to fnTaskEthernet():
  When the FTP connection is initiated on the client side, fnTaskEthernet() receives IP_UDP instead of IP_TCP.
   
Compared to the version that is running (ftp ok, mass_storage.c not implemented) just 'R' has been added (TASK_MASS_STORAGE):
W, A, E, T, a, R, D, d, S, X, V

Does anybody have an idea what might have gone wrong?
Any suggestions how to procede are highly appreciated!

Regards,
Martin
attached: TaskConfig.h

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: FTP access to SD card
« Reply #1 on: September 06, 2013, 02:01:18 PM »
Hi Martin

The configuration looks Ok and, as I have understood it, the SD card is basically operating.
If you haven't changed ftp.c to support the SD card I would expect it to work as it did without the SD card.

Are you sure that TCP is basically operating? (Check whether the web server works)

Since IP_UDP and IP_TCP are generated in the Ethernet task depending on whether the received Ethernet protcol is UDP or TCP I don't see that this can be dependent on whether SD card is used or not (since it all takes place at a low level before any file system code is used). It may be that there were some UDP frames on the network when you tested.

Check also that no initialisation fails - for example due to lack of heap memory - which could stop operation as expected.

Regards

Mark

Offline martinh

  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: FTP access to SD card
« Reply #2 on: September 10, 2013, 01:52:31 PM »
Hi Mark,

the problem was caused by an additional line I had added to the macro CONFIGURE_SDCARD_INTERFACE:
  ...
  PINSEL2 &= ~(3<<10 || 3<<6 || 3<<4 || 3<<12 || 3<<14 || 3<<22 || 3<<24);
           //  MCIPWR  MCICMD  MCICLK  MCIDAT0  MCIDAT1  MCIDAT2  MCIDAT3 
  ...
The intention was to set the bits to its default status to asure that the OR operation in the next line
  PINSEL2 |= (  PINSEL2_P1_3_MCICMD | PINSEL2_P1_2_MCICLK | PINSEL2_P1_6_MCIDAT0 | PINSEL2_P1_7_MCIDAT1 | PINSEL2_P1_11_MCIDAT2 | PINSEL2_P1_12_MCIDAT3);
would set the right bits.
For some reason that failed and that code had to be removed.

1. SD card access
Now with the following code in the main loop I can establish a ftp connection to the SD card.
    ...
    uTaskerStateChange(TASK_MASS_STORAGE, UTASKER_ACTIVATE);  // status when fnMass_Storage() is reached: MemoryOperation == _INITIALISED_MEMORY
    uTaskerSchedule();
    ...
I can see the file names on the SD card but I cannot copy/open the files (deleting is possible!).
(Reducing the clock rate from 18MHz to 9MHz did not make any difference.)

Instead I get an error message "Error downloading file" after some time.
The following events are monitored at the beginning of fnFtpListener() (before 'switch') after trying to copy a file:
 5   TCP_EVENT_CLOSE
 1   TCP_EVENT_ABORT

 8   TCP_EVENT_CONREQ
 2   TCP_EVENT_CONNECTED
 3   TCP_EVENT_ACK
 4   TCP_EVENT_DATA
 3 4 .. 3 4
 a   TCP_EVENT_PARTIAL_ACK
 7    TCP_EVENT_REGENERATE
 a 7 .. a 7
 a   TCP_EVENT_PARTIAL_ACK
 1   TCP_EVENT_ABORT

 8 2   
 3 4 ... 3 4
 1

 8 2
 3 4 ... 3 4
 3
 5
 1

 In fnFTP_Data_Listener() (seperate test) the following events were logged twice:
 8   TCP_EVENT_CONREQ
 2   TCP_EVENT_CONNECTED
 a   TCP_EVENT_PARTIAL_ACK
 7   TCP_EVENT_REGENERATE
 a   TCP_EVENT_PARTIAL_ACK
 3   TCP_EVENT_ACK
 ...
 3
 1   TCP_EVENT_ABORT

Does that information lead to any conclusion?

2. File system access (for bootloader)
Now that I can connect to the SD card (but still not being able to copy files), how can I connect to the file system to load an update?
When the TASK_MASS_STORAGE is not activated periodically in the mainloop then a ftp connection to the file system is achieved and uploading a file is fine.
But how would I select either the SD card or the file system using the ftp client (for instance TotalCommander in this case)?

3. File size
Is there a size limitation for files on the SD card?

TCP is basically operating, a simple html file (uploaded to the file system) was invoked by the browser.

Regards,
Martin

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: FTP access to SD card
« Reply #3 on: September 11, 2013, 06:05:28 PM »
Hi Martin

1) I don't understand why you have needed to add uTaskerStateChange(TASK_MASS_STORAGE, UTASKER_ACTIVATE); to the main loop. The task should be started by the configuration and then use a timer of its own, which is operational only when mounting and when some operations are performed; mainly it will be dormant.

2) Have you tried using DOS FTP? Total Commander is not fully compatible with the version of FTP in the present LPC2xxx release and may cause some difficulties with certain operations - the events that you see haven't helped me identify anything though. I have attached my latest FTP.c version which has a few modifications compared to yours which allow Total Commander to operate correctly. See changes {28} and {30}. Note that a new define (in config.h)
#define UT_FTP_PATH_LENGTH      128                      // this must be non-zero to enable PWD request to return a path name
is required for the FTP PWD command (as used - and needed - by Total Commanded) to operate correctly.

3) If FTP is working with the SD card all uploads will go to the SD card (and not to the uFileSystem, which you are presumably using for software uploads).
Using
utServer() and parameters UTFAT_FTP_SERVER_ON / UTFAT_FTP_SERVER_OFF it is possible to change between the SD card and the uFileSystem but FTP will not control that directly. It would be possible to control it on a web page if that is an option.

4) FAT32 has a file size limit of 4,294,967,295 bytes. If your SD card is larger than 4G this should be the maximum size possible.

Regards

Mark

Offline martinh

  • Newbie
  • *
  • Posts: 25
    • View Profile
Re: FTP access to SD card
« Reply #4 on: September 12, 2013, 03:44:33 PM »
Hi Mark,

thanks for your reply.

1) Would you suggest to put something like the following into ctTaskTable[]
   { "R_MassSt",    fnMassStorage,  MEDIUM_QUE,  0, 0, UTASKER_GO},
and set iMemoryState = SD_STATE_STARTING to stard card initialisation?

The intention is to schedule utasker just once during a cycle (duration of 20...30ms) by invoking 'uTaskerSchedule()'.
Then data shall be stored to the SD card. But it shall also be possible to prevent storing data for some cycles. Accessing the SD card must be done at a defined position within the cycle, i.e. after sampling has been finished. A uTasker timer would not meet that requirement, I am afraid.

2) Using DOS FTP (Windows 7) the 'dir' command is accepted.
The command 'get file222' however results in this:
  200 OK.
  150 Data.
Nothing more.
After some seconds uTasker runs in an infinite loop at 0xF4:
  b 0x000000f4
The call stack from Rowley's CrossStudio just says '(Unknown Function)???', no further information about previous steps.
In this special case it is the data abort exception.
Restoring the last command lead to the function
  uMemcpy(ptrValue, fnGetFlashAdd(ParLocation), Size);
which is invoked in
  static void fnGetPars(unsigned char *ParLocation, unsigned char *ptrValue, MAX_FILE_LENGTH Size)
The call stack shows these values
  Size         0x4000f73c
  ptrValue     0x4000f73c
  ParLocation  0x4000f8a7
Size obviously is wrong.
So it looks like a memory problem. (MEM_FACTOR for the heap has already been increased to 1.2.)


I also tried to exchange ftp.c, but the file you attached did not contain a definition for
  _TCP_SOCKET_MASK
  _TCP_SOCKET_MASK_ASSIGN
It could not be found in uTasker version 8 either.
Could you let me know what the definition is, please?


Regards,
Martin
« Last Edit: September 13, 2013, 09:03:11 AM by martinh »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: FTP access to SD card
« Reply #5 on: September 14, 2013, 02:00:52 PM »
Hi Martin

1. The usual task configuration is:
{"MassSt",    fnMassStorage,  MEDIUM_QUE,  (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP},
The task then has a timer associated with it and is started from the application task (when needed) by calling
uTaskerStateChange(TASK_MASS_STORAGE, UTASKER_ACTIVATE);
which starts its operation.

2. Looking at the FTP messges it looks as though the FTP control connection is working correctly but there is a problem when the data connection is opened. This is probably not due to TCP or FTP itself but due to accessing memory - is the file system dimensioned correctly? Thsi type of erro can result when the file system is being checked for content and there is some area that is not physically available (such as the area defined larger than the internal Flash size when using uFileSystem).
Note that MEM_FACTOR is only used when simulating (not when building with cross-compiler) and is only concerned with the heap size.

3. The missing defines are due to multiple network capabilities in the newer software.

If you put these dummy defines into tcpip.h it will make the code at those locations the same as before:
    #define _TCP_SOCKET_MASK_ASSIGN(uSocket)                             // does nothing when single interface and single networks
    #define _TCP_SOCKET_MASK(uSocket) (uSocket)
    #define _UDP_SOCKET_MASK_ASSIGN(uSocket)
    #define _UDP_SOCKET_MASK(uSocket) (uSocket)


In case of problems I would copy the code marked by the revision numbers to your version so you can contol the changes that you woudl like without potential compatibility issies.

Regards

Mark