Let's get (non)volatile

Firmware
63

Thanks, this the info I needed.

about your update, the file name is just an example.

regards,
Marcus

64

Hi @bko

Writing and reading to/from flash using the sFLASH_ APIā€™s is not working when the number of writes is more than once. The first write and read work, but when I rewrite to the same address and read again, I read wrong values (mostly zeros).

I have put delay(100) between the reads and writes, and I have erased the sector (in setup() ) and I am writing even number of bytes( 8).

Is there something I am missing? Is there another way?

65

Hi @Muez

The FLASH technology only allows writes to convert 1ā€™s to 0ā€™s, so if you have ever written a location with 0ā€™s in the value, you need to erase before you can write 0ā€™s again. There are lots of schemes to work with this limitation so you donā€™t have to erase so often.

Does that explain your results or is your problem different?

66

I see,

One solution I can think of for my case is not writing to the same memory location again.
I want to log some data, so I don't need to rewrite to the same address.

Good.

67

Hi @Muez. There this library https://community.spark.io/t/user-nvm-non-volatile-memory-support-with-the-serial-flash/2765 created by @mattande - maybe that will help you?

If you can hang on a few days, Iā€™m in the middle of coding a library to specifically support logging data to flash via circular buffers. And also an eeprom emulation layer so you just read and write as normal - meaning you can write to the same address twice without any issues.

1 Like
68

Hi,

I have made a simple file system for the spark, silly and simple. I have not setup a git account jet, so here are the links to the sfs.cpp and the sfs.h
cpp file: http://pastebin.com/WreFALxV

h file: http://pastebin.com/CNL6TQQG

ā€˜manualā€™ is at the beginning of the files.
example:

 //create a file:
    fs.create((char*) "index.htm");
    fs.append((char*) "hello world!\n");
    fs.append((char*) "a brave new world!");
    fs.close();
 //read a file:
  if (fs.open((char*) "index.htm")) {
       while (fs.read(buffer, 120) > 0) {
           Serial1.println(buffer);     //do something more suitable for your app      
       }
       fs.close();
 }
 //dir command: slightly more complicated.. you have to loop through the directory and collect each entry in a buffer.
  int index = 0;  //
    char buf[45];
    int rc = 0;
    Serial1.println("dir:");
    while (index < 17) {
        rc = fs.dir(buf, &index);
        if (rc != 0)
            break;
        Serial1.println (buf);
    }

enjoy!

1 Like
69

Hi @ marcus,

the links are both the same header file.

70

Sorry, it was late last nightā€¦

I changed the content.
the function erase_file is under development, as we speak, so be careful!

I hope you can work with it,

bye!

1 Like
71

Cool! Thanks for sharing! :slight_smile:

Thanks,
David

72

no prob, it does not beat DOS, but it works.

1 Like
73

Iā€™m on the hunt for freeing up RAM, and one of the entries near the top of the list is

00000200 b EepromAddressTab

This is part of the eeprom emulation layer. Given that it only emulates 100 bytes, I was surprised to see the ram usage was twice that!

What I donā€™t understand is why the app takes the hit for this memory even if they donā€™t use EEPROM. I thought the linker garbage collected unused functions and data?

1 Like
74

@zach - hereā€™s your worldā€™s smallest dropbox clone! :smiley:

2 Likes
75

been digging through posts concerning the use of the external EEPROMā€¦seems like youā€™ve been able to use it successfully without interference from the wifi module on the SPI bus that others were struggling with. Whats the secret? Iā€™d like to use the external eeprom to host files for an embedded webpage.

1 Like
76

I hadnā€™t solved that problem until recently. Iā€™ve posted a fix at https://github.com/m-mcgowan/core-common-lib/tree/spibus_arbiter - this ensures that the flash and the cc3000 donā€™t collide with their use of the internal spi bus. You donā€™t have to change your code - itā€™s part of the firmware (at least when you pull the changes in that repo - but keep in mind thatā€™s preproduction code and also includes local changes I had to make to makefiles to work on my Windows box.)

Itā€™s discussed in this thread - https://community.spark.io/t/bug-bounty-ota-flash-reliability-issue/

Thereā€™s another approach involving turning off interrupts, but thatā€™s a pretty blunt tool in comparison to precision of the device (a mutex lock) that I use.

77

interesting read. Kinda of surprising that the OTA flash works as well as it does without the arbiterā€¦youā€™d think that would represent a pathological use caseā€¦simultaneous access of external flash and wifi.

78

I know. I think there must be sufficient latency in the system not to exacerbate the problem. But clearly itā€™s become more of a pressing issue.

To be perfectly honest, Iā€™m surprised a shared bus was put in place without any access control from the outset, but of course we donā€™t know what other battles the team have fought to get this far.

1 Like