Macro definition uFILE_SYSTEM_START

[frank]

Hi,

I am evaluating uTaskerV1.4 version. In the uTasker application folder, in config.h file the following two lines are present.

#define uFILE_SYSTEM_START (MEMORY_RANGE_POINTER)(uFILE_START)
#define uFILE_SYSTEM_END   (MEMORY_RANGE_POINTER)(uFILE_START + FILE_SYSTEM_SIZE)

uFILE_START is declared in app_hw_5223x.h file, which is included in config.h via types.h. But this file is included after the above two lines. Is it right ?.

I want to override the value of uFILE_START with custom value ( i want to start the uFILE_START in external SPI flash). Do I need to redefine the above two lines, or do i need to make change in app_hw_5223x.h file?.

Please confirm.

Thanks

[mark]

Hi

The file system dimensions are indeed declared in app_hw_m5223x.h. The include order is, in this case, not that important.

To place the uFileSystem in external SPI FLASH you can do the following:
- in config.h activate BOTH SPI_FILE_SYSTEM and FLASH_FILE_SYSTEM, which will enable support of the uFileSystem in external memory (or a mix of internal and external memory).

In app_hw_m5223x.h this will already cause a default configuration to be used [based on one of the three supported SPI FLASH types: AT45DB, STM25 or SST25]:
Eg.
        #define PARAMETER_BLOCK_START 0x3f000                            // FLASH location at 2 parameter blocks short of end of internal FLASH
        #define uFILE_START 0x40000                                      // immediately after internal FLASH
        #define FILE_SYSTEM_SIZE (64*SINGLE_FILE_SIZE)               // 1Meg reserved for file system (assuming 8k file size)

By adjusting these (and the exact SPI FLASH  chip(s)) you can then set the address location and size of the SPI based uFileSystem accordingly.

Regards

Mark

[frank]

Thanks. I have enabled both FLASH_FILE_SYSTEM and SPI_FILE_SYSTEM. I would like to place the file system in external SPI. I have done the following changes in the app_hw_m5223x.h file.


#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

        #define SINGLE_FILE_SIZE (FILE_GRANULARITY)                      // each file a multiple of 16k (64k ST)
        #if SINGLE_FILE_SIZE < 20000                                     // {36}
            #if SPI_DATA_FLASH_SIZE < (64*SINGLE_FILE_SIZE)              // {42} allow testing smallest SPI FLASH
                #define FILE_SYSTEM_SIZE  SPI_DATA_FLASH_SIZE
            #else
                #define FILE_SYSTEM_SIZE (64*SINGLE_FILE_SIZE)           // 1Meg reserved for file system (assuming 8k file size) {34} [PAR_BLOCK_SIZE removed]
            #endif
        #else
            #define FILE_SYSTEM_SIZE (16*SINGLE_FILE_SIZE)               // 1Meg reserved for file system {35}
        #endif
    #else       
///


===

The board has AT45DB011 SPI ( 128K).

Following config for this chip is enabled.

 #define SPI_FLASH_AT45DB011                                          // {31} define the ATMEL type used here
  //#define SPI_FLASH_AT45DB021
  //#define SPI_FLASH_AT45DB041
  //  #define SPI_FLASH_AT45DB081
  //#define SPI_FLASH_AT45DB161
  //#define SPI_FLASH_AT45DB321
  //#define SPI_FLASH_AT45DB642
  #define SPI_FLASH_AT45XXXXD_TYPE                                     // specify that a D-type rather than a B type is being used


After done all the above changes, the ethernet link is not coming-up. When I disabled the SPI_FILE_SYSTEM, the ethernet link is up and running.  When I look at the nearest ethernet switch where the board is connected, the link LED ( in the switch) is comes ON and goes OFF.  Looks like the application is crashed and rebooted or something else.

Did I miss anything ?. Help is much appreciated.

[mark]

Hi

1) make sure that you have selected the ATMEL family in config.h by disabling alternatives:

      //#define SPI_FLASH_SST25                                          // use SST SPI FLASH rather than ATMEL
      //#define SPI_FLASH_ST                                             // use ST FLASH rather than ATMEL
      //#define SPI_DATA_FLASH                                           // FLASH type is data FLASH supporting sub-sectors (relevant for ST types)

2) I believe that the AT45DB011 is available as B and D types. Setting SPI_FLASH_AT45XXXXD_TYPE is in fact only used by the simulator to known whether it should respond to D-type commands or not and not be the embedded code.

3) I don't see anything else which is wrong; the uFileSystem size if being set to be equal to 135'168 byes (the site of the memory in the chip in 264 byte page mode).

4) When I simulate these settings I don't see any problems either.

