Firmware Release v1.20.1

robert-hh

@rskoniec Do you use the PyBytes variant? According to the code this variant always returns False (and it does not set this flag). See the code snippet from pycom_config.c:


bool config_set_wifi_on_boot (uint8_t wifi_on_boot) {
    if (pycom_config_block.wifi_config.wifi_on_boot != wifi_on_boot) {
        pycom_config_block.wifi_config.wifi_on_boot = wifi_on_boot;
#if (VARIANT != PYBYTES)
        return config_write();
#endif
    }
    return true;
}

bool config_get_wifi_on_boot (void) {
#if (VARIANT == PYBYTES)
    return false;
#endif
    return pycom_config_block.wifi_config.wifi_on_boot;
}

River

Hello @iwahdan, promissing update! Thanks to all people involved.

I will test new firmware flashing a module later today. I have two questions regarding this update:

It's now ULP co-processor supported? We have a product with custom hardware + lopy4 and we want to add capability to count pulses on two digital inputs while sleeping (measuring water consumption, etc..)
It's possible to change wifi mode to LR (Espressif's Long Range protocol) by code?

If still not supported (1 or 2) I don't know if may open an issue on github in order to pycom keep track of improvements, or maybe is better to leave written here.

Regards

cmisztur

Thank you.

Regarding 'legacy' vs 'pybytes' variants. Does the PyBytes variant auto connect to PyBytes platform and maintain connection? What is the difference between 'legacy' and 'pybytes'?

robert-hh

@cmisztur Sorry, I never looked at pybytes.

cmisztur

Breaking change for me from 1.20.0.rc13 to 1.20.1 is usage of machine.idle().
Below, line 7 is never reached.

import utime
import _thread

def t():
    print('thread start')
    utime.sleep_ms(4000)
    print('thread run')

_thread.stack_size(8192)
_thread.start_new_thread(t, ())

utime.sleep_ms(1000)

while 1:
    machine.idle()
    #utime.sleep_ms(50)

cmisztur

@robert-hh said in Firmware Release v1.20.1:

@cmisztur Sorry, I never looked at pybytes.

How are you flashing 1.20.1?

robert-hh

@cmisztur I build the image myself, and as part of that, i can call:

make BOARD=xxPy flash

There are also the pyupgrade tools, you can download from the pycom web site.

robert-hh

@cmisztur That finding with idle is strange. Comparing the Pycom variant with the Micropython.org shows no difference in the machine.idle() implementation. But the Micropython.org version works. That's how the function looks in both variants:

STATIC mp_obj_t machine_idle(void) {
    taskYIELD();
    return mp_const_none;
}

robert-hh

@cmisztur I compared the related functions in machine.idle() and utime.sleep_ms() for both v1.20.0.rc13 and v1.20.1. They are identical, and just call taskYIELD() (idle) resp. vTaskDelay() (sleep_ms). So the change must be cause by moving from esp_idf v3.1 to esp_if v3.2.

Clemens

I have some devices with firmware 1.20.0.rc13 before and now 1.20.1. Unfortunately the old software is not running with the new firmware and I got e.g.

File "main.py", line 11, in <module>
File "webserver.py", line 124, in <module>
File "/flash/lib/microDNSSrv.py", line 19, in Create
File "/flash/lib/microDNSSrv.py", line 161, in Start
OSError: Network card not available

or

File "/flash/lib/terkin/network/core.py", line 110, in start_services
File "/flash/lib/terkin/network/core.py", line 131, in start_httpserver
File "/flash/lib/terkin/api/http.py", line 70, in start
File "/flash/dist-packages/microWebSrv.py", line 219, in Start
OSError: Network card not available

and my former working OTA-Code is stopping also

  File "main.py", line 44, in <module>
  File "/flash/lib/OTA.py", line 176, in connect
NameError: name 'SSID' isn't defined

robert-hh

@Clemens I had a similar problem too on one Lopy4 device - Wifi was not available. Erasing the flash and reloading the firmware solved it.

Clemens

@robert-hh said in Firmware Release v1.20.1:

pycom.wifi_on_boot(True, True)

>>> pycom.wifi_on_boot()
False
>>> pycom.wifi_on_boot(True, True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: the requested operation failed

robert-hh

@Clemens That wifi_on_boot() issue is a different topic and has been fixed with today's build for the Dev branch. AFIK it is not yet in the 'official' version.
Edit: It looks like there is a lag in the Pycom update. The updater does not show V1.20.1, and the download page for firmware packages is also not updated.

rcolistete

Please update the links for all Pycom devices in :
https://docs.pycom.io/advance/downgrade/
to include the version 1.20.1 for manual firmware download.

Clemens

One software is after the repeated firmware update with the checked option erase filesystem now running. The second one outputs still the same error.

berni

After upgrading to 1.20.1, I started having crashes when setting up the frequencies for the Nano-Gateway code:

Guru Meditation Error: Core  1 panic'ed (Cache disabled but cached memory region accessed)
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x40201f50: bad00bad bad00bad bad00bad
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x40201f50: bad00bad bad00bad bad00bad
Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.

This happens somehow randomly, after a few cycles of deep sleep/transmission, but even the Watchdog timer becomes useless.

Then I downgraded to 1.20.rc13. Now, the code doesn't work and stops in this line:

>>> from network import LoRa
>>> lora = LoRa(mode=LoRa.LORAWAN)
>>> lora.nvram_erase()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: the requested operation failed
>>> lora.nvram_save()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: the requested operation failed

Is there any way to go back to 1.20.rc13 and have these function working again? I suspect there must be some low level changes on the LoRa radio.

iwahdan

Hello @berni , Thanks for reporting that issue, we will work on reproducing it, meanwhile regarding the exception you get when downgrading to rc13 , this should be due to the new formatting mechanism of NVS introduced in IDF_v3.2 (1.20.1) , so when you downgrade the FW to previous version of IDF, NVS might not be initialise successfully, to solve this issue you can erase the device and flash the Firmware again.

Thanks

robert-hh

@berni @iwahdan Setting the frequency and/or removing channels is a topic which anyhow does not seem to work. I have to look at it. Even when I set in the abp_node.py sample code the device to use a single frequency only, it transmits at the three default frequencies. That was different once.

oligauc

@berni Using a terminal / command prompt, please can you go to the pycom firmware updater folder (e.g "C:\Program Files (x86)\Pycom\Pycom Firmware Update" in windows) and type the following command:

pycom-fwtool-cli.exe -p "your com port" erase_all

After erasing please re-flash your device.

Please let us know how it goes, Thanks

oligauc

@robert-hh We carried out some tests with the abp node / RAK gateway in the EU region. If you add 3 channels with the same frequency and remove the others, it will send at 1 frequency.

If you do not add / remove channels manually, then the node uses frequency hopping.

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

Firmware Release v1.20.1

Pycom on Twitter