Onion Omega 2+ "jffs2: Newly-erased block contained word 0x0 at offset 0x01180000" warning
Product in use: Onion Omega 2+ (with custom hardware)
Firmware in use: 0.2.2 b202
To give some context to the situation itself, I will briefly explain the product we created. We created a Gateway based on Onion Omega 2+ where we use the following resources provided by it:
Serial 0 (GPIO 13/12) - It is being used for an external GSM module (115200 bps)
Serial 1 (GPIO 45/46) - It is being used to talk to an external CPU (500000 bps)
GPIO 03/11/15/16 - Are being used as output
GPIO 02/17 - Are being used as input
FW RST (GPIO 38) - It is being used to reset the Onion Omega 2 +
GND/3.3V - Power
The warning mentioned in the subject only happens when we are using Modem-3G to output data to a platform (developed by us). Another additional information is that our solution saves every 5 minutes (minute 0, 5, 10, etc.) some data on flash. Through the "logread" I was able to discover that sometimes the error " kern.warn kernel: [ 854.947376] jffs2: Newly-erased block contained word 0x0 at offset 0x01180000" occurs on that saves on flash and after this warning if we restart the Gateway it will no longer start (Onion is damaged).
Can you help troubleshooting the problem? Someone already managed this problem? Also, how does it just happen with GPRS?
This situation is happening sometimes in all the Gateway with GPRS we have (>500).
Thank you in advance.
crispyoz last edited by
@francisco-vieira If you save to SD Card do you experience the same issue?
luz last edited by
Tough problem, with 500 devices in the field…
The first thing that comes to my mind would be flash wear. However, that would not explain why it only happens with the GPRS devices and not the others. Unless the GPRS devices write significantly more data or more frequently.
Have you calculated the amount of data written over time and set in relation with the number of erase cycles the flash chip is specified for? It‘s not a simple calculation, but checking the order of magnitudes between your use and the expected life of the chip should be possible.
The other possibility would be physical interference of the cellphone signal with the flash chip due to high signal strength, too close proximity of sending antenna and the Omega or insufficient shielding in some way. Very speculative, though.
Third idea: a power supply issue, in that the GSM modem might draw power spikes, which, when happening during flash writes, exceed the momentary power budget so the flash write fails.
If it’s one of the second two things, you could probably work around in software by making sure to do flash writes only when you are not sending/receiving cellular data.
@crispyoz no, I didn't tried with SD Card because I have more than 500 installations done and I'm trying to find a solution or something that mitigate the problem via software (remotely I have access to all Gateways).
crispyoz last edited by
@francisco-vieira The reason I asked about the sd card was to determine if as @luz suggested, this may be a wear issue. Similarly if this is a power issue I would expect the sd card to also experience issues.
Once you understand the root cause, you can determine a solution.
@luz It's true, it was being a tough problem since 3 months ago.
Relatively to your first suggestion, the GPRS or the Ethernet write the same amount of data with the same frequency. I will try to calculate that and get you back as soon as possible.
Relatively to your second and third suggestion, we already are investigating this possible hardware issues and trying to get a solution to that. As you can imagine, with more that 500 installations done right now, we pretend first to understand if a software solution is possible. If not, and if we find a hardware solution (against the interferences or changing the equipment power supplies) we will advance to change all the > 500 Gateways.
After we can prove there is related to the interferences I think your software work around suggestion can be a good solution for that.
Do you see another things we can do for protect the Onion from the interferences (by software)?
Thank you my friend.
@crispyoz ok, I will try to use the SD Card and not the internal flash for internal tests. The difficult for us has been that happens randomly and It's difficult to reproduce in laboratory (we have more than 30 Gateways on tests). Relatively to the power issue, we are already studying if the problem is there.
Thank you so much for your help my friend.