Data save to flash

TinyCLR OS
1

Currently, I am using the SD card to save nonvolatile data. (The system will ALWAYS be notified of loss of power, giving time to store nonvolatile data to SD card)

Is there a way to save data to flash ?

2

Is it file or just data array?

3

it is individual strings

4

Please clarify. Are you saving data to an SD card and you are concerned about power loss while saving data?

5

No. The device we interface to has about 30 sec of power after it is shutoff. Our device is power by the connected device. We are notified when power has been shutoff. So we have 30 sec for graceful shutdown. So writing to SD is assured.
Matt wants to put the data in flash. I want to avoid the constant access to flash, both read and write. The data we want to save, about 150 strings, is constantly being updated.

6

This?

http://docs.ghielectronics.com/software/tinyclr/tutorials/secure-storage.html

7

OTP description is confusing.

It says you can only write once, but later says if you write all 0xff you can then rewrite?

8

i read that as “if you were silly enough to use your single write to write 32 bytes of 0xFF, then we’ll still call that block unused and therefore writeable with real data”. What that implies is if you have one byte not 0xFF in your 32-byte block, that whole 32-byte block is used and can be read but not rewritten.

9

different interpretations means there is confusion? :grinning:

10

yes but no. It’s write-once, no matter what, but writing it with what it says is “empty” doesn’t count because it discards that write. (in fact, if the text just said if you attempted to write 32x 0xFF, that is discarded, that might make it unequivocal ?)

11

We should change… How about this?

The default value of an empty block is all 0xff. Writing all 0xff has no effect and the block continues to be considered as an empty block.

12

The default value of an empty block is all 0xff. Writing all 0xff has no effect and the block continues to be considered as an empty block.

That is better.

Might consider adding some text about usage, such as device serial number.

1 Like
13

Luckily, I’m not using OTP. The secure flash looks like it has the same kind of access as the unsecured 4Mb of ram. I think this will work great for us. The are some configuration parameters that we need to persist. They are infrequently accessed. This will work.

14

(The same interface to unsecured RAM that is not included in the heap)

15

I am testing the secure storage / programmable storage. I used the sample code in the Secure Storage tutorial. It worked fine.

After Debug.WriteLine(“The Configuration driver is good to go!!!”);

I inserted the following code:

        string ttt = "enabled";
        string status = "";

        byte[] working = new byte[32];

        byte[] str = Encoding.UTF8.GetBytes(ttt);
        Array.Copy(str, working, str.Length);
        Configuration.Write(working, 0, 0, 32);

        Array.Clear(working, 0, 32);
        Configuration.Read(working, 0, 0, 32);  // <-----------------------------
        status = Encoding.UTF8.GetString(working);

This is to test saving and reading configuration data. It hung on Configuration.Read. To recover, I had to boot into LDR mode, erase all, reload the firmware.

Note also that if I changed the offset on Configuration.Write, i got an exception.

16

Using 100 or 260 chipset?

17

20260, preview 6
Sorry, should have included that

18

Erase before write, it will work.

This configuration uses storage driver, just write, not check empty. And the flash only accept write once when empty.

We will check and raise exception in next release.

19

erase before write works. Thanks

1 Like
20

thanks. i didn’t know it, will try. much appreciated as i’m still learning