Have tried various 1.3.x 1.2.x versions. Even with flashing tinker, then the firmware, then tinker again, Boron always comes back up flashing 10-signal red SOS. Only way out of it is to do a “particle update”, but of course that just gets back to 1.5.0.
Really trying to get back to 1.2.1, and a bit at our wit’s end here. Any suggestions greatly appreciated.
How are you trying to downgrade?
Have tried many ways, but most common is something like:
particle flash --serial boron-tinker@1.2.1.bin
particle flash --usb boron-system-part1@1.2.1bib
particle flash --usb boron-tinker@1.2.1.bin
Can never do the second tinker as --serial because the device is already SOS10 blinking after the system flash. Have also tried some other 1.2 rc’s and some 1.3s. Maybe 1.4s first? Perhaps there is some downgrade path dependency?
If you use the VSCode plugin (Particle Workbench), the Flash Application & Device OS (local) command has worked pretty well for me in the past
Thanks for the suggestion. Downloaded and installed Workbench. Got a simple program configured for 1.2.1 and compiled. Flashed locally and got same darn SOS pattern. Assume a:
particle update
will again fix it, but reinstall 1.5.0. Will keep trying for a bit with other < 1.5.0 to see if we can find any rhyme or reason to this.
Thanks again though, suggestion much appreciated.
After few more hours of tinkering, it is possible to downgrade as far as 1.3.1 if you do each release in a row. But going from 1.3.1 to 1.3.0 gets to the SOS red light pattern as soon as it is done flashing (with tinker or an essentially empty setup() and loop() code.
@rickkas7 or @ScruffR may be able to give more information, but I believe there is a bootloader downgrade that may need to happen in here. I could be wrong though.
Thanks (again), much appreciated.
We did try flashing the bootloader as well, but it did not seem to make any difference. Come to think of it, we may not have tried it sequentially down from 1.3.1 --> 1.3.0. Might give that a go at some point, but we have essentially thrown in the towel and decided to rewrite some stuff that was very stable under 1.2.1 to work under 1.5.0 (since we seem to be stuck with it 
)
AFAICT there never was a 1.3.0 release version.
1.3.1 also required a SoftDevice update and after that the SoftDevice would be updated automatically.
So chances are that you’d need to downgrade the SoftDevice to align with pre 1.3.1 versions.
However, if you can you should really consider making it work with 1.5.0 as there are several fixes for potential memory leaks and code safety compared to previous versions.
Thanks, that sounds like a very likely candidate.
You’re correct, of course, that there does not seem to be a 1.3.0 release on the GitHub site, but based on some previous advice we were using WorkBench, and there is indeed a 1.3.0-rc.1 target there.
We’re most of the way through some 1.5 changes in any case. Only remaining issue is that getting the network operator name does not seem to work anymore via the:
Cellular.command(callbackOperator, operator_name, DEFAULT_TIMEOUT, “AT+UDOPN=9\r\n”))
approach. Since the name of the network operator does not seem to be possible even in principal on LTE cards (?), we may need to rethink some logic on our end. Not entirely clear that 1.2.1 would solve that anyway.
For completeness, we may try the SoftDevice downgrade just to see if we can resolve that that was indeed the issue. Will update here if we do.
The operator name is not available on any of the LTE M1 devices as the u-blox SARA-R410M-02B hardware does not support it.
The way it works in the console is that the MCC and MNC, which are available from Device OS firmware and in device diagnostics, are sent to the cloud. Those are mapped to the operator name cloud-side. The mapping is easily obtained by downloading the table from mcc-mnc.com occasionally, however the worldwide database is far too large to fit in device firmware.
Interesting, that’s very helpful. We could at least have a sparse on-board lookup for most likely candidates, and then a fallback.
Even better, does anyone know if there is some already exposed public API that returns the operator name given an MCC and MNC? We could expose a Particle.function() on the device for setting the operator name that gets fired after an “online” or “update” event. Of course we could just store the data and do the lookup ourselves on our own servers, but if some entity is already maintaining an interface? Or maybe there already is such a call available in the integration system at particle? Just thinking out loud …
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.