If the SPI FLASH is not working correctly I do see a danger when the define INTERNAL_USER_FILES and EMBEDDED_USER_FILES are enabled. The reason is that the SPI FLASH is checked on start up (see fnCheckAT45dbxxx() in spi_flash_m5223x_atmel.h) and should match with one of the IDs read. If this is not the case the QSPI interface will be set to low power mode again. With a debugger you can see whether this check is successful (whether it can read the chip's ID or not).
The above configuration (with embedded user files) checks in the file system to see whether there are embedded user files present (see fnActivateEmbeddedUserFiles() in application.c) and this will probably cause a crash since it expects the QSPI interface to be active (it will not be if the SPI FLASH could not be found!!).

Otherwise there would not be a crash until an attempt to server web pages or check files by FTP were made.

Therefore I suggest first checking that the FLASH is really identified. Be careful that any leads between processor and FLASH are as short as possible - less than 2inches when flying connections are used - since there have been many problems with this; the chips are very sensitive to ringing on these lines and may not allow the ID to be read if this happens (even connecting an oscilloscope to the lines has been known to cause it to fail too!).

You can also activate the SPI FLASH test in application.c (#define TEST_SPI_FLASH) and then step through fnTestSPIFLASH(), which will test whether a page in the chip can be successfully read, written and deleted. [Beware that the possible hang mentioned above occurs BEFORE this test, so ensure that it gets that far.]

Regards

Mark

[frank]

Hi Mark,

The test was re-run with M25P20 SPI flash. The result was same. But after disabling INTERNAL_USER_FILES  and EMBEDDED_USER_FILES  macros, the device came-up. ping and telnet works.

The only issue is FTP didn't work as expected. After opening the ftp session, executing the "dir" command hangs the session.

Do you think something wrong with the flash configuraiton ?.

[mark]

Hi Frank

FTP uses the file system (in SPI FLASH) and so can have problems if something is not configured correctly. However check also that the SPI FLASH is completely deleted when starting.

You may also like to check whether just disabling EMBEDDED_USER_FILES may also help. The reason is that this also uses the file system to search for a file with an embedded user file  - if the SPI FLASH contains 'strange' data (not blank when first run) it may also cause this to immediately fail (similar to FTP failure).

If this does turn out to be the problem I think that it may be useful to add a file system clean-up routine which verifies the file system integrity on each start. It could then delete all sectors which contain obviously invalid data which could cause later use to fail. Eg. if it find files which are larger than the physical chip size they are obviously invalid and so the complete invalid space could automatically be cleared out. Try typing DEL *.* when connected via FTP (before attempting a DIR), which should result in the file system area being fully erased.

Regards

Mark

[frank]

Hi Mark,

I have just disabled EMBEDDED_USER_FILES, not INTERNAL_FILES. The behaviour is same, meaning  we can ping, telnet the device. But FTP behaviour is same. When the DEL *.* command is executed in the FTP session, the session is just closed.

C:\Documents and Settings\Sundar>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> del *.*
Connection closed by remote host.
ftp> quit

[mark]

Hi Frank

Unfortunately I can't explain this behavior at the moment.

I will send you a connection to an FTP account - could you zip your entire project (delete any simulator object files in the simulator directory in case you have been using the simulator - eg. "uTasker___Win32_uTasker_M5223X_plus_GNU_build" since the objects can be rather large) and transfer it. I will then test it on my hardware (and in the simulator) to see what is going on.

Thanks

Regards

Mark

[frank]

We tried Atmel AT45DB011D and STM Micro STM25P20 SPI flashes.

For STM25P20 chip, I found an issue in the file Hardware/M5223X/spi_flash_m5223x_stmicro.h.  The function fnCheckSTM25Pxxx is not checking device STM25P20 chip. I will modify the code and try.

For Atmel SPI, Status Register Format is slightly different between AT45DB011D and AT45DB011B device. The code is checking for AT45DB011B, not D.  I am not sure whether the device density check ( STATUS_1MEG 0x0c ) is correct. Because bit5,bit4,bit3,bit2 needs to be considered, not bit 0 and bit 1.

Please confirm.

[mark]

Hi Frank

AT4DB011D. This is in fact not a supported device (that is it is not recognised since it is not in the list). When the ATMEL AT45DB driver was written the smallest D-type chip seemed to be the AT45DB041D. If it is not in the D-type list it will then check the status register to see if it can identify a B-type chip. The AT45DB011B should return 0x8c and then be recognised. Possibly the AT4DB011D is also not recognised in this case?

In the case of the STM25P20 I remember that you added the configuration for it (when the driver was written it seemed as though the STM25P40 was the smallest). In this case, since it is not in the list (as you have identified) its size (from manufacturer ID) will not be recognised, causing the SPI interface to be deactivated. This can/will lead to problems accessing the file system.

It looks as though the range of supported chips will need to be slightly extended (basically adding the additional types in the list).

In addition there may be code (I didn't actually see it though in the demo project) where the SPI FLASH will also be rejected it it is smaller that a certain value.

If you have difficulties adding your devices tell me. I will download the latest data sheets to see what is new to make sure that nothing else is missing. Also tell me if you then manage to get the system up and running after there adjustments.

Regards

Mark

[frank]

Hi Mark,

Here is the latest datasheets.

M25P20-VMN6TPB : http://www.numonyx.com/Documents/Datasheets/M25P20.pdf
M25PE20-VMN6P: http://www.numonyx.com/Documents/Datasheets/M25PE20_10.pdf
AT45DB011D-SH-B: http://www.atmel.com/dyn/resources/prod_documents/doc3639.pdf
AT45DB021D-SH-B: http://www.atmel.com/dyn/resources/prod_documents/doc3638.pdf

[mark]

Hi Frank

I have integrated the AT45DB011D and AT45DB021D into the project so that they are recognised as D-type.

However I noticed that, although they were not being recognised as D-types before this would not cause a problem since their status register was subsequently checked and this gives the correct size information. Therefore I don't actually see why this would cause these types to fail.

I will continue and integrate the ST parts and tell you what happens.

regards

Mark

[mark]

Hi Frank

On the ST (Numonyx) site I have seen that the ST25P family is now offered in sizes from 64k up to 16M (the driver presently supports 512k up to 8M).

Therefore I integrated the 4 additional parts (3 smaller and one larger) and tested the 128k part (before and after integration):
- originally the chip size was not recognised and this indeed caused the SPI interface to be disabled.

It was necessary to extend the list of valid devices so that the type was recognised, and also to change the check of size (in spi_flash_m5223x_stmicro.h) from

    if (ucSPI_FLASH_Type[0] < STM25P40) {                                // we expect at least this part to be available

to

    if (ucSPI_FLASH_Type[0] == NO_SPI_FLASH_AVAILABLE) {                  // we expect SPI FLASH to be detected


Therefore I would expect an improvement when the list is extended and the check above is modified.

Regards

Mark

[frank]

Hi Mark,

It is much better now. FTP is not hanging after executing "dir" command. But we got an another issue. ..

We've uploaded the standard uTasker webserver files such as 0Menu.htm, 1Lan.htm ..etc. After uploading the files, if we execute "dir" commands, it is not displaying the actual file name.

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
-rwxrwxrwx 1 502 502 1360 May 1 2009 0.HTM
-rwxrwxrwx 1 502 502 2007 May 1 2009 1.JPG
-rwxrwxrwx 1 502 502 1608 May 1 2009 2.HTM
-rwxrwxrwx 1 502 502 5 May 1 2009 3.TXT
-rwxrwxrwx 1 502 502 1360 May 1 2009 4.HTM
-rwxrwxrwx 1 502 502 2007 May 1 2009 5.JPG
-rwxrwxrwx 1 502 502 1608 May 1 2009 6.HTM
-rwxrwxrwx 1 502 502 5 May 1 2009 7.TXT
-rwxrwxrwx 1 502 502 1360 May 1 2009 8.HTM
-rwxrwxrwx 1 502 502 2007 May 1 2009 9.JPG
-rwxrwxrwx 1 502 502 1608 May 1 2009 A.HTM
-rwxrwxrwx 1 502 502 5 May 1 2009 B.TXT
-rwxrwxrwx 1 502 502 1360 May 1 2009 C.HTM
-rwxrwxrwx 1 502 502 2007 May 1 2009 D.JPG
-rwxrwxrwx 1 502 502 1608 May 1 2009 E.HTM
-rwxrwxrwx 1 502 502 5 May 1 2009 F.TXT


In the config.h file both INTERNAL_USER_FILES and EMBEDDED_USER_FILES macros are enabled.

Individually each file can be accessed via the webserver. But if we browse through the menu page, the links are broken for the other pages.

[mark]

Hi Franklin

The sizes of the files don't look right - there are files (like 1.jpg) which are not in the standard web pages, and the entries are being repeated.

This suggests that something is not matching yet. Which FLASH are you using - I see that the AT45DB011D can be factory programmed to use 254 byte pages rather than 264 byte pages; could this be something (there are settings for both page sizes)?

I would start with a blank file system (DEL *.*) and load a small test file called 0.html and check that you can browse it and that its size is correct in FTP. Then increase the size of the file (covering one SPI FLASH page, then 2 pages, then 3 pages, etc. - watch its size and whether it display correctly - if something goes wrong at a boundary somewhere it is a good clue to what it is.

Then try the same for a file '1.html', 2.html' etc. to see whether this gives any ideas.

Note that it is normal that only the first letter of the name is displayed (see the guides at http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF and http://www.utasker.com/docs/uTasker/uTaskerFileSystemSPI_FLASH_003.PDF )

Regards

Mark