How would I place the entire uTasker file system on the 4th SPI chip only

[jong56]

I am currently attempting (with the simulator) to have the uTasker file system reside on the 4th SPI chip only.  I do not use any internal flash, nor a parameter block and the first 3 SPI chips are using my own system that includes the boot loader files (I have modified the bare-minimum boot loader to handle the uTasker-style firmware upgrade format, but use my 'files' directly).

My desire is to use the 4th SPI chip (all are ST micro/Numonyx/Micron NOR SPI 'data file' chips with page erase/write, 2mB(yte) M25PE16) for the uTasker file system, specifically to handle all of my web pages.

Using the simulator, I was easily able to load a couple of my own pages using the standard setup (using internal flash).  I then 'placed' the pages in the 'first' SPI chip and all worked properly there.

I then attempted to set the various defines to set the start of the file system to the last chip and make the file system size just 2 megs.  This did not work for two reasons: 1) even though the buffer was the correct size for the chips (8mb), it is attempting to access memory beyond the buffer when the ftp command del *.* is attempted and 2) If I expose all 8 megs as the physical size of the memory, but only have the spi flash size set to 2 megs, the simulator still attempts to clear ALL 8 megs.

I do not have to span multiple chips, just one.  As far as I can see, I have the granularity set properly (it is the size of the chip's sub-sector I believe for erase purposes).

So, how would I set the uTasker defines for a 4th SPI chip-only uTasker file system.

                                                  - jon 

[mark]

Hi Jon

The first thing that I note is that the FTP *.* doesn't seem to be deleting just the 4^th SPI Flash as you would like it to do. The FTP *.* is special due to the fact that it doesn't just delete all existing files (as the wildcard would usually do) but instead causes an erase of the complete file system are to be performed; the reason behind this is that it can be used to ensure that every byte of memory in that area is reset to the 0xff state and so can be used to clean up any corruption (or a chip with random content) as well, if needed.

The actual command that it causes to be executed is:
uFileErase(uFILE_SYSTEM_START, (MAX_FILE_LENGTH)FILE_SYSTEM_SIZE);
where the uFILE_SYSTEM_START needs to be equal to the start location of your 4^th chip and FILE_SYSTEM_SIZE needs to be the size of your 4^th chip (or smaller).

I would therefore expect that there is a discrepancy between these settings if the erase function attempts to delete anything more that the content of the 4th SPI Flash chip.


I will assume that the internal Flash starts at 0x00000000 and is 256k bytes in size (0x40000). The SPI Flash devices are not physically in the memory map but they are virtually mapped there and it is assumed that the SPI Flash range (8MByte in total) therefore starts at 0x40000 and ends at 0x840000. (Generally it follows immediately after the internal Flash in the memory map).
The 4^th chip thus occupies the range 0x640000..0x83ffff and has a size of 2MByte (0x200000).

This suggests that the correct settings would be
#define uFILE_SYSTEM_START 0x640000
#define FILE_SYSTEM_SIZE     0x200000

This should be fairly easy to verify in the simulator by ensuring that the values passed to the routine cause only content of the 4th Flash chip to be erased.
Also a quick test of MEMORY_RANGE_POINTER ptrFile = uOpenFile("0"); should return the address of the start of the file system - 0x640000.

Since you are using data flash, which supports a sub-sector erase of 4k, the file system's file granularity should be a multiple of this 4k value. With 4k it would allow up to 62 files of 4k size (or less of larger), with the final file capable of being up to 1.7MBytes. Probably, a more optimum setting is therefore 32k file granularity, which would give 62 files at 32k (or less of larger) with the final file capable of holding 76k.

Finally note that latest package versions contain an extended file system option which would allows 512 individual files of 4k granularity to be stored in a 2Meg SPI Flash chip (without the 62 file limitation). Full information concerning this feature will be published shortly.

Tell me if thsi helps to 'tune' the file system settings to solve your problems.

Regards

Mark

[jong56]

Thanks Mark for the file granularity info as this will help with our actual page sizes.

I appreciate the info on the various defines and must tell you I have already done this and everything matches what you have shown.  So maybe it is my confusion at the point.

I currently see a sim buffer that is the size of a single chip and this is correctly loaded with my pages.  I guess my concern was to make sure (prior to copying this to my actual system on the eval board) that I could see three chips left alone and the last chip being used.  I guess the simulator must take care of the 'chip-select' as it should based on the starting address of the file system and this is 'hidden' (though I have seen it pick correctly based on the address).

I was attempting to see a buffer that was 3/4ths empty (zeros) and the end used.  Obviously using only a single chip size for the file system, you only create a buffer that size and the system does not know anything about the other physical chips other than the starting virtual address.  This as stated should get uTasker to select via the proper CS line.

I will now move this all to the real world and make sure all remains as such.

Thanks again as always.

                                                - Jon   

[mark]

Jon

To be sure about the fact that 4 SPI chips are being used:
1) SPI_FLASH_MULTIPLE_CHIPS should be defined
2) SPI_FLASH_DEVICE_COUNT should be 4
3) CS0_LINE, CS1_LINE, CS2_LINE and CS3_LINE should be set to the port outputs that they are being controlled on.
4) SPI_DATA_FLASH_0_SIZE, SPI_DATA_FLASH_1_SIZE, SPI_DATA_FLASH_2_SIZE and SPI_DATA_FLASH_3_SIZE should each be set to the size of the individual chips (in fact it is generally assumed that each used device will be the same size since it doesn't make much sense to mix chip sizes - also not from a price/logistic point of view in a production project).
If the simulator is saving a flash file (to the harddisk on simulator termination) that is not 8 Meg in size it is probable that these defines are not set (the extended ones default to 0).

I would also check in the simulator that the 4^th chip select is being set correctly when accessing uFileSystem files.
When you call your own routines the corresponding chip select can also be verified - the control of this is not file systen specific but memory map specific; this means that the file system will always cause the 4^th CS to be used based on the fact that it is always accessing the 4th chips memory area, but any other use of the low-level access read/write routines will cause whatever CS to be selcted as necessary.

You can get the info as to the CS when the routine fnGetSPI_FLASH_address() is called, which then calls fnGetSPI_Device() to chose the exact chip.
In the SPI simulator part (in WinSim.c) fnSimSTM25Pxxx() first checks which of the port outputs is set to zero to determine which of the chips it will read and write from/to so you can also put breakpoints in the code that would detect either unexpected CSs to be found to be asserted or a breakpoint in the one that you are expecting to be asserted in order to identify the cause of either incorrect or correct accesses.

Regards

Mark

[jong56]

Thanks and once again I actually have done this and all of this is correct as you specified.

I went ahead and ported it to my eval board code and it works great.  I guess I was a bit worried from my lack of understanding of the simulator, but it is all good.

I confirmed that all of the other 3 SPI chips are not affected.  FTP works correctly as well as the pages.

Thanks again and as usual, uTasker is not as complex as it first seems.  Take care.

                                                   - Jon 

[mark]

Hi Jon

Nice to hear that things worked first go on the HW target.

I think that it is best to spend a short time ensuring that all is really operating correctly in the simulator (testing cases and ensuring that understanding is correct) before spending (potentially) a lot of time trying to work out why it is not doing what it should on the HW ;-).
Debugging errors in real SPI Flash is not the easiest thing in the world !!

