I have the +TCP Labs going on an STM32F407 controller, now I am trying to make the FTP example work. I have copied and modified the TCPServer, HTTPServer and FTPServer code from the win32 simulator demo. The HTTP server seems to work pretty ok, the FTP server doesn’t do much. I am able to connect to it, but I cannot get the directory listing, I have tried with several different clients, most of them just get stuck, telling me they are downloading. With FileZilla I got a few messages which might be helpful: ~~~~ Status: Resolving address of EnergyMaster Status: Connecting to 192.168.12.107:21… Status: Connection established, waiting for welcome message… Response: 220 Welcome to the FreeRTOS+TCP FTP server Command: USER anonymous Response: 331 Anonymous login okay Command: PASS ************** Response: 230 OK. Current directory is / Command: SYST Response: 215 UNIX Type: L8 Command: FEAT Response: 211-Features: Response: MDTM Response: REST STREAM Response: SIZE Response: 211 End Status: Server does not support non-ASCII characters. Status: Connected Status: Retrieving directory listing… Command: PWD Response: 257 “/” Command: TYPE I Response: 200 NOOP command successful. Command: PORT 192,168,12,104,71,197 Response: 200 NOOP command successful. Command: LIST Response: 150 Opening ASCII mode data connection to for /bin/ls Error: Connection timed out Error: Failed to retrieve directory listing ~~~~ and here is what happens in passive mode: ~~~~ Status: Resolving address of EnergyMaster Status: Connecting to 192.168.12.107:21… Status: Connection established, waiting for welcome message… Response: 220 Welcome to the FreeRTOS+TCP FTP server Command: USER anonymous Response: 331 Anonymous login okay Command: PASS ************** Response: 230 OK. Current directory is / Status: Server does not support non-ASCII characters. Status: Connected Status: Retrieving directory listing… Command: PWD Response: 257 “/” Command: TYPE I Response: 200 NOOP command successful. Command: PASV Error: Disconnected from server: 10053 Error: Failed to retrieve directory listing ~~~~ any help is greatly appreciated.

[We have a project for the STM32F4, including FTP and HTTP on an SD card, but haven’t found the time to release it yet!] We have mainly tested with FileZilla, so I should stick with that for now. Not sure if it helps, but here is the output I get when connecting to the FreeRTOS+TCP FTP server running on a SAM4E (a Cortex-M4F microcontroller). I’m using a Windows host. ~~~~ Status: Resolving address of RTOSDemo Status: Connecting to 192.168.0.2:21… Status: Connection established, waiting for welcome message… Status: Insecure server, it does not support FTP over TLS. Status: Server does not support non-ASCII characters. Status: Connected Status: Retrieving directory listing… Status: Directory listing of “/” successful ~~~~ Your output looks fine up to the LIST command, I will take a WireShark capture to see if LIST is also being used when I connect from Windows. Other than that – is there anything unusual on the disk you are trying to view view FTP. For example, could there be a file name or path that has more characters than the value set by ffconfigMAX_FILENAME in FreeRTOSFATConfig.h, etc. Regards.

My guess is that you are close to getting it working 🙂

• The FTP connection with 192.168.12.107:21 went OK
• Your HTTP server runs, which means that +FAT is functional

And now for some reason the data connection doesn’t seem to get established. That could be caused by a firewall. Or caused by a lack of resources somewhere. Do you have logging enabled? For example like this: ~~~~~ #define ipconfigHASPRINTF 1 #if( ipconfigHASPRINTF != 0 ) #define FreeRTOSprintf( MSG ) usartprintf MSG #endif ~~~~~ In your logging there is this command: ~~~~~ Command: PORT 192,168,12,104,71,197 ~~~~~ As you probably know, the device is asking for a data connection on the address: 192,168,12,104 port 18373 (71 << 8 + 197) I just made 3 captures and I also collected the Filezilla logging (2 – Info and “Show raw directory listing”). You find the following files in the attachment ‘filezilla_examples.7z’ : filezillaactive.pcap + txt Dir listing with PORT filezillapassive.pcap + txt Di listing with PASV filezilla_send.pcap Sending a 1.2 MB file If you want us to look you can attach a PCAP of an FTP session. Regards.

