New firmware release 1.10.1.b1

[robert-hh]

@xykon I tried already a few variants:
a) Pycom image or homebrew image: not difference
b) starting from main.py or manually: no difference
c) starting from the file system or as frozen bytecode: no change
d) with or without manual ip setting: makes a difference

If with manual IP setting I add a delay of 2 seconds between the isconnected state and IP setting, it is more stable. So it could be something related to the state machine if the WiFi stack.

But I had that manual IP setting before with all versions including 1.10.0b1 w/o problems.

[Colateral]

This post is deleted!

[Emmanuel Goudot]

@xykon said in New firmware release 1.10.1.b1:

https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-73-ge28a011-5.2.0.tar.gz

I use this compiler on linux, and still have
~/esp/pycom-micropython-sigfox/esp32$ make BOARD=SIPY TARGET=boot
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
CC bootloader/bootloader.c
xtensa-esp32-elf-gcc: error: unrecognized command line option '-mfix-esp32-psram-cache-issue'
../py/mkrules.mk:47 : la recette pour la cible « build/SIPY/release/bootloader/bootloader.o » a échouée
make: *** [build/SIPY/release/bootloader/bootloader.o] Erreur 1

[Colateral]

@xykon Thank you. Done. I did also 'make BOARD=LOPY clean' then make BOARD=LOPY TARGET=boot
make BOARD=LOPY LORA_BAND=USE_BAND_868 TARGET=app

and I have same result on flashing.

            $ make BOARD=LOPY LORA_BAND=USE_BAND_868  ESPPORT=COM7 flash
            Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
            warning: CRLF will be replaced by LF in esp32/application.mk.
            The file will have its original line endings in your working directory.
            Entering flash mode
            Traceback (most recent call last):
              File "tools/pypic.py", line 185, in <module>
                sys.exit(main(sys.argv[1:]))
              File "tools/pypic.py", line 173, in main
                pic = Pypic(args.port)
              File "tools/pypic.py", line 77, in __init__
                self.serial = serial.Serial(port, baudrate=115200, bytesize=serial.FIVEBITS, timeout=0.25)
              File "D:/ProgramFiles/msys32/mingw32/lib/python2.7/site-packages/serial/serialwin32.py", line 31, in __init__
                super(Serial, self).__init__(*args, **kwargs)
              File "D:/ProgramFiles/msys32/mingw32/lib/python2.7/site-packages/serial/serialutil.py", line 240, in __init__
                self.open()
              File "D:/ProgramFiles/msys32/mingw32/lib/python2.7/site-packages/serial/serialwin32.py", line 78, in open
                self._reconfigure_port()
              File "D:/ProgramFiles/msys32/mingw32/lib/python2.7/site-packages/serial/serialwin32.py", line 222, in _reconfigure_port
                'Original message: {!r}'.format(ctypes.WinError()))
            serial.serialutil.SerialException: Cannot configure port, something went wrong. Original message: WindowsError(87, 'The parameter is incorrect.')
            make: *** [application.mk:398: flash] Error 1

[Colateral]

@xykon I commented this in application.mk

#PIC_TOOL = $(PYTHON) tools/pypic.py --port $(ESPPORT)
#ENTER_FLASHING_MODE = $(PIC_TOOL) --enter
#EXIT_FLASHING_MODE = $(PIC_TOOL) --exit

and flashing was working.

I don't know if everything goes fine with those lines commented. Seems that those lines are targeting flashing a pic microcontroller ... do we have this kind of microcontroller on our LopY and L01?

[tudro]

Hello, with this firmware i'm having a problem with the deepsleep lib:
Traceback (most recent call last):
File "/flash/lib/deepsleep.py", line 151, in get_wake_status
File "/flash/lib/deepsleep.py", line 79, in peek
IndexError: bytes index out of range

I downgraded the firmware to 1.9.2.b2 and the deepsleep started working fine again, so i assume it's something with the new firmware. Anybody had this problem?

Thank you

[Colateral]

@emmanuel-goudot I had the same problem. After I upgraded xtensa tool to last version everything is working. You need to download and replace xtensa folder with the new software. Be sure the software that you install is inline with your OS: linux / windows and 32/64bit

[Xykon]

@colateral The pypic.py tool puts the esp32 into firmware update mode when using a Pytrack or Pysense which is controlled by a PIC microcontroller. This way you no longer need a jumper wire to do firmware upgrades.

[Colateral]

@xykon Thanks. We are using LoPy with pycom shield. We have also our own board based on L01. Both cases raise errors on that pypic serial connection . Can you enhance application.mk by adding some conditions in case that the pic is not present.?

[Xykon]

@colateral On MacOS X (which we use internally) the script works fine with either the standard expansion board or the Pytrack / Pysense. This is an issue specifically with running the script on Windows. As I want to include this functionality with the firmware update tool, we'll obviously have to make the script compatible with Windows OS.

[robert-hh]

@xykon said in New firmware release 1.10.1.b1:

Any chance you can try without assigning a fixed IP?

calling ifconfig() before connect() also solves the problem. I looked into the code, and there seems to be a condition mix-up between the local state of the wlan_obj.disconnected variable and the connection status in the wifi_event_group variable. ifconfig(), when called, disconnects first, which causes a SYSTEM_EVENT_STA_DISCONNECTED event, which attempts to reconnect, while the dhcp client is shut down and the new ip values are set, and the timing relations are not obvious. This might lead to trouble.

[this.wiederkehr]

Espressif just pushed a new release 2.1.1 (https://github.com/espressif/esp-idf/releases) which is advertised to include bug fixes for two security vulnerabilites: KRACK and BlueBorne

Are the mentioned fixes already included in this current firmware release?

EDIT:
Found the answer regarding Krack myself:
http://espressif.com/en/media_overview/news/espressif-releases-patches-wifi-vulnerabilities-cert-vu228519
Fix is in master since this commit:
https://github.com/espressif/esp-idf/commit/904d6c8f2b01de52597b9e16dad19c78ade9e586

This commit is in pycom's esp-idf as well (https://github.com/pycom/pycom-esp-idf/commit/904d6c8f2b01de52597b9e16dad19c78ade9e586).

[bradnz]

@tudro Did you find a solution to this issue? Im experiencing the same issue

[tudro]

@bradnz Nope. I guess we have to wait for a new firmware.

[robert-hh]

@tudro There is a new firmware version out at 1.10.2.b1, but it does not mention deepsleep in the revision notes.

[bradnz]

@tudro Interestingly enough, after a lot of testing, I only ever get this error when I have connected to the device, with an expansion board and powering this ONLY through a Lipo battery. With the device connected via USB I dont get this error! I have upgraded to the latest firmware which hasnt fixed the issue so Im not sure where to go to from here.

[tudro]

@bradnz Thank you for the info. I was pretty busy lately and didn't have much time for the lopy. Maybe this week i get a chance to test some more. I tested 2 lopys on usb and they both had the same problem. Even if it's just on batter for you, it still means there is a problem. Maybe they will have time to investigate this sooner or later, otherwise i will just stick to the 1.9 version for now.

[devinv]

@tudro This is hapenning to me now with the last firmware. How did you solve this?

[robert-hh]

@devinv What is happening?