We are using LiIon cell connected to power the unit.
If MangohRED is disconnected form its accu and connected back everything looks good. But if we use device with low battery and finally let it fully discharged (usually about 3.4V) the MangohRed is rolled back from 18.01 to 16.10 In my case after power re-connection. This rollback does not happens every-time but quite often. Is there a way to prohibit rollbacks entirely? Empty battery is a real world 
Thanks
Mirek
After you install your app enter
Update —mark-good
This will prevent rollback
Hi, I am doing by Dev Studio
Is it enough?
Mirek
I haven’t tried it on dev studio but give it a try and let us know
This is fishy. Even if the system was in probatiin, I don’t think it should rollback from one reset due to power failure.
I can confirm rollback from 18.03 to 18.01 after slowly discharged battery also at WP7702 module. It seems not to be so often as WP7502 but it is here again 
.
Is there some way to prohibit rollbacks?
Hello
I think you have a limited time mark system good after install new update. I think it’s 30 minuts.
When I install a new system I use a manual command to mark the system good : update -g
Just after the update.
Francis
I have a similar problem and I think I can help define it. This is a serious problem for us as we cannot graduate our client to start build production units until we solve this.
We use a Li-Ion battery, and we install 18.03 using fwupdate, then use the update function to install 18.08 with our custom app over that. We use the # update -g command, followed by the # legato status command to verify that the build has been marked good. We can cycle power on the unit and no rollback occurs.
The problem comes when we let the battery drain to a point that the mangOH red stops. When we plug a power source into CF3 USB connector, and the mangOH comes back to life, it has rolled back to 18.03. I have learned from unrelated experience that if I cycle power several times in just a few minutes, the system will roll back to what was installed using fwupdate (18.03) regardless of probation status, and that is what happens with the battery drain situation.
My suspicion is that the BQ24296 is not providing a positive off and on to system power, but may fluctuate and result in several on/off cycles in rapid succession as the battery drains down. I am hoping to hear from experts that there is a way to program the BQ to have some hysteresis so that the system power is given a clean off, then on only once it is plugged in to a power source. I have not seen such a feature in the BQ24296 data sheet, but I hope someone has a solution. Thanks to all.
I should also mention that we are using the WP7601, and hope to move to the WP7702 soon. If the solution depends on the module version please include that in the answer. This is a problem in February 2019.
Do you see the rollback if wireless mode is disabled on the unit?
another and safe solution
-> you will have “legato.cwe” who include legato framework and you’re apps.
you can flash it to your target with “update legato.cwe 192.168.1.2”
CWE file will be stored in RO partition (not in RW).
You can deploy it by Airvantage by create an bundle.
Francis
@Francis.duhaut
Thanks for that reply. It appears to be just what I need. I’m having trouble getting through the process though. The systoimg command works, but the update command fails, and the log complains that the update file does not begin with either { or [
I will capture command prompt text and log output in case that his helpful. Trying to upload that in a file:
systoimg results (5.6 KB)
Any help is greatly appreciated.
Jim
@asyal
Thanks for responding. I’m not clear what your question means. Can you give me an example of enabling and disabling wireless mode, so I can try it both ways and report back? Thanks,
Jim
@Francis.duhaut
Success in getting that .cwe file installed.
I only needed to use $ fwupdate download legato.cwe [TARGET_IP]
Now just to wait until the battery drains tonight and see what happens…
Thank you again.
Jim
you can use AT command or use cm radio off.
Is the reset being caused by the low battery coupled with unit trying to connect to the network?
If the battery is low, maybe you can go to a low power mode till you recharge your battery.
Ok yes fwupdate download ipaddr is the good way to flash a cwe file.
Normally this will solve the issue.
Regards
Francis
@jdots83 Francis is right in that regard. My suggestion was only for troubleshooting not as a fix
@asyal
@Francis.duhaut
The fwupdate using the .cwe file does solve the roll-back issue.
That’s a positive step, and thanks for that suggestion.
Which enables me to see a new problem, that once the battery drops to a low enough charge, the firmware does not succeed in re-connecting once the device is plugged in.
By comparison, simply disconnecting and re-connecting a fully charged battery doesn’t present this problem, so I interpret that a brown-out or similar situation is part of the story.
When it gets into that state, and I then plug in to CF3 USB to recharge, our app is shown as running (still), but connections to A/V have stopped. This code is capable of re-connecting after a timer or shake wake from ULPM, so I have confidence that the code is capable of re-connecting, except in this situation where the battery was allowed to drop too low.
If, at that point, I issue these commands:
a new connection is made and data begins to be sent once again.
I still suspect that the BQ24296 is not cutting off system power cleanly which makes me want to find a register to program that will act differently.
Thanks asyal for suggesting that I detect a battery state that is nearing the end of its charge, and put the device in ULPM to protect it. This might be part of the ultimate solution. Of course, there is always the case where the unit is not recharged for so long that even this trick doesn’t save us.
Along a similar vein, I have also considered perhaps when the battery begins to run low, having myApp start a separate app which only relies on the module/timer, and on that timer wakeup, stops and restarts the primary app, similar to what I did at the command line. This might get us out of the current “stuck after brownout”, and on to the next problem 
Any suggestions are welcome, and I will continue to report new findings.
Jim
Hello Jim
Thanks for your feedback.
You can separate your app in 2 branch:
One for cloud connection who manage the server Time out/ connection
Second is your apps who push data if the connection is ready.
Is what I use with Airvantage.
Hi Francis, how to include our apps into CWE?
Best regards
Mirek