Firmware Release v1.20.1

[rcolistete]

@rcolistete said in Firmware Release v1.20.1:

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.

Repeating my request.

[benc]

Hi, the release notes mention that uasyncio is included in this release, but I can't find it when I run help('modules').
Any tips of how to import it?
Thanks

[robert-hh]

@benc You have to go to this lib https://github.com/micropython/micropython-lib and get: uasyncio/uasyncio/init.py and uasyncio.core/uasyncio/core.py. Copy it to the board, best under lib/uasyncio. Then you should have the files:

lib/uasyncio/init.py
lib/uasyncio/core.py

You may also copy the files upip.py and upip_utarfile.py from https://github.com/micropython/micropython/tree/master/tools. If you install these on your board (e.g. to lib), you can use that via REPL to install modules from https://micropython.org/pi or https://pypi.org/pypi with the commands:

import upip
upip.install("micropython-uasyncio", "lib")

The status of micropython-lib is somewhat unclear. Not all modules from that lib work with any micropython board. But it is always a good source of inspiration.

[crumble]

I found a workaround for my actual I2C problem.

When I2C Error on init the GPS pop up, this status will stay even on reboot. So intentioned machine.reset(), uploading new python scripts and the watchdog is no solution. So the machine gets into an endless reboot loop until the power supply is cut.

The solution is to catch the I2C error and send the pytrack to deepsleep with gps=True. This resets the GPS, so that the ESP can talk again to it.

try:
  self.i2c.writeto(GPS_I2CADDR, self._mtkSentence)
  utime.sleep_ms(wait_ms)
except Exception as e:
  sys.print_exception(e)
  print("cut off GPS")
  utime.sleep_ms(2000)
  pytrack.setup_sleep(1)
  pytrack.go_to_sleep(True)

So 1.20.1.r1 seems to fix my problems at the moment. Would be nice, if this damn GPS will will be able again to find sattelites and print is able to flush.

[andreas]

@t0000899 said in Firmware Release v1.20.1:

Wlan connection has turned to really unreliable in 1.20 version.

We can confirm this after upgrading to 1.20.1 on FiPy and LoPy4 devices, with or without VARIANT=PYBYTES. We are also spuriously getting these core panics, see also https://community.hiveeyes.org/search?q=bad00bad bad00bad bad00bad.

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 0x4020f958: bad00bad bad00bad bad00bad

Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x40200754: bad00bad bad00bad bad00bad

[dabal221]

@serafimsaudade How do you solve this "OSError: Scan operation Failed!"?

[serafimsaudade]

@dabal221
I put a time.sleep of 3sec before wlan.scan(). And the error don't happen.

# Change the mode to both AP and station so we can connect to the network
self.wlan.init(mode=WLAN.STA_AP, ssid=system.uniqueGwId, auth=(WLAN.WPA2, self.system.apKey))
# Use internal antena
#self.wlan.antenna(WLAN.INT_ANT)
# Use External antena
self.wlan.antenna(WLAN.EXT_ANT)
try:
    time.sleep(3)
    self.nets = self.wlan.scan()
except Exception as exception:
    print("error", 'startWLAN scan: {0}'.format(exception))

[dabal221]

