Recommendationsfor flash regions please.

doingnz commented 8 years ago

I would appreciate suggestions on ways to layout the internal flash memory of my MF 4.x device. We could use the feedback as notes for other people who need to make these choices.

Flash regions in single flash memory device.

In may case, the physical flash is a single AMD block flash with 8 blocks of 8K, followed by 127 blocks of 64K (total of 8MB).

Currently I define two regions

const BlockRange g_Meridian_Flash_BlockRange_Region1[] =
{
    { BlockRange::BLOCKTYPE_BOOTSTRAP  ,  0,  7 },   // TinyBooter
};

const BlockRange g_Meridian_Flash_BlockRange_Region2[] =
{
    { BlockRange::BLOCKTYPE_BOOTSTRAP,  0,   2 },   // TinyBooter
    { BlockRange::BLOCKTYPE_CODE,       3,  26 },   // TinyCLR runtime
    { BlockRange::BLOCKTYPE_DEPLOYMENT, 27,      122},   // Application Deployment
    { BlockRange::BLOCKTYPE_STORAGE_A, 123, 123},
    { BlockRange::BLOCKTYPE_STORAGE_B, 124, 124},
    { BlockRange::BLOCKTYPE_CONFIG,     125, 125}    // g_ConfigurationSector
};

I run into difficulty with the single large BLOCKTYPE_DEPLOYMENT of 6MB. It takes more than 10 seconds to erase, which causes MFDeploy to timeout and raise an error when I erase the deployment..

Options:

build a version of MFDeploy with a longer timeout
break the Deployment region into multiple block ranges.

For the second option, what are the suggested sizes for the regions?

Regions can in theory be any size all the way down to 1 region for each physical 64K block?
They are not required to be the same size.

If feels incorrect to use a 64K block for the configuration sector? Would an 8K block(s) be better use of the flash space?

Adding file system support

My build can use an SD card for removable file system storage. (i.e. build includes FAT file system libraries) What are the additional steps to use some of the above flash for a file system? Do I just add a BLOCKTYPE_FS with some blocks to the region definitions, and add a call to AddDevice()?

Multiple physical flash memory devices

In the more general case, there could obviously be multiple different physical FLASH devices. Any additional guidance above what you suggest for a single physical flash memory?

Thank you for your suggestions

Thank you for your thoughts and suggestions.

doingnz commented 8 years ago

I realised after the above post that I am missing the optimisation which checks if a block is erased, only calling the driver to physically erase the block if not erased. This is much faster and avoids my initial timeout problem.

if (!m_deploymentStorageDevice->IsBlockErased( accessAddress, NumOfBytes )) 
{ 
                         success = m_deploymentStorageDevice->EraseBlock( accessAddress ); 
}

The question remains though even with this optimisation implemented, should the example 6MB flash region be divided into smaller regions for other advantages? e.g. to enable optimised reuse of already deployed assemblies?

Currently there is no verification of the regions being erased. Is it overkill to add a check after the call to the driver to confirm the region was actually erased?

if (!m_deploymentStorageDevice->IsBlockErased( accessAddress, NumOfBytes )) 
{ 
    success = m_deploymentStorageDevice->EraseBlock( accessAddress ); 
    success &= m_deploymentStorageDevice->IsBlockErased(accessAddress, NumOfBytes);
}

Thoughts about merit or over kill of adding a Verify step after a write?

success = m_deploymentStorageDevice->Write(accessAddress, NumOfBytes, (BYTE *)bufPtr, FALSE);

if (deviceInfo->Attribute.SupportsXIP)
{
    int res = memcmp((BYTE*)bufPtr, (const void*)accessAddress, NumOfBytes);
    success &= (res == 0);
//  if (success)
//  {
//       CLR_Debug::Printf("Verified OK");
//  }
//  else
//  {
//      CLR_Debug::Printf("Verify Failed");
//  }
}

smaillet-ms commented 8 years ago

Are you using the Released v4.4 VS integration and SDK? There was a fix applied to the underlying mfdeploy engine that will adjust the timeout based on the number of blocks being erased so you shouldn't see a timeout for large flash parts anymore. If that's not happening with the official released version then please file a bug so we can investigate more on why.

If the block isn't properly erased, then when a subsequent write is performed the checksum will fail. If you aren't doing a write immediately following the erase or the write you do perform doesn't have a checksum to verify then you might want to check it. As with many things it's a tradeoff.

In my experience working with FLASH FileSystems on NOR flash from the early days of Windows CE (Now called Windows Embedded Compact) I'd say don't bother trying to put an FS onto NOR. It's not worth the effort and you quickly run out of free blocks to perform a safe update to add a new file, etc.. The block sizes are just too large to make that a workable story.

To the more general, I recommend using the smaller sized sectors for the configuration area as it doesn't normally get very large and dedicating a larger one wastes space. The others depend more on what your device is going to do. If it's a maker dev kit then the more space for deployment the better! if it's a retail product with no support for third party app deployment/development then you don't technically even need a deployment region at all.

NETMF / netmf-interpreter