@eric-waai said in New v1.20.0 Release candidate v1.20.0.rc7:
If clearly stated i have no problem with adding a manual delay.
there are plenty of case where this time can be used to initialize other stuf. if that already takes 750 ms. there are a 750 ms wasted.
There is another way to program this. Start each init in an own thread and wait until each one died.
Yes, it shall be optional, 'cause ensure order of execution will not be easy ans overhead maybe too slow. But there are at least two ways to deal with this problem.
If we have to implement the wait time, the min time shall be in the documentation and not in the forum ;)
@mfallavol said in New Stable Firmware Release v1.18.2:
I'm getting somewhat regular crashes with this firmware. The crash begins with:
assertion "netconn_alloc: undefined netconn_type" failed: file "/Users/iwahdan/e
sp/pycom-esp-idf/components/lwip/api/api_msg.c", line 696, function: netconn_alloc
abort() was called at PC 0x401450b7 on core 1
I've seen it a few times already today.
Hello @mfallavol, Thanks for the report. Any idea what the board happened to be doing at the time?
@protean Pymakr is indeed using the zlib.decompress() micropython function for this feature. Normal upload also still works of course, but this way is faster for large files. Let me give you some pointers on how to code it:
The zlib function on the micropython side is documented here. Pymakr is compressing the files before uploading (here using this python file), writing the compressed file to the board with os.write() like always, and then decompressing them right after that (here). It'll definitely make uploading bigger files faster. Just realise that for files under 4k, it's actually slower because the overhead of compressing/decompressing is bigger than the savings of compressing the file.
@paul-thornton what about certification for IN865 region ? we cant do projects with lopy devices until the certification is there.
FYI, we are already using the lopy devices with indian band, but commercial projects require certifications.
What happend to the development branch and version 1.19 (which is still in beta)?
Was it abandoned? As far as I can see they both branched from 1.18, but with similar changes, especially regarding the new directory structure.
Is everything that was new/fixed in 1.19 also in 1.20?
The issue is that socket.connect() and SSL handshake will not timeout also in case the socket timeout is set and hang the application forever.
More than 1 way to skin a cat! Renamed upgdiff_33080-to-39529.dup to upgdiff_33080-to-39529.py, uploaded it via the upload button in atom, used Filezilla to change the extension back to .dup in the gpy flash then upgraded the modem.
Your modem has been successfully updated.
Here is the current firmware version:
@rskoniec said in New Firmware release v1.18.1.r1:
@mfa2214 xPy module f/w and GPy/Fipy modem f/w are separate, so GPy/Fipy module f/w doesn't contain modem f/w.
Here http://stiny.webd.pl/PYCOM/ on my VPS you have collection of CATM1/NB1 *.dup files.
Many thanks @rskoniec for sharing the files :)
More simple procedure on Linux :
start from the Linux menu "Pycom Firmware tool", quote "include dev releases"
then just choice /dev/ttyACM0 in High transfert mode
the firmware is flashed in 1.18.1.r1
Wrote 1.19 MiB from sipy.bin in 1 minute and 13.88 seconds
@xykon said in New Firmware Updater version 1.15.1:
@bmarkus Win32:Evo-gen [Susp] is a broad classification used by the Avast Behavior Monitor feature for software that exhibits suspicious behavior categorized as potentially malicious. The Behavior Monitoring feature observes the behavior of processes as they run programs.
The firmware updater connects to the Internet. That is considered "suspicious" for some anti-virus applications.
Thanks for the details. However it is a bit strange,a s I'm frequently installing programs connecting to the net during installation and have never seen such message from my AVAST.
Anyhow, I will ad it as an exception.
We could change the default sort order but I'm not sure this would affect existing users. I admit it throws me off too if I'm on the forum but not logged into my account. I'll see if our system admin can do some internal tests.
Hi @mongkol, so you have this error every time you try to update? Or just once in a while? I would suspect the PC USB port to be the problem, you could:
change the USB-microUSB cable
use the PC direct USB port, not thru a USB hub;
remove other USB peripherals from PC
The firmware update packages are sent over DFU protocol, which runs over USB bulk transfer channel, it might happen that the CRC of a package was wrong (or delayed).