Results with external Flash enabled for deployment :
Formatting
Formatting done, seconds elapsed : 18.8917007
Creating file
FileCreated
Filesystem OK. Mounting…
Mounted. Now reading settings.dat file…
InitialPosX=200
InitialPosY=150
Stats
Bytes free : 8386560
Bytes orphaned : 1024
8MB file system, roughly half the time to format the drive, everything looks good to me 
Could you please confirm that the project I’ve sent is working on your latest revision of SC20260D dev board ?
I presume that my “Rev B” one may have issues, thus preventing this driver to work. I just want to know.
“Rev B” should work fine.
Your problem is Erase(uint address, …);
We use address, not sector, mean you have to pass 16 * 1024 * 1024 for length, not 4096.
That why it is so fast and doesn’t work.
I have no idea why your board work.
Hmmm… Formatting the FileSystem is using EraseChip() in the driver, which is translated to _qspi.Erase(0, sectorCount, TimeSpan.FromSeconds(1)); , to use your Erase() method.
SectorCount is Capacity/SectorSize, which gives 16 * 1024 * 1024 / 4096 = 4096, so I don’t see anything wrong in this code.
Or did I misunderstand the “count” parameter ? What is the meaning of this parameter ?
But this does not explain why it does work nicely on our board and not on the dev board 
_qspi.Erase(0, 16 * 1024 * 1024, TimeSpan.FromSeconds(100));
So it would mean that you can erase one byte only at a particular address ? Quite strange, to me, to be honest…
We have
Read(address, count…)
Write(address, count…)
So that is reason we have
Erase(address, count…)
Although Erase(sector, count…) is proper way in this cases.
And erase will erase entire of sector.
I thought read and write take the sector address not the byte address, no?
No, everything in byte address…
Frankly, I’m kind of lost, here
On one side, I would say that I have understood everything correctly since my driver is working flawlessly on our board, and on the other hand, you are talking about “different meanings” of parameters.
I think that a clarification on the parameters for this SQPI thing would be welcome, anyway.
Yes, I am wondering why your driver work.
Shouldn’t you wonder why it does not work on your board instead ?
No, just kidding 
Anyway, I will still investigate on my side, looking at the MCU datasheet to see how this memory is organised.
Yes, we did and found out why not work in our board.
The thing is, it shouldn’t work on your board too.
TFS: we don’t see unmount() in your TFS library?
You’re right.
The Mount() method is only a simple check to ensure that the file system is valid (formatted and without inconsistent infos) and sets some other informations.
Since we are using memory, with TFS, there is no “removable” parts like SD or USB stick, so unmounting the FS does not really make sense, to me.
Also, why would you unmount a memory filesystem ? The memory used by TFS is not meant to be shared, so once mounted it will stay mounted until a restart.
Here, “mounted” means more “ok for use”.
What was the issue ? Can it be fixed ?
We found issue in your project you sent us, relates to sector address and byte address. We are just wondering why that project worked on your board. With your project, both should not work.
I will create a dedicated thread, if you don’t mind.
Our drivers are now hosted here : GitHub - MBNSoftware/MBN-TinyCLR: MikroBus.Net drivers for TinyCLR 2.0