TFS driver(s)

TinyCLR OS
1

This is a new thread regarding TFS issues seen here : Click drivers from MBN - #33 by Bec_a_Fuel

@dat_tran : if I look at your source code in TinyFileSystem.cs, I can see the following :

this.blockDriver = new BlockDriver(storage, storage.PagesPerCluster);

            // Precalculate commonly used values based on the device parameters provided by the block driver.
            this.totalSectorCount = (ushort)(this.blockDriver.DeviceSize / this.blockDriver.SectorSize);
            this.clustersPerSector = (ushort)(this.blockDriver.SectorSize / this.blockDriver.ClusterSize);
            this.totalClusterCount = (ushort)(this.blockDriver.DeviceSize / this.blockDriver.ClusterSize);

Btw, those are the same in our driver, naming convention apart.

But, you set the following values in the qspi driver :

public override int Capacity => 0x1000000;
public override int PageSize => 0x1000;
public override int SectorSize => 0x1000;
public override int BlockSize => 0x1000;

So, when the constructor gets called, you will have (pseudo-code) :

this.totalSectorCount = 0x1000000 / 0x1000 = 0x1000;
this.clustersPerSector = 0x1000 / 0x4000 = 0;
this.totalClusterCount = 0x1000000 / 0x4000 = 0x400;

The clustersPerSector value being 0 will throw an exception later in the code. So I don’t understand how setting the same 0x1000 value for all properties can work on your side :open_mouth:

Also, can you tell me what are the meanings of the different parameters in the different qspi methods, please ?
I’m confused between addresses, sectors, bytes, etc…

2

From the W25Q128JV datasheet, I can see (bold text by me) :

The W25Q128JV array is organized into 65,536 programmable pages of 256-bytes each. Up to 256 bytes can be programmed at a time. Pages can be erased in groups of 16 (4KB sector erase), groups of 128 (32KB block erase), groups of 256 (64KB block erase) or the entire chip (chip erase). The W25Q128JV has 4,096 erasable sectors and 256 erasable blocks respectively. The small 4KB sectors allow for greater flexibility in applications that require data and parameter storage.

So values in our driver are correct :

public override Int32 Capacity => Flash.IsEnabledExternalFlash() ? 0x00800000: 0x01000000;
public override Int32 PageSize => 0x100;
public override Int32 SectorSize => 0x1000;
public override Int32 BlockSize => 0x10000;
3

It was 0x400 in my code, not 0x1000, sorry about that.

They are correct, but I think PageSize and BlockSize effect to TFS only, nothing to do with StorageController which exposes Sector only.

4

Yes and no :wink:

Yes for the Erase() method. And this showed an issue in my driver in the BlockErase() method. It is now using “sector size” as reference to calculate both address and count.
Now that this is fixed, our TFS implementation does work on both the RAM board and the SC20260D dev board now :slight_smile:
With the parameters above for TFS.

No for the Read/Write methods, however. A newly formatted block on which you save a Byte[3] array (say at address 10, for example) will show expected values at addresses 10, 11 & 12 and will show 0xFF starting at address 13. Which obviously means that nothing is written past the count bytes sent to the Write() method.

A clarification on all those parameters and their meanings would be welcome in the docs, to me.

Anyway, the driver on our repo is now up-to-date with the fix and the variable capacity depending on External Flash used for deployment.

1 Like