Regards

Mark

[jong56]

Mark,

Thanks and I agree, except I have been working with these chips on the NE64 for the past 6 years (ok, I used the 1MB version of the SPI at the start) so debugging on a real system is easy for me and I am more used to that than checking everything out with the simulator.

Now with that in mind, I may have found an issue still with selection of the proper chip.  My previous post was a bit in error in that it turned out uTasker was STILL selecting the first chip even with all the address correct.

So what I found (when I do a DIR command from ftp) was this.  I will attempt to show this as basic flow in uTasker...

At the dir the processing path goes as follows along with the virtual starting address value as follows (=> means called from previous routine/system)

=>fnDoDir                           (starting address not set)
=>uOpenNextMimeFile           (starting address passed as zero to force it to set)
=>uGetFileLength                 (starting address is now set uFILE_SYSTEM_START
                                            value which is 0x00640000)
=>fnGetParsFile                    (NOW, inside the routine, the address is zero)
=>fnGetSPI_FLASH_location  (starting address is zero)
=>fnGetSPI_Device               (starting address is zero and the returned chip is 0)

So I do not know if maybe I have an optimization issue or what, but this loss of the starting address is what I did see in the simulator. 

Now something even more interesting, if I hard-code the chip-select value to 3 in the fnGetSPI_FLASH_location instead of calling fnGetSPI_Device, everything works perfectly (really!!) and when I debug, I notice that I do NOT loose the starting address at all (as I am not using it to determine which chip) throughout the 'same' sequence I described above.

