NetBurner Community Forum

I saw that the calls to FlashProgram and FlashErase were failing to compile and tracked down the Hal_StorageSave and Hal_StorageRead functions.

Hal_StorageSave on the MOD5441X seems to simply be a wrapper for FlashProgram and FlashErase which is great. Hal_StorageRead doesn't exist for the MOD5441X, and it's not exposed on the SOMRT1061 anyway. Is there a generic way of getting the pointer to the flash location which would work in both systems without resorting to #if defined(MOD5441X) .. #elif defined(SOMRT1061) .. #endif?

This goes all the way back to the MOD5272 which we started with, I have to write up to 256kB, this isn't written often, but regardless doesn't fit in any of UserParam spaces...

If you created a larger custom UserParam area on the MOD5441x, then yes, you will need to handle each platform separately. The SOMRT1061 uses SPI flash, so there is no concept of a memory mapped flash address. Now if you were using the default UserParam storage space, then you would access each the same way - they would be identical.

For the SOMRT1061 you have to use the standard method to access UserParams:
#include <system.h>
int SaveUserParameters(void *pCopyFrom, int len);
void *GetUserParameters(void);

To set the size to a larger amount, overload hal_platdefs.h in the platform include in your project.

#define PLAT_STORAGE_MAX_USERPARAMS_SIZE 0x4000

Hi Tom,

I understand -- on the old MOD5441X, I was already copying the memory mapped flash space to a location in RAM, so it's somewhat simple.
I'd just marked the end of the flash space as where I would store this extra data.
I was storing to an arbitrary place in flash which was significantly higher than my application size...

With the HalStorage_Save function, there's an offset which can be specified here. Is there anything stopping me from doing this:
HalStorage_Save(HalStore_App, pData, szData, flashSize - szData - 1)

And then to expose and call HalStorage_Read with similar attributes to read it back?

Is there anything stopping me from doing this:

Yes there is.

Ok, so architecture theory time. The new HalStorage methods are an abstraction layer between the OS/Application and some form of non-volatile storage. In the case of the SOMRT this is because it uses the EFFS Std Filesystem as a primary interface. While it is technically possible to set aside some portion of Flash for direct access (by configuring a second partition), by default, everything is a file in the filesystem.

The reason for the HalStore_AREAs, is to allow the OS to _emulate_ the dedicated storage spaces of older platforms in a way that is mostly transparent. In your case, I would recommend either use GetUserParameters/SaveUserParameters (and specifically GetUserParameters, rather than HalStore_Read(HalStore_UserParams....), as GetUserParams will emulated the 0xFFs of erased flash, etc.) or just directly use the filesystem itself. If you need a larger UserParameters space than the default 4kB, you can increase the size by changing the value in `hal_platdefs.h` header in the platform directory (or override the file in your project).

To do what you suggest will in fact wipe out the application image, as it is expected that when HalStorage_Save is called, you are providing the complete blob to store in that storage region, which, in the case of HalStore_App, is the complete new application image.

Thanks dciliske, perfectly clear. I appreciate the explanation.