hello, I am now working on FreeRTOS Lab version 150825 to pick up tcp stack in our Zynq application. I found there is some issue when I use ftp protocol to transfer file, where some bytes are corrupted especially when the file is large, for example, when we transfer ~400kB file, the issue occur every time, but it works well all time when file size is ~100B.

I use Notepad++ to open the transfered file and found during some bytes, 4 bytes will be written to NULL like this:

13:28:54 WARN : [Hsm 55-1559] Software Design already exists with Name D:BJKuZED701bspsystem.mss 1354 WARN : [Hsm 55-1559] Software Design already exists with Name D:BJKuZED701bspsystem.mss

I found 10 corruptions in file of 400kB size. The issue only occur when transfer file from PC to freeRTOS, but did not find corruption from freeRTOS to PC. Could anyone tell me how to identify the root cause? Thank you very much.

Is your FTP file written to a RAM disk or an SD-card? Could you send an email to h point tibosch at freertos point org? Then I will send you the latest sources.

Regards, Hein

Thank you for your reply! I have test ftp file write on both SD-card and ram disk. The corruptions are the same. I will email to your mentioned address soon.

Hi,

I can confirm that issue on 160112 ! Sometimes the last 4 bytes of each TCP FTP transmission of a large file are replaced with . I tested it on both SD-card and RAM disk. In some cases an undefined number of bytes of the following transmission part are replaced with or other chars too.

When debugging, you can see that bytes in the pcBuffer (FreeRTOSFTTserver.c - pvrStoreFileWork() )

In Wireshark the transmission is correct.

Hardware is Zynq.

I attached a sample file (testfile.txt), the wireshark recording and the corresponding file on SD-card.

regards Michael

Hi Michael

@Xiaoqing (fanksting) : you tried out a later release of the driver. Can you confirm that the problem with the nul-bytes had gone?

@Michael : while waiting for an answer, you might want to upgrade your /Labs library to the latest release 160908.

Very recently I worked on the Zynq driver to make it better. I attach a copy of the new 'xemacpsifdma.c' for those who want to try it.

The full name of the file is :

~~~~ FreeRTOS-Plus-TCP/portable/NetworkInterface/Zynq/xemacpsifdma.c ~~~~

Regards.

Hi Hein,

thanks for your answer.

ok... didn´t saw, that there´s a new release.

Succesfully updated my project to the latest release, did a clean build -> same as before. Replaced xemacpsifdma.c -> same as before.

cheers

same as before

Do you mean that the same problem still occurs? It feels like my memory is being tested. Looking at your .txt files and PCAP, I have seen it before and I solved it before.

Would you mind sending your FreeRTOSConfig.h and FreeRTOSIPConfig.h files? I'll have to play with it and see when and why this happens.

Michael, no need to send config files. I can replicate the problem now. I'll soon give an answer :-)

Hi Michael,

I'm very sorry, but the mistake was on our side. Every Zynq/CZ207 +TCP project must include :

~~~~ FreeRTOS-Plus-TCPportableBufferManagementBufferAllocation_1.c ~~~~

and not the x_2 version, which uses pvPortMalloc().

The problem is caused by the combination of memory caching and DMA: cache flushing/loading is always done per 32-bytes, whereas pvPortMalloc() will allocate just enough bytes for each buffer. The last word of a buffer may get corrupted if an adjacent buffer gets flushed or reloaded.

BufferAllocation_1.c will align all buffers statically and keep enough space between them. Although this was a bit exaggerated:

~~~~ #define niBUFFER1PACKET_SIZE 2048 ~~~~

The following configuration also works OK, it keeps all buffers 32-byte aligned :

~~~~ /* See FreeRTOS-Plus-TCP/portable/NetworkInterface/Zynq/NetworkInterface.c : */

#define niBUFFER_1_PACKET_SIZE        1568    /* Use a multiple of 32 */

static uint8_t ucNetworkPackets[ ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS * niBUFFER_1_PACKET_SIZE ]
    __attribute__ ( ( aligned( 32 ) ) );

~~~~

Defining niBUFFER_1_PACKET_SIZE in terms of ipconfigNETWORK_MTU or ipTOTAL_ETHERNET_FRAME_SIZE may cause problems in case the macro's contain uint32_t casts. My my compiler understood it wrong.

Regards.

As a test, I just FTP-copied 44,813 Files and 2,876 Folders to an SD-card and copied them back to my laptop.

After that I compared the 2 volumes: there were no differences.

I did use BufferAllocation_1.c and the above settings in NetworkInterface.c

Well done for spotting this and also for the solution. I have made a note on http://www.freertos.org/FreeRTOS-Plus/FreeRTOSPlusTCP/TCPIPFATExamplesXilinxZynq.html

Hi

Wow, great! sorry for my late response.

Thanks a lot!!!

I will check it now on my platform...

Hi again,

tested it by loading my boot.bin via ftp to SD-card several times and zynq booted successfully every time.

loaded a 85MB large file without errors.

many thanks!!! Michael