@steve-williams , I did some power mesurements here on the same setup I mentioned in my previous post to give you a clear picture about the current consumption while the modem is trying to attach so as to help you identifying the problem , in first trial I intentionally powered off the CAT-M1 network in office and run a script on GPY trying to attach
0_1551268954885_Screenshot 2019-02-27 at 12.57.44.png
you can see that the modem current consumption increases after sending attach request and keep trying to attach periodically, you can see that the Avg.current consumption when trying to attach can reach 285mA (150mA more than normal).
The following image is when CAT-M1 network is back online and attaching is successful :
0_1551269393276_Screenshot 2019-02-27 at 13.09.22.png
Sorry Paul, I never saw your reply until today. Unfortunately our load is pretty complicated; we have one thread for each I2C bus we configure (1 or 2 depending on the system) and two threads doing socket communication (one for outgoing and one watching for incoming). We're keeping track of resets and will monitor the systems. If it doesn't improve with later firmware releases then I'll have to look at debugging the crash. Do you have instructions on how to go about that?
@robi90 I misunderstood your first post, assuming a hard crash. I just tried your example and agree, that this is not good and must be fixed, because the device locks up in an unresponsive state.
I tried that with version 1.20.0.rc4.
The situation is a little bit better with Ctrl-F, because then the device falls at least back to safe boot, from which it can be restarted with machine.reset(). But only from the USB port. Using telnet is only possible then, if you use the default settings for WiFi.
This is all a little bit tedious, so I avoid to do it.
I remember we had a discussion about this on GitHub around Christmas last year...
Ideally the Makefile should know which branch of pycom-esp-idf should be used and clone / checkout / submodule update as necessary. It could also run make -C ../mpy-cross all before building the firmware as it should only rebuild if necessary. However checking all this before every build would probably be very annoying if it increases the build time significantly especially if you just made a small change between builds. Maybe adding this as make prepare would be better... plus a small post git checkout script that creates a file .force_prepare that would tell make to run the prepare step first so you don't forget.
Of course you can always keep two separate firmware directories, one for the master / stable and one for the release-candidate branch. You can also have a shallow clone of the IDF in each directory (git clone --depth=1 --recursive -b [master | idf_v3.1] https://github.com/pycom/pycom-esp-idf.git esp-idf) and then use a relative IDF_PATH (export IDF_PATH=../esp-idf).
We also plan to change the way we use branches in this repository. Rather than master being the latest stable release, we will create a branch for each major release version. If we did this today, we would have branches called release/v1.18 for stable and release/v1.20 for the release candidate. The master branch would always have the latest code so we can publish hot fixes without creating a full new release for the software server and firmware updater.
@robert-hh Es läuft jetzt. Ds Update ging nicht weil ich das Board für den Fipy überbrückt habe das es im batterie Modus läuft. nach entfernen des kabels ging auch das Update. Jetzt kann es weiter gehen. Danke für deine Mithilfe.