FTP Failure on upgrade image

[frank]

Hi,

I have a custom board based on MCF52232 and Numonyx STM25P16 SPI flash. When I tried to upload a new upgrade bin image ( 0_Upload_Enc.bin ) which has a size of 71K, the FTP connection got  timed-out. Even after deleting all the files in FTP ( using DEL *.* )  FTP connection still got timed-out.

But when I tried to upload files ( not the upgrade file, but some simple text files) which has size of less than 64k  , the upload was successful.

In the app_hw_m5223x.h file, the following macros are enabled.

SPI_FLASH_ST
SPI_FLASH_STM25P16

#define SPI_FLASH_PAGES             (32*256)

#ifdef FLASH_FILE_SYSTEM
    #if defined SPI_FILE_SYSTEM                                          // this is a test setup for external SPI FLASH, with the parameters at the end of internal FLASH
        #define PARAMETER_BLOCK_START 0x1f000                            // {34} FLASH location at 2 parameter blocks short of end of internal FLASH
        #define uFILE_START 0x20000                                      // immediately after internal FLASH



Am I missing anything ??

[frank]

The device was active even after the FTP connection timed-out. I can able to ping the device, telnet was working fine.  I can also able to upload the image on the simulator version of the device.

[mark]

Hi Frank

There is nothing obvious that is causing this. Is the board resetting when it occurs or is it restricted to the FTP connection ? (Note that it may be resetting and afterward everything will otherwise seem OK).

Can you show a Wireshark recording of the transfer?

Regards

Mark

[frank]

The hardware was not resetting at the time of FTP timeout. I will send you the wireshark file shortly.

[frank]

Hi Mark,

Please find attached the pcap file.

192.168.15.3 - is the host ip address
192.168.15.120 - device ip address

C:\>ftp 192.168.15.120
Connected to 192.168.15.120.
220 Welcome M5223X FTP.
User (192.168.15.120:(none)):
331 Enter pass.
Password:
230 Log OK.
ftp> bin
200 OK.
ftp> put 1_nov15.bin
200 OK.
150 Data.
> Netout :Connection reset by peer
Aborting any active data connections...
Connection closed by remote host.
ftp> quit

C:\>

[frank]

Here is what happens when I do del *.*, and the corresponding PCAP


C:\>ftp 192.168.15.120
Connected to 192.168.15.120.
220 Welcome M5223X FTP.
User (192.168.15.120:(none)):
331 Enter pass.
Password:
230 Log OK.
ftp> dir
200 OK.
150 Data.
-r-xr-xr-x 1 502 502 1150 May 1 2009 favicon.ico
226 OK.
ftp: 50 bytes received in 0.16Seconds 0.31Kbytes/sec.
ftp> del *.*
Connection closed by remote host.
ftp>

[mark]

Hi Frank

From the FTP recording it is clear that the first 44 TCP frames (about 64k) are being accepted normally but after that there is no further response. The FTP client is giving up after about 40s.

