Is there a way to write to different parts of the User Parameter flash? I have a bunch of user parameters, and I want to be able to set them back to defaults if the User flash gets scrambled (power down in the middle of a flash write) or if the user gets carried away 'tweaking' and can't get back. Since the different units have different defaults, it gets messy to have the defaults in the firmware. I want to have one 'factory blob' that I can update once the project is tuned up at the factory, and it would never be written again, but could be read to set the user blob to the defaults from the factory blob.
If I use SaveUserParameters(pCopyFrom,len) to save changes to the flash, does that write the entire 8K block, or only 'len'? Or only, say 1K blocks up to and including 'len'?
Does SaveUserParameters() always write from the start of the user flash? It must, there is no way to tell it to start elsewhere.
Is there another way to write to the user parameter area?
Sam
Splitting the User Parameter region?
Re: Splitting the User Parameter region?
I don't have a direct answer but two documents of interest related to user flash storage would be
The paper on increasing flash storage I know you don't need more storage but you could use a separate flash area to achieve your goal
and
the manual on the extended flash file system
I don't know how at risk the flash is if a power down happens while waiting. As a software guy I have faith in the magic of electrons and capacitors and assume that all will be well. Which means I would just create a vector<optionSettings> and the 0 element would have the never changing default and the other elements would have the user specific ones. That would at least achieve your goal of allowing the lost tweaker to get back to normal.
I would be interested in hearing the answer to your question though. I would assume that only the specified length bytes are written but I can't say I know that for sure.
The paper on increasing flash storage I know you don't need more storage but you could use a separate flash area to achieve your goal
and
the manual on the extended flash file system
I don't know how at risk the flash is if a power down happens while waiting. As a software guy I have faith in the magic of electrons and capacitors and assume that all will be well. Which means I would just create a vector<optionSettings> and the 0 element would have the never changing default and the other elements would have the user specific ones. That would at least achieve your goal of allowing the lost tweaker to get back to normal.
I would be interested in hearing the answer to your question though. I would assume that only the specified length bytes are written but I can't say I know that for sure.
-
joepasquariello
- Posts: 85
- Joined: Mon Apr 28, 2008 7:32 am
Re: Splitting the User Parameter region?
I'm pretty sure SaveUserParameters() erases the entire user flash area, then writes the specified number of bytes. Flash is generally block-erasable and byte-writable. If the user flash area consists of more than one block, then it could conceivably be erased / written at that block size if NB was willing to support that in the API. Any time a user updates a parameter, I simply erase and rewrite all parameters. If what's in user flash is not valid on bootup, we simply revert to defaults, i.e. defaults are in program flash.
- check user flash on bootup
- if valid, load params from user flash
- else load defaults and write to user flash
For what it's worth, I've never seen an instance of the user flash being invalid.
Joe
- check user flash on bootup
- if valid, load params from user flash
- else load defaults and write to user flash
For what it's worth, I've never seen an instance of the user flash being invalid.
Joe
Re: Splitting the User Parameter region?
Thanks Tod and Joe,
I have been doing what Joe suggests, but my problem is, for example, every unit has a serial number in user flash, I don't want to have to have that default be in the code, it would require a different image for each device. And some of the other user parameters are specific to a unit as well.
I think I could use the info Tod pointed to to make a second user default area for my MOD5234-based products, my current effort is on MOD5213, where I can't afford the extra 8K out of application flash.
It does look like the user flash gets erased by sector for each write, although I found the manual's references to Write and Program to be confusing. On the MOD5234 I can have different sectors for User and Default.
I'm working on code to get the lost tweaker back to ground zero, but I think that at least for the MOD5213 I'm still susceptible to corrupted user flash.
I have seen user flash corruption happen, if you lose power while writing to flash it can all go away. After you have checked your user flash, put in a loop that just keeps updating your user flash. Run this and kill the power when it is in the loop, you can pretty reliably get corrupted flash. This is why having the user flash written to at power up is risky, since power up can be dirty.
Sam
I have been doing what Joe suggests, but my problem is, for example, every unit has a serial number in user flash, I don't want to have to have that default be in the code, it would require a different image for each device. And some of the other user parameters are specific to a unit as well.
I think I could use the info Tod pointed to to make a second user default area for my MOD5234-based products, my current effort is on MOD5213, where I can't afford the extra 8K out of application flash.
It does look like the user flash gets erased by sector for each write, although I found the manual's references to Write and Program to be confusing. On the MOD5234 I can have different sectors for User and Default.
I'm working on code to get the lost tweaker back to ground zero, but I think that at least for the MOD5213 I'm still susceptible to corrupted user flash.
I have seen user flash corruption happen, if you lose power while writing to flash it can all go away. After you have checked your user flash, put in a loop that just keeps updating your user flash. Run this and kill the power when it is in the loop, you can pretty reliably get corrupted flash. This is why having the user flash written to at power up is risky, since power up can be dirty.
Sam
Re: Splitting the User Parameter region?
<PhilosophicalMusing>
When you put the serial number in flash you are really assigning a serial number of the NB module not your hardware. If that is your intent then that's OK. If the user buys two of your product and can swap NetBurners they've changed the serial numbers of the units. If your modules can't easily be removed then that obviates my objections. In secure environments NB modules typically HAVE to be removed when a unit is sent back. In the case of a firmware upgrade we install a new NB module. I wouldn't want to have the serial number change in that case. I have wanted to do similar things, that is, store identifying information (not just the serial number but a full assembly list of serial numbers of the unit) as well as lots of default data (typically complex calibration data) that can be used to restore the instrument to a "factory" state. The approach taken was to add non-removable EEPROMs to the carrier board and store the information there.
</PhilosophicalMusing>
When you put the serial number in flash you are really assigning a serial number of the NB module not your hardware. If that is your intent then that's OK. If the user buys two of your product and can swap NetBurners they've changed the serial numbers of the units. If your modules can't easily be removed then that obviates my objections. In secure environments NB modules typically HAVE to be removed when a unit is sent back. In the case of a firmware upgrade we install a new NB module. I wouldn't want to have the serial number change in that case. I have wanted to do similar things, that is, store identifying information (not just the serial number but a full assembly list of serial numbers of the unit) as well as lots of default data (typically complex calibration data) that can be used to restore the instrument to a "factory" state. The approach taken was to add non-removable EEPROMs to the carrier board and store the information there.
</PhilosophicalMusing>