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. 
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. 
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.
@stevespark, I would have to look at your code to see where the RAM is being used before I can make suggestions. There is a possibility that there is an SPI overrun but I suspect your problem is RAM.
Has anyone else experienced issues with active pages being incorrect on restart? Flashee works great as long as I don’t restart, and once I do, there is a decent chance initializing the flash space incorrectly picks the active pages, so I’m either pointed to valid but old data (previous write that is still fully intact) or corrupted data (erased or partially erased).
1 Like
I think the 8 quick flashes are the SOS pattern. The single remaining flash is the relevant code: Hard Fault. You need to post your code to get help on that since it could have lots of potential causes.
1 Like
Thanks for the offer but I have since managed to strip a bit more code out and it now works and communicates over TCP IP. The binary file downloaded from Cloud is 86.9KB (88956) together with data and bss is a total of about 102000 bytes. If I increase the code by a couple of hundred bytes the code still loads and breathes cyan with no RED FLASHING but TCP IP doesn’t work for local comms.If I increase the code size further then it briefly flashes cyan before RED FLASHING at each auto reboot.
I believe I have reached the limit for code size at about 87KB binary and 102000 bytes overall including data and bss byte requirements. When I try local commands through TCP IP there is a buffer overhead and that must be causing the comms issue before extra code causes the RED FLASHING.
Hi everyone, great to see the library is being used, although sorry to hear some are having problems. I’m on vacation until the end of the month with only sporadic internet access, but I will investigate these issues as soon as I’m home again. Thanks for your patience!
2 Likes
Thanks! VERY glad to know you’ll be back. 
2 Likes