[Submission] Flashee-eeprom library: eeprom storage in external flash

Have you tried using Flashee? Have now found that “Flashdevice* flash = Devices::createAddressErase();” needs to be called within each function before writing or reading data rather than being called just once in setup();

Yes, I have tried it. :slight_smile:

You don’t want to do it within each function. You will quickly run out of RAM since you are allocating a new object each time.

Put

FlashDevice* flash;

in global scope - outside of any function - near the top of the file

Then initialize in setup()

void setup() {
    flash = Devices::createAddressErase();
}
1 Like

Thanks. I have now done that but the “Getting Started” documentation is a little ambiguous on this and I understood it to mean just enter “FlashDevice* flash = Devices::createAddressErase();” in setup();

P.S. I have compiled my app with this code and it is now an 88kB binary file instead of 84kB. When I flash it seems to go through the motions with the usual high speed flashing of the LED for writing and read verification but then I get the red flashing kiss of death. Could it be that the compiled code is too large?

You’re right, the current docs aren’t clear in this regard. I had rewritten the getting started section but didn’t push to the github repo. (D’oh!) But I just pushed the changes now, so hopefully it’s clearer, but let me know if not!

Thanks again. Still having trouble with the red flashing after flash of new code. I have stripped everything out to the very basics:-

// This #include statement was automatically added by the Spark IDE.
#include "flashee-eeprom/flashee-eeprom.h"
using namespace Flashee;

static const int MINUTE_MILLIS = 60 * 1000;       // 1 minute milliseconds count


FlashDevice* flash;

void setup() 
{

    flash = Devices::createAddressErase();

    delay(1000);
}



void loop() 
{
static int lastdata = millis();
static int x = 0;

  if (millis() - lastdata > MINUTE_MILLIS)  // every  minute
  {
    lastdata = millis();
    if(x < 59)
        x++;
    else
        x = 0;
    flash->writeString("Hello there!",x*13);
  } 
    delay(1000);    // Delay in loop of 1 second
}
1 Like

I’m afraid as far as I know, this is an issue with the online IDE - please see

1 Like

Ack, it strikes again! I’ll bump up this issue for our next sprint.

Thanks!
David

I have been using the Flashee library that has grown from 5 to 13 files since I started using it a couple of weeks ago. I have been data logging a number of parameters at hourly intervals and retrieving them through TCP IP on the local network. I am using the address level erase scheme with 128kB storage.
When I have increased the frequency of data logging to every 2 minutes I have noticed some corruption in the data blocks I retrieve with characters “ÿ” (152decimal 98Hex)inserted at random positions. I am reading the datablocks (60 chars) x 24 - days worth at a time.

I am also noticing data corruption. I send story binaries, over and over, then print out the results, and things will work for a period of time, but then suddenly starting it up, sections of bytes are corrupted, and it all falls down. :frowning: I’m not sure if there are any gotchas I don’t know about for reading / writing…I’m using one section of Address Level Erase (4 pages), and WearLevelErase for 1MB. Hrm…

I’m noticing some issues with data still being on flash after a restart for WearLevelErase. Also, have you tried making the test classes on a Mac? It doesn’t build for me (though I’ve been using the library itself).

I am not sure it is Flashee reads as yet but it could also be corruption when I am accessing data through TCP IP protocol. I will carry out a few more tests and when I am sure I will post results.

I am reading data over TCP, writing it to flash, immediately reading it back into a buffer and printing it out, and it is perfect. I reset the core, and after it sets up flash partitions, the data is unreliably there, usually partially there. :confused:

Here is my setup:
_metaFlash = Flashee::Devices::createAddressErase(0,
4 * Flashee::Devices::userFlash().pageSize());
_storyFlash = Flashee::Devices::createWearLevelErase(
4 * Flashee::Devices::userFlash().pageSize(),
259 * Flashee::Devices::userFlash().pageSize());

Actually,@stevespark, that isn’t right, with things not working was wondering if there was a one-off-issue hence the 259. We are compiling a list of questions to try and get a better understand what is going on.

In my createAddressErase section I’m finding occasions where writing specific parts of it cause some sort of erase (everything up to where I’m writing suddenly goes FFFFFF…). Will be back soon with specific questions, but hope we can figure out a stable way to use your library!

-Jerry

Hey @mdma.

Sigh…another day with another coder trying to get Flashee to working consistently…we can’t. We can write data to our AddressErase and WearLevelErase areas without issue, read the data back and print without issue, but after a Spark Core reset, some data reverts to earlier versions of the data, so possibly from the wrong page because of the wear leveling? My header I’m updating over time is 74 bytes. I update it (write then read to verify), update it, update it, read it back and it is correct. Reset, and SOME of those updates are reflected, but not all. I think there are some real bugs in the initialization of the flash areas, starting at the wrong pages as the most recent data. Spent about three working days trying to get it to work consistently. It will appear to work, then data it outdated or corrupted…

ANYTHING I can do to help you figure this out, let me know. (I was originally responding to the wrong person, got my wires crossed and thought they were the author!).

1 Like

I have been having occasional problems but now have a bigger problem as my code reaches a size of 102580 bytes - the basic loop with no extras takes about 75k. I thought we had 128kB of total user space including data and bss. I notice Flashee now takes about 3K when using" flash = Devices::createAddressErase();".
I have two Cores with identical code that have the same problem and don’t want to reflash the third that has code that works fine when logging at hourly intervals.

@stevespark, the Spark Core’s bootloader takes about 20K of flash so the remaining 108kB is left for user and firmware code.

Thanks for the info. I have now trimmed ny code down to 102004bytes (includes txt, data and bss) but it still flashes red. If I use an earlier version of my firmmware with fractionally less code it loads and runs. I am obviously hitting a wall and without stripping out cloud functionality I am at an impasse. I could develop two versions - one with reduced or zero cloud functionality and the other with cloud but less local command functions.

@stevespark, the txt is what goes in flash. Flashing red is caused by the panic firmware and the number of flashes indicates the error:

Can you count the number of red pulses you get and report back? A typical panic error is caused by too much RAM being used/allocated.

I get 8 very quick flashes followed by a separate red flash before each attempt to reboot. From the link you have shown it appears to be out of HEAP with an SPI overrun - could the SPI overrun be associated with accessing external flash memory?

I assume my code that is being cloud flashed has the latest Firmware 2.3 with RAM optimisations. I don’t think I can squeeze much more out of my code.