@serafimsaudade Unfortunately, it does not change anything. :(

[andreas]

@serafimsaudade said in Firmware Release v1.20.1:

I'm trying to connect gpy to wireless, but when I do wlan.scan() get this error:
wlan = WLAN(mode=WLAN.STA_AP,ssid="teste", auth=(WLAN.WPA2, 'pass'))
nets = wlan.scan()
OSError: Scan operation Failed!

This work on others fw version.

@dabal221 said in Firmware Release v1.20.1:

@serafimsaudade How do you solve this "OSError: Scan operation Failed!"?

For us, this flow works

import network

station = network.WLAN()
station.antenna(network.WLAN.EXT_ANT)
station.mode(network.WLAN.STA)
station.init()

then, later, either

station.scan()

or

station.connect(ssid, (auth_mode, password), timeout=int(timeout * 1000))

[dabal221]

@andreas Where can I find Firmware Release v1.20.1? Because when I update Firmware using Pycom Firmware Update I have got 1.20.0.rc13 not 1.20.1

[andreas]

@dabal221 said in Firmware Release v1.20.1:

Because when I update Firmware using Pycom Firmware Update I have got 1.20.0.rc13 not 1.20.1

Maybe the program will offer the newer releases after upgrading the Pycom Firmware Updater itself.

[dabal221]

@andreas said in Firmware Release v1.20.1:

@dabal221 said in Firmware Release v1.20.1:

Because when I update Firmware using Pycom Firmware Update I have got 1.20.0.rc13 not 1.20.1

Maybe the program will offer the newer releases after upgrading the Pycom Firmware Updater itself.

@andreas I have got 1.16.1, it is said that it is the latest stable version.

[crumble]

@dabal221

The new firmware is only visible, if you select pybytes, If yiou are asked about your bybytes ID, you can simply skip the question.

[dabal221]

@crumble said in Firmware Release v1.20.1:

@dabal221

The new firmware is only visible, if you select pybytes, If yiou are asked about your bybytes ID, you can simply skip the question.

What is the between pybytes and pybytes/legacy?

[andreas]

Dear @t0000899 and all others here,

@t0000899 said in Firmware Release v1.20.1:

Sometimes during FTP transfer there is an unhandled exception and flash memory is formatted.

Memory dump at 0x4020234c: bad00bad bad00bad bad00bad
Guru Meditation Error: Core  0 panic'ed (IllegalInstruction). Exception was unhandled.

@andreas said in Firmware Release v1.20.1:

We can confirm this after upgrading to 1.20.1 on FiPy and LoPy4 devices, with or without VARIANT=PYBYTES. We are also spuriously getting these core panics, see also https://community.hiveeyes.org/search?q=bad00bad bad00bad bad00bad.

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 0x4020f958: bad00bad bad00bad bad00bad

We have been working on mitigating these issues, so if you feel lucky, you might want to try one of our custom builds published to [1]. More background about this is available through [2].

If we are lucky together, this will improve the stability significantly. If you will be still receiving the core dumps, I will be happy if you would share its content with us. Please just don't paste it into the comment itself but put it into a file which you will be able to upload by dragging it into the text area.

Please be aware that when upgrading from a lower firmware version to the current 1.20.1.r1 development release these builds are based upon, you will have to erase your device completely before flashing in order to keep things straight as outlined within this topic already. Hint: Use a command like pycom-fwtool-cli --port /dev/ttyUSB0 erase_all, see also [3].

Please also be aware that this procedure will also erase the LoRa MAC stored on the device. @robert-hh thankfully outlined the procedure to restore it appropriately:

• If you still know the value the LoraMac had before, then you can follow the procedure explained at https://forum.pycom.io/topic/1272/lora-mac-ffffffffffffffff/21.
• If you do not know it, you will have to use the Pycom updater to restore it:
  • First, use the Pycom updater (GUI version) to install a recent image (like pybytes 1.20.1) from the Internet. You do not have to use it, the installation process itself already restores both the LoRa MAC and the Sigfox ID.
  • Then, use the Pycom updater to flash the custom image. Do not erase the flash in between.

As it turned out to gain more robustness for others already [4,5], we will be happy to learn if this happens to you as well.

Have fun!

With kind regards,
Andreas.

P.S.: For all people who want to go with Pybytes, we just published builds using VARIANT=PYBYTES at [6]. When going that way, you should probably save the pybytes_config.json before invoking the erase_all procedure and restore it to the device afterwards.

P.P.S.: All these builds use the LittleFS filesystem to prevent filesystem corruption which works for us very well.

[1a] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/LoPy4-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz
[1b] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/FiPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz
[2] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480
[3] https://community.hiveeyes.org/t/installing-the-recent-pycom-firmware-1-20-1-r1-requires-erasing-the-flash-memory-completely/2688
[4] https://community.hiveeyes.org/t/testing-the-custom-dragonfly-builds-on-pycom-devices/2746
[5] https://github.com/pycom/pycom-micropython-sigfox/issues/361#issuecomment-553399627
[6] https://packages.hiveeyes.org/hiveeyes/foss/pycom/pybytes/

[bilou7]

@iwahdan
Hello,
I am using Fipy and Lopy4 device which are getting data from a Ruuvitag by BLE connection. Since I have updated the firmware 1.20.1, pycom devices doesn't get any value from the ruuvi. Do you know if there is an issue with BLE connection with the new firmware ?

[serafimsaudade]

I'm trying to compile the pycom-micropython to use only one core.
I compile the idf libs, I make menuconfig and select "component config->FreeRTOS-> Run FreeRTOS only on first core". the compilation runs ok.
I move the libs to the pycom-micropython and compile the firmware, and program the wipy with no problems.
After the programming completes, the pycom enter into a loop when loading the bootloader and don't go to the python shell.

D (695) bootloader_flash: mmu set paddr=001e0000 count=1 size=20 src_addr=1ebab0 src_addr_aligned=1e0000
D (704) bootloader_flash: mmu set paddr=001e0000 count=1 size=20 src_addr=1ebab0 src_addr_aligned=1e0000
pycom-esp-idf/components/freertos/tasks.c:685 (xTaskCreateStaticPinnedToCore)- assert failed!
abort() was called at PC 0x4009097b on core 0

Backtrace: 0x40092c0f:0x3ffbab00 0x40092e15:0x3ffbab20 0x4009097b:0x3ffbab40 0x400de0b5:0x3ffbab80 0x400d2411:0x3ffbabb0

If I disable Run FreeRTOS only on first core. The pycom boots.

D (706) bootloader_flash: mmu set paddr=001e0000 count=1 size=20 src_addr=1ed800 src_addr_aligned=1e0000
Pycom MicroPython 1.20.1.r1 [4c809f4e-dirty] on 2019-11-21; LoPy4 with ESP32
Type "help()" for more information.
>>>

[regiskiwi]

@andreas I have been having the "Cache disabled but cached memory region accessed" exception in my custom (LOPY) build but it is hard to reproduce. When this happens in 1.20.r1 the CPU loops in the panic handler and hangs up there and only a POWEROFF reset will reboot the device ( WTG does not work). I made some minor changes in panic.c and got it to reboot if the exception happens. (the loop is caused by a call to rtc_wdt_set_time()).

That's all good but I need to find what could be causing this exception and I wonder if you can help me there:
In LoRaMAC.c there are radio 5 handlers defined but only one of them (OnRadioTxDone) is using the IRAM_ATTR attribute. It seems that all 5 of those handlers are called within an interrupt context so I think that they should be located in IRAM too. Any reason why they are not?

The handlers are:
RadioEvents.TxDone = OnRadioTxDone;
RadioEvents.RxDone = OnRadioRxDone;
RadioEvents.RxError = OnRadioRxError;
RadioEvents.TxTimeout = OnRadioTxTimeout;
RadioEvents.RxTimeout = OnRadioRxTimeout;

Thanks a lot.
Regis

[andreas]

Dear @regiskiwi,

@regiskiwi said in Firmware Release v1.20.1:

I have been having the "Cache disabled but cached memory region accessed" exception in my custom (LOPY) build but it is hard to reproduce.

I hear you. We experienced the same and went through all the jazz outlined within [1] to produce some more stable builds. However, I am sorry that we haven't been able to upstream the changes appropriately. As we recognized folks of Pycom have been pretty busy on their World Tour, I will try again to get through to @Xykon next week.

If you can get by using unmodified builds in any way, you are welcome to try our Dragonfly builds in the meanwhile [2].

As I am not using LoRa yet, I can't tell about any possible issues with the OnRadio* event handlers regarding IRAM.

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480
[2] https://community.hiveeyes.org/t/testing-the-custom-dragonfly-builds-on-pycom-devices/2746

[robert-hh]

@regiskiwi It is quite a while ago since I dug my way through the Lora stack. I had seen this IRAM/Not IRAM setting. But at that time it seemed plausible for me due to timing constraints. After TxDone, the device has to meet a very narrow time window for possible downlink messages. With caching needed that window may have been hard to hit. For the other events, timing is less critical. So I wonder more why caching is disabled. Did you do that intentionally in your code? Without caching, the firmware is hardly usable.
Did you try to add the IRAM attribute to the other handlers?

P.S.: I made also the experience that the internal WDT is not effective.