In any case, I will leave it hard-coded for now as this will remain this way for this device.  Just figured I would let you know what i found.

Thanks.

                                            - jon 

[mark]

Hi Jon

I just checked carefully the flow to see whether I could explain this.
However I can't at the moment;
fnParsFile() passes the same pointer that it receives to fnGetSPI_FLASH_location() so I don't see how it can get set to zero there.
In fnGetSPI_FLASH_location() the value is referenced to the start of the SPI Flash area (pointer - SPI_FLASH_START) so an address towards the end of the area should still have a large value, which will then cause fnGetSPI_Device() to select a higher chip select line.

Is it possible that you are not using both SPI_FILE_SYSTEM and FLASH_FILE_SYSTEM? This may then reference to the start of the file system and not the start of the storage area, which would not give the correct CS line - this mode was originally used for uploading SW to SPI Flash without it being in the file system; the mode is sometimes still used but became almost reduncant when the SPI Flash operation was combined with the file system.

Regards

Mark

[jong56]

Mark,

No, they are both set.  I am not sure as I said why, but the loss I see is actually on the call to fnGetParsFile.  The value of the start address passed using the pointer is correct in the calling routine uGetFileLength and once I step into fnGetParsFile, the value changes to zero and remains that way. 

Now I know this is actually a virtual pointer, but VS (and I assume any c/c++ compiler) thinks it is a 'real' pointer.  Would it be safer to pass a pointer to this virtual pointer as you do elsewhere (though as with dbl pointers, you can change the pointer's pointer as I believe you do where you use this...) and de-reference it for use?

I guess I do not see this as an issue with the settings but possible how these virtual ptrs are resolved via the linker, etc. which was why I was thinking a setting like for optimization was incorrect.

In any case, I can work with the static chip select as this is actually what I am doing (I really do NOT want to make which chip is the file system user-configurable).  I can easily use the various defines already in place to set this static select value.  Everything else in the file process on both the simulator and the Coldfire seem to work just as expected.

Thanks again.

                                         - jon 

[mark]

Hi Jon

I try to keep pointer real as long as possible (then the real value is seen when debugging, which is helpful). When the simulator needs to acces the memory there is usually a conversion between the real pointer and a simulated memory pointer. In the case of internal FLASH (the most common case) the routine fnGetFlashAdd() is used (this is a dummy routine when compiling for the target but converts from real to simulated flash when simulating). In some cases the converted address is left in the code (eg. when needed in a lot of lines to avoid each needing its own conversion) and can be converted back again to the real address with fnPutFlashAdd().

I won't look at the behaviour that you noticed in any more depth at the moment since I have just prepared a new revision of the uFileSystem which allows a few more features and also uses a more generic method to control multiple storage areas - also made up of multiple devices if required. The techniques are much easier to maintain so it would be better to study it in that environment in case similar issues are encountered in the future.

It has just been tested on a new storage media (multiple external parallel flash memories) and it was rather easier to add this in the revised version because the generic parts do the file interface work and the new driver is well encapsulated away from the higher level details. There are a few things to update in two new documents and then it will be available (initially in the next M522xx package) but will then be standard in all other versions as they are next revised.

Regards

Mark