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:\BJK\uZED701_bsp\system.mss
13**54 WARN : [Hsm 55-1559] Software Design already exists with Name D:\BJK\uZED701_bsp\system.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.
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.
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 (FreeRTOS_FTT_server.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.
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.
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 niBUFFER_1_PACKET_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.