I support that you are using a code FLASH with 64k sectors. The delete time for a sector is specified to be about 0.6s (max. 3s). Possibly, when the sector boundary is reached it is necessary to start an erase of the next sector, which will cause a delay. However the delay is too long - even if it were to start erasing the complete chip this would typically require 13s (maximum 40s).  So I am wondering whether maybe the sector is protected? Perhaps this causes the delete (or the write) to fail once use of this sector is attempted. (The simulator seems to show that no problems are expected in the normal case, but it doesn't simulate things like protected sectors). It may be that the error return codes (of any) from the low level write/delete attempts doesn't cause any particular error message in at the FTP interface so it just sort of freezes.

Take a careful look to see whether something like this may be an explanation.

Regards

Mark

[frank]

Hi Mark,

Yes. The SPI flash was 64k sector size ( STM25p16).

[frank]

Hi Mark,

Why does the FTP mechanism tries to delete all the sectors when the file size is just 71k ( needs 2 sectors ).  If protector sector is the problem,  why can't it happen on the first sector. If there any way I can findout whether the sector is protected or not ?. Please suggest a solution.

[mark]

Hi Frank

If a following section is not deleted and the file needs more space the file system will delete it to make space for the data. If it is not deleted you would however see a file (probably 2.xxx) with FTP DIR.

A protected chip would also block writing though, so it may not necessarily be a delete problem.

If you read the status register of the SPI FLASH you can see the chip's protection status. I don't actually believe that this is the problem since I don't think that it is possible to protect just the higher sectors, but it may help to check it to understand the difficulty.

Regards

Mark

PS. I have in fact used 4 x 8MByte chips from this family on a single board, giving 32MByte using 4 Chip select lines. This was also copying a large file of up to 32MByte. Therefore I didn't experience any basic problems with the ST chips.

[frank]

Hi Mark,

If "delete" is the problem, if I manually delete the first 2 sectors in the SPI flash ( via a CLI command ), do you think the FTP process will still try to delete the 2nd sector.

Could you please let me know the commands to erase SPI flash sectors ?.

Thanks

[frank]

Hi Mark,

The document http://www.utasker.com/docs/uTasker/BM-Booloader_for_M5223X.PDF, page 7 ( Uploading new software via Ethernet - external SPI flash ),describes SPI_SW_UPLOAD needs to be enabled in both boot loader and application. But I read somewhere in the forum that SPI_SW_UPLOAD  needs to be enabled only in boot loader ( FLASH_FILE_SYSTEM AND SPI_FLASH needs to be enabled both in boot loader and application ). which one is correct ?.

Thanks

[mark]

Hi Frank

In fact both are correct but the document is a little outdated and doesn't include a configuration.

The history is as follows:
1) Originally the uFileSystem worked in internal FLASH and there was no support for external devices.
2) The SPI FLASH driver was added but didn't support the uFileSystem. That is, it supported low-level reading and writing but not interfaced to the uFileSystem.
3) at this point in time the requirement for uploading new firmware to this area was added. This means that the upload was a special case and was saved to the external SPI FLASH, whereby all other file activity was in the internal FLASH. The settings described in the document are correct for this. The boot loader itself uses the same define since it also uses the drivers.
4) The next development was the ability to operate the uFileSystem in external SPI FLASH (in fact it can be configured to operate in both at the same time, whereby the first area starts in the internal FLASH and then it overflows to external SPI FLASH). The consequence is that the firmware upload is not performed as a 'standard' file since it can also be located at the correct position in external SPI FLASH. Since the boot loader doesn't need to be concerned with the uFileSystem its setting is the same - that is with SPI_SW_UPLOAD set. The application uses SPI_FILE_SYSTEM and FLASH_FILE_SYSTEM for this configuration and doesn't need SPI_SW_UPLOAD (in fact this shouldn't be set to be absolutely sure).

I did think that this new ability would make SPI_SW_UPLOAD use in the application redundant; when the file system is used in external SPI FLASH this is also the case. However, if one wants to have the uFileSystem entirely in internal FLASH and use an SPI FLASH purely for firmware uploads then the original setup is in fact still the best way to do it...

I hope that this explains the situation and allows you to decide which settings are best for yourself. I have noted that the document needs a review and will get this updated shortly.

Regards

Mark

[frank]

Hi Mark,

Thanks for the information. It is very useful.

My requirement is I want to keep both file system and upload software in external SPI flash. The standard webserver files ( from original utasker code)  works fine with the external SPI flash ( since the file size is less than 64K, I don't find any issues with STM25P16 spi flash ). But I am struggling to upload the new bin files which has greater than 64K size.

I am thinking of manually deleting the 2 sectors where the upload file is going to reside , then try FTP.

Do you like to give any more input ?.

Thanks in advance.
- Frank

[mark]

Hi Frank

In your case the SPI_SW_UPLOAD in the application is certainly not needed.

Unfortunately I can't think of any further tips concerning the upload problem of files greater than 64k. I haven't experienced this.

Regards

Mark