[WORKAROUND] Unable to create string as not enough memory (FlashEEPROM problem) #558
Replies: 15 comments
-
Posted at 2016-05-03 by Wilberforce Isn't this a recursive call that will call itself until all memory is consumed?
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-03 by ceremcem I guess no, since |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-03 by @allObjects As setTimeout() is not necessarily ending a context... and that's what I think is going here, just as @wilberforce says... it depends what arguments are passed with the sleep. If they keep holding on to a context in order to return at a later time, and the whole is nested - like parsing in a tree - it is easy to run out of memory. Next thing is cross-compiling/generating: even though a powerful technique, it has its price... how is your sleep function look like? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-03 by ceremcem Are you sure about that? Is it all because of this "recursive function"s memory consumption?
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-03 by Wilberforce Output a |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-03 by ceremcem I reconnected the ESP8266 in order to add
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-03 by DrAzzy Well there's the first problem - you're walking on a knife edge there... only 122 free... |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-03 by ceremcem Well, I removed my variables (class instances) one by one, and available memory is increased to 836 bytes. Absolutely these classes are needed, but clearly they consume a lot of memory. Would this be my solution? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-03 by ceremcem @drazzy After refactoring my classes (used
Edit...but this didn't entirely help solving the problem. I cycled the power supply many times. Most of the time it read from FlashEEPROM as expected (correctly), but at 10th time or so, here is the result:
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-04 by ceremcem Here is the output after 30 power cycles:
The EditProgram is not starting at all afterwards. Giving the following error:
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-04 by ceremcem It turns out that I had corrupted FlashEEPROM's Now I changed the app code to use RAM, and flush very very rarely to the FlashEEPROM. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-04 by @allObjects
Switch over to something that does not wear out THAT quickly... tha's why some IoT MC chip maker use non-volatile RAM so they can power off / down anytime without saving to (FLASH)EEPROM. See FRAM/MRAM - 256-Kbit (32 K × 8) Serial (SPI) F-RAM - Ferroelecric, non-volative RAM - SPI: something that behaves like EEPROM AND RAM at the same time. For your needs, a 32KB works just fine and runs with @drazzy's EEPROM lib... and with the same driver but without wait-after-write (and no page erase), it's even better... you can write and write and write... For 'production' runtime EEPROM may work... it got corrupted at development time because of the unusual high rate of retries... ;) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-04 by ceremcem That sounds great! I could never think about that I would face with such a problem... Maybe we can replace original flash chip or add another one to the board on our next release. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-04 by @allObjects There is a trade off... easy integrate-able FRAM/MRAMs are only both of smaller capacities and more expensive than (Flash)EEPROMs. With a huge (Flash)EEPROM compared to the space needed and the (Flash)EEPROM run on a wear leveling driver you do not run THAT quickly into issues. The MCs with FRAM/MRAM have only 16..128..256 KB of that type of memory and for the vast amount of read-only needs they still run (Flash)EEPROM. Having all your application state in transparent, non-volatile RAM makes a sleep and resume very simple and and even more so quick. Last but not least not having to save and restore state saves battery... |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-04 by DrAzzy Worth noting that cheap EEPROMs (though not big flash chips) are readily available in I2C interface too, not just SPI. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2016-05-03 by ceremcem
Hi,
I have a relatively big codebase right now and I'm not sure what causes this error:
I guess I'm having trouble while reading from
FlashEEPROM
with the following class:Here is the Javascript output of above code:
I'm trying to use this code as follows:
...the Javascript:
The error is:
I expect the
sim2()
function to increment flash memory area by 1 in every 50 ms and this is what happens most of the time. But sometimes, (in a random order of power cycles) itConfig.read()
throws an error and memory can not be read.Is there anything I might misunderstand about usage of
FlashEEPROM
?Beta Was this translation helpful? Give feedback.
All reactions