New Beta Release v1.20.3.b3

[robert-hh]

@DualMatic said in New Beta Release v1.20.3.b3:

PS. cannot reply on time because not sufficient reputation

I added a few.

[robert-hh]

@peterp Building in a up-to-now rarely used mint linux virtual machine worked. So if have to tell now what is interfering with the other build process.
Edit: copying back the pycom-esp-idf directory from the virtual machine to my primary machine worked too. So: Why did the esp-idf not install properly?
Edit2: Found the culprit: two additional lib directories in components/bt and components/esp32. But HOW did they get into the fresh cloned esp-idf? They are in the linker search directories, hmmm.

[robert-hh]

@peterp said in New Beta Release v1.20.3.b3:

Soft reset (Ctrl-D) causes core dumps

Commenting out 'uart_deinit_all();' on line 381 in mptask.c lets the code survive soft reset.
So maybe the delay is to short for the 'MPY:soft reboot' message to get sent.
Yup: Increasing the delay at line 379 to 50000 does the trick.

[peterp]

@robert-hh said in New Beta Release v1.20.3.b3:

two additional lib directories in components/bt and components/esp32. But HOW did they get into the fresh cloned esp-idf? They are in the linker search directories, hmmm.

Maybe some git submodule stuff? I recall some trouble when doing a git checkout that is "too far". E.g., git clone idf3.3.1 and then git checkout idf4.1 would lead to some messed up git submodules and it was just easier to make a fresh git clone from a branch that is just a few commits away from the IDF_HASH without any major changes to submodules and then you can git checkout IDF_HASH and have all the submodules correct.

Did those two directories not show up with git status? I'm sure there is a " correct " way with git to do this checkout in any existing clone, but I couldn't figure it out and just settled on a new clone from a "close" branch as shown above.

[peterp]

@robert-hh said in New Beta Release v1.20.3.b3:

@peterp said in New Beta Release v1.20.3.b3:

Soft reset (Ctrl-D) causes core dumps

Commenting out 'uart_deinit_all();' on line 381 in mptask.c lets the code survive soft reset.
So maybe the delay is to short for the 'MPY:soft reboot' message to get sent.
Yup: Increasing the delay at line 379 to 50000 does the trick.

Awesome @robert-hh I'll check that today!

[robert-hh]

@peterp said in New Beta Release v1.20.3.b3:

Maybe some git submodule stuff?

There are sometimes warnings when changing the branch, that directories cannot be removed because they are empty. In combination with the unneeded lib includes for -L$(ESP_IDF_COMP_PATH)/esp32/lib and -L$(ESP_IDF_COMP_PATH)/bt/libin Makefile line 182ff that could have cause the trouble for my old repository. But I do not understand why that happened too with the new cloned versions of esp-idf. Maybe some caching of paths.

[DualMatic]

I've tested new Beta Release (again thanks for the update)

Regarding ULP question, sadly is not included here but check out my post ULP Testing (pycom firmware with ULP support) as I've managed to "copy" micropython ULP part and integrated more or less on pycom firmware.

Regarding LoRa DeviceTimeReq, DeviceTimeAns not tested, but checking the code I think is not supported yet.

Side note, the Beta release requires to flash entire memory: differential update doesn't work and it complains with wrong size.

Regards

[jand]

@peterp
You now implemented LoRaWAN 1.0.3 (Class A& C). Does that mean that the MAC command “DeviceTimeRequest” can now be used to synchronize the real time clock of an end device? (see https://lora-alliance.org/resource_hub/lorawan-specification-v1-0-3/) If yes, how? Or where can I find that information?

[Sjur Wroldsen]

Hi @peterp,
Any updates on this release?
I see that there hasn't been that much activity lately, and I am eager to include uasyncio in my project : )

[Jean Ferreira]

@peterp can you please provide an update on this? I need updated IDF and MP to stay with this hardware platform but feedback and progress has been slim on the ground the last few months.

There have been no release candidates or beta improvements.

[peterp]

@Jean-Ferreira All I can tell you is that new MP and IDF versions are being worked on, but I can't give you an ETA

[Jean Ferreira]

@peterp is this beta worth testing or has the code base moved on too far? I need to integrate Ulab but the available 1.20.2 with ulab has LTE issues

[peterp]

@Jean-Ferreira said in New Beta Release v1.20.3.b3:

@peterp is this beta worth testing or has the code base moved on too far?

Yes. At this moment, you might test three different options. It could be that either one has their own pros/cons:

• stable FW based in IDF 3.3.1 - 1.20.2.rX for the latest X (right now 1.20.2.r4)
• beta FW based on IDF 4.1 - 1.20.3.b3
• alpha FW based on IDF 4.2.1 - 1.20.3.b4

I need to integrate Ulab but the available 1.20.2 with ulab has LTE issues

I haven't looked into this at all, but I find it surprising that there is a relation between ulab and lte.

[goldfishalpha]

Hello all!

This release doesn't appear to be changing the LoRaWAN mac version to 1.0.3, on a LoPy4. Update performed with Pycom firmware updater tool (not self built).

>>> import os
>>> os.uname()
(sysname='LoPy4', nodename='LoPy4', release='1.20.3.b3', version='v1.11-92f2b22e on 2021-04-19', machine='LoPy4 with ESP32', lorawan='1.0.2', sigfox='1.0.1', pybytes='1.6.1', pygate='1.0.1')
>>>

Could it be that the name was not updated, though the firmware still tries to support 1.0.3?

If this feature requires me building a more recent beta version, would consider it. Could really do with this for testing.

Thanks for any pointers.