I would be very interested in the STM32F4 demo, especially because I am not 100% satisfied with the performance. I am sure there are a few settings in the different config files (TCPIP and FAT) that are not ideal. Is it possible, that you sent me the config files of the demo? I’d also be interested in how you tied the ETH peripheral into the TCPIP stack, if you remember, I had a few issues getting ethernet working several months back, hardware checksum still isn’t working for me. Regarding the files stored on my SD card, they are all very standard in content and naming, no fancy characters, not even spaces in the names. LFN is enabled and adequate buffer size is allocated. I can successfully “open” each file using firefox (via HTTP server). This lets me conclude, that accessing the SD card and handling the FATFS (FAT32 on an 8GB card, one partition) is working properly. Best, Pascal

hardware checksum still isn’t working for me

It won’t be the first MAC peripheral that promises checksum-off-loading while it does not work properly. Should ask ST about this. I checked that explicitly by clearing the 2 CRC fields ( IP and TCP/UDP check-sum ), send messages from the device and look with Wireshark. Or I would have it receive packets from my laptop with erroneous check-sums.

I would be very interested in the STM32F4 demo

Could you write to us directly ( h point tibosch at freertos point org ) ? Then I will send you the current sources so you can try them. If FTP doesn’t work properly, could you send a PCAP of some session? And some logging ( produced by FreeRTOS_printf() ) would also be interesting. Regards.

Hello Hein, Thanks for the valuable input, I will implement some logging. I did capture the network traffic and the corresponding filezilla log (see attachment). Firewall is not the issue, completely disabled it for testing purposes. Also FTPing to other servers in the network works. I’ll get back to you with the FTP logs. Best, Pascal

in the meantime I got my setup running, FTP and HTTP with +FAT and microSD card. I also enabled logging for FTP and HTTP, in the FTP logs I keep getting this message: prvListSendWork: Unknown error (rc) = (-2113601484) it happens around line 1767 in the file FreeRTOSFTPserver.c. Note that I got my own logging mechanism going, so I had to change the original formatting a bit. I suppose the original message would look like this: prvListSendWork: Unknown error (rc = 82050034) Again, FTP is working fine, navigating through dirs, copying both directions, renaming, deleting. There are also no suspicious messages in the FileZilla console/log area. I am just wondering what this “error” means. Regards, Pascal

in the FTP logs I keep getting this message: prvListSendWork: Unknown error (rc) = (-2113601484)

Sorry about that 🙂 -2113601484 would be 0x82050034 which is a +FAT error code. A what? ~~~~~ /* See ff_error.h */ * Error codes are 32-bit numbers, and consist of three items: * 1Bit 7Bits 8Bits 16Bits * . …….. …….. …….. …….. * [ErrFlag][ModuleID][FunctionID][– ERROR CODE –] ~~~~~ It is a 32-bit ‘signed’ number, which contains the Module ID (source file), a function ID and an error code. The error code 0x34 is very innocent, end-of-dir:

#define FF_ERR_DIR_END_OF_DIR    52

In the later version, you won’t see this error any more. Within ff_stdio.c, these codes are translated from FF_Error_t to a comparable errno value. In the latest version, both error codes are accessible:

int stdioGET_ERRNO();
FF_Error_t stdioGET_FF_ERROR();

The idea of the FF_Error_t is to make debugging a lot easier. The functions in ff_error.c will print a readable error like e.g. : ~~~~~ fffile.c:: FFExtendFile:: The file was not opened for writing ~~~~~ which gives a lot more information than an errno 13: EACCES /* Permission denied */

Again, FTP is working fine, navigating through dirs, copying both directions, renaming, deleting. There are also no suspicious messages in the FileZilla console/log area.

Good to hear, thanks. Regards, Hein

All right, thank you for clarifying this. Regards, Pascal