-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve SIM7600 power on and power cycle #952
base: master
Are you sure you want to change the base?
Conversation
Crash recovery only works on my test module when GPS was up & running at crash time. With GPS disabled, it still keeps looping in the power detection state cycle:
An explicit |
Thanks Michael, do you know why the uart frame error is not picked up in the |
UART frame errors are no indication you can rely on. They may or may not occur in case of an unresponsive modem, and they also may frequently occur during normal operation. The reason these occur so often sometimes still isn't clear, another ESP32 hardware bug cannot be ruled out. The modem task only logs & counts these, so we can potentially some day figure out why they occur and how to avoid them. If you'd like to dig deeper, read: |
Is there any reason the RX buffer is not flushed on a framing error? If the above log is an indication of an unresponsive modem I'm interested in how it passes the Is there any way to capture the RX following the |
Flushing the RX buffer does not help, even performing an UART reset does not help to stop the frame errors. RX lines are logged as See my previous logs on other boot sequences. Running your latest change, this is a cold boot with GPS disabled:
And a regular reboot from here, still GPS disabled:
Also an example of how random the UART frame errors are; not a single one on that reboot. |
Given the above works is it sensible to always power off the modem on a restart (or crash restart), before powering it on? |
Yes, and that is exactly what the general (driver auto detect) code does. You cannot assume a specific modem state on a reboot. Even if you introduce a new persistent variable in the boot object for the last modem state, that can as well get lost or corrupted by a crash. That's why the general code does a series of modem power switches until it gets a response. |
I've added a backstop PowerCycle if the modem gets stuck in the
|
Good news is, it does recover now. Bad news is, it needs much longer than with the default (autodetect) scheme:
This has been consistent over multiple tests. Regarding your proposed But you inspired me to try using And indeed, that seems to work on both modem models. It also seems to yield ~30 seconds shorter crash recovery times on both (down to 80-90 seconds), without hurting regular power-on times too bad (still 50-60 seconds), regardless of GPS status. That is, these results are based on introducing this change to the So I suggest testing this in more detail, and probably reverting the SIM7600 changes in favor for this, if you don't find any caveats. It could additionally be beneficial to make use of the Diff:
@leres Maybe you can give this a try as well? @markwj Any objections / further ideas? Regards, |
Thanks Michael, good to see the |
I've been using the As written above, recovery time still is worse with the SIM7600 modifications, so I'll keep this PR unmerged for now. |
@dexterbg @leres appreciate if you can test on your modules, it is working consistently on mine to recover from a module fault.