Firmware Release v1.20.2.r3

[peterp]

Dear Pycom community!

We're happy to announce the release of version 1.20.2.r3

This version contains the following changes:

• LTE: fix core dump during machine.deepsleep() when lte is not enable on boot
• LTE: detect modem in ffh/recovery mode
• make: support User C modules - thanks for this contribution! PR 471
• pycom.rgbled() returns the current color value
• LoRa: cleaner error when trying to use modlora on Pygate
• WIFI: added constant for manual antenna selection

As usual, you can

• install this update via Pybytes
• or with the Firmware Updater
• find the source code and detailed commit log in the git branch Dev
• download the firmware packages (.tar.gz) from the docs
• and get the .elf files from the github release

[troy salt]

Did you fix the utime/RTC issues that were introduced in 1.20.2.r2?

[peterp]

@troy-salt said in Firmware Release v1.20.2.r3:

Did you fix the utime/RTC issues that were introduced in 1.20.2.r2?

Unfortunately, I am still not able to reproduce this https://github.com/pycom/pycom-micropython-sigfox/issues/478

[troy salt]

@peterp Have you tried to reproduce my example? https://forum.pycom.io/topic/6616/rtc-utime-issues-in-1-20-2-r2?_=1608751623362

[peterp]

@troy-salt I played with a few different versions. If there is an issue where rtc=RTC();rtc.ntp_sync() gives a wrong result that's a big problem, so I wanted to focus on that. Can you reproduce the problem when you use no parameter to set an initial date? Is the reproduction stable? Is it happening always, or sometimes?

[robert-hh]

@peterp I confirm that there is still a big mess around time setting.

• setting the date/time after reset with rtc.ntp_sync() results in rtc.now() showing the proper values, but time.gmtime() is far in the future by about 44 years and 4 months
• setting (after reboot) the date/time with rtc.init() e.g. to the actual values results in rtc.now() being not set, but starting at the initial value of 1.1.1970, 0:0:0 (the epoch value), but time.gmtime() returns the value being set and carries on.

I looked into the code, and it seemed to be related to the offset which is added to have the date/time being based on the 1.1.1970 epoch value, while the rtc uses 1.1.2000 for that. The code does some adding the offset here and subtracting it there, and seems to get lost over that. The cause was not obvious, and since @Gijs told it would be fixed I did not look further into it.

[troy salt]

@peterp When I wrote that post it was reproducible using my example. Please try it out just as I posted it and see. I don't have a device on me at the moment, but I can give it another shot in a few hours.

Best,
Troy