New firmware release 1.10.1.b1

Xykon

@tudro Please make sure you have a wire connected between G23 and GND and reset the board before trying the erase. You should see a message "Waiting for download" on the serial terminal. Also make sure that all serial terminal programs & Pymakr plugins are disconnected when running esptool or the firmware update tool.

Colateral

building from fresh pulled git raises errors. There is a param that shall be specified?

$ make BOARD=LOPY TARGET=boot
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
mkdir -p build/LOPY_868/release/bootloader/
CC bootloader/bootloader.c
xtensa-esp32-elf-gcc.exe: error: unrecognized command line option '-mfix-esp32-psram-cache-issue'
make: *** [../py/mkrules.mk:47: build/LOPY_868/release/bootloader/bootloader.o] Error 1

Xykon

@colateral Please download the new xtensa compiler for your OS.

The "esp32" port requires an xtensa gcc compiler, which can be downloaded from the Espressif website:

for 64-bit Linux::

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

for 32-bit Linux::

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

for Mac OS:

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

Colateral

@xykon thanks. we are using msys2. This has to be installed in msys to work?

Xykon

@colateral Please use the following within msys2 to update the toolchain:

# Automatically download precompiled toolchain, unpack at /opt/xtensa-esp32-elf/
TOOLCHAIN_ZIP=xtensa-esp32-elf-win32-1.22.0-73-ge28a011-5.2.0.zip
echo "Downloading precompiled toolchain ${TOOLCHAIN_ZIP}..."
cd ~
curl -LO --retry 10 http://dl.espressif.com/dl/${TOOLCHAIN_ZIP}
cd /opt
rm -rf /opt/xtensa-esp32-elf  # for upgrades
unzip ~/${TOOLCHAIN_ZIP}
rm ~/${TOOLCHAIN_ZIP}

Colateral

@xykon said in New firmware release 1.10.1.b1:
For windows:
https://dl.espressif.com/dl/xtensa-esp32-elf-win32-1.22.0-73-ge28a011-5.2.0.zip

Colateral

@xykon Thanks. It was working. The mpy-cross was built and also the binary .. but there are issues on serial writing.
COM7 is ON and 'waiting for download'

but

            $ make V=1 BOARD=LOPY LORA_BAND=USE_BAND_868 flash ESPPORT=COM7
            python ../py/makeversionhdr.py build/LOPY_868/release/genhdr/mpversion.h
            Entering flash mode
            python tools/pypic.py --port COM7 --enter
            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

With pycom firmware update and updater.py (changed according with Daniel above guidelines) ... it is working.

            >>> import gc
            >>> uos.uname()
            (sysname='LoPy', nodename='LoPy', release='1.10.1.b1', version='v1.8.6-839-g536c958c on 2017-11-15', machine='LoPy with ESP32', lorawan='1.0.0')
            >>> 
            >>> 
            >>> 
            >>> import gc
            >>> gc.mem_free()
            3070064

tudro

@xykon Thank you for the quick answer and sorry for the late reply (2 small kids :) ). You were right, i didn't have G23 and GND connected. I was able to reset the flash and make the lopy work again. Thank you very much

Xykon

@colateral This seems to be due to a new tool we added that puts the ESP32 into firmware update mode if a Pytrack or Pysense is being used. It seems this tool doesn't work on Windows...

Please edit application.mk in the esp32 directory, search for flash: and comment the 4 lines as shown below:

flash: $(APP_BIN) $(BOOT_BIN)
#       $(ECHO) "Entering flash mode"
#       $(Q) $(ENTER_FLASHING_MODE)
        $(ECHO) "Flashing project"
        $(Q) $(ESPTOOLPY_WRITE_FLASH) $(ESPTOOL_ALL_FLASH_ARGS)
#       $(ECHO) "Exiting flash mode"
#       $(Q) $(EXIT_FLASHING_MODE)

This will prevent the tool from running until we can fix it.

robert-hh

@daniel I have a serious problem with the new release. Setup:
Plain vanilla pycom image on a LoPy, flash was erased. I have a little script that connects as a STA:

import network
import time
from uos import uname
# setup as a station
wlan = network.WLAN(mode=network.WLAN.STA)
wlan.connect(ssid="my_ap", auth=(network.WLAN.WPA2, "my_passwd"))
for _ in range (200):
    if wlan.isconnected():
        wlan.ifconfig(config=("10.0.0.141", "255.255.255.0", "10.0.0.240",  "10.0.0.240"))
        print(wlan.ifconfig())
        break
    else:
        time.sleep_ms(50)
else:
    print("Could not connect")

and add the line
import connect
to main.py. If I boot, then it may connect, after a few reboots, it somehow locks, in that it does not connect to the AP any more. In that state, if I press Ctrl-D a few times, if get a core dump & Reset. The core dump starts with:

PYB: soft reboot
Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x40113db8  PS      : 0x00060a30  A0      : 0x8011fd1a  A1      : 0x3ffbd590  
A2      : 0x3ffc9a00  A3      : 0x3ffd609d  A4      : 0x3ffd60c7  A5      : 0x00000000  
A6      : 0x00000000  A7      : 0x00000000  A8      : 0x80113db8  A9      : 0x3ffbd580  
A10     : 0x3ffc9a4f  A11     : 0x00000000  A12     : 0x0000000f  A13     : 0x3ffc9a5e  
A14     : 0x02ac0f00  A15     : 0x00000000  SAR     : 0x00000010  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x000000f1  LBEG    : 0x4009860c  LEND    : 0x40098617  LCOUNT  : 0xffffffff  

Backtrace: 0x40113db8:0x3ffbd590 0x4011fd17:0x3ffbd5c0 0x4011c891:0x3ffbd610 0x4011d436:0x3ffbd690 0x4011dce1:0x3ffbd760 0x40127265:0x3ffbd780 0x40128e1b:0x3ffbd7d0

================= CORE DUMP START =================
QCsAAAsAAABsAQAA
gNj7P9DU+z942Ps/
0Nb7PxDY+z8ZaybO6EH8P+hB/D+A2Ps/4EH8PwIAAAAQwvs/EML7P4DY+z8AAAAA
FwAAAHzI+z93aWZpAJRVPYhIESdYiUIAAAAAAHjY+z8AAAAAIA4GABcAAAABAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAACAB/0/6Af9P1AI/T8AAAAAAAAAAAEAAAAAAAAA
qFFAPwAAAAAIjAlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHXmuw==
MCf7P7g9EUAwCgYAGv0RgJDV+z8Amvw/nWD9P8dg/T8AAAAAAAAAAAAAAAC4PRGA
gNX7P0+a/D8AAAAADwAAAF6a/D8AD6wCAAAAABAAAAAcAAAA8QAAAAyGCUAXhglA
/////w8AAABemvw/6CsIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAMxi+z+w1fs/AQAAAAAAAACUyBGAwNX7PwCa/D+g1vs/
nWD9PwAAAABAAAAAGAAAAADsEYDQ1fs/AJr8P/ij/D851BGAENb7PwCc/D8DAAAA
UBdCPxDW+z8Amvw/g5r8PzIAAABMAAAAANb7PwIAAACO5BGAAgAAANps/D+QqPw/
NF3HAAAAAABApPw/AJz8P+TcEYCQ1vs/VPn9P5Cq/T8zMzMDUBdCPwEAAAAAAAAA
QjgyAAoAAABgEv0/kGISgFAXQj9U+f0/4Kj8PwAAAAAi5RGAkNb7P/hs/D9kGfw/
LAAAAKBt/D+EYP0/AQAAAAEAAAAK+ghAAwAAACwAAAAAmvw/kKj8P3Rg/T8IAAAA
aHISgGDX+z+Qqv0/LAAAAAAAAAD8bPw//f///wAAAAB+YP0/CAgxBAABZAAAAAAA
mGD9P4wBAAAAAAAAjGD9PwAAAACYYP0/nWD9P8dg/T8AAAAASGH9P61g/T9kYf0/
zWD9PwVh/T8AAAAAiWH9PwAAAAAAAAAAJArEAAr6CIAkYv0/gBQAAP////8IQvw/
EQAAACwAAACQqv0/AAAAAFE8EoBw1/s/KIQJQBAAAAAc+/0/AAAAAAEAAAAAAAAA
AQAAAAUAAABQAAAAAQAAAB6OEoCA1/s/BQAAAAyv/D8AAAAAdGD9P3Rg/T8AAWAB
AAAAANDX+z8Ir/w/YHD8PwAAAACwfPw/CK/8P2Bw/D8AAAAAAAAAAAiv/D+vW8cA
/////9DX+z8Ir/w/YHD8P1hg/T/Q3BFA9QAAAAQAAAAAAAAAENj7PwAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAABEAAAAAAAAAAAAAAAAAAAAaAAAAG44SQIiHQT8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNj7PwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
0HX9P2B0/T/Idf0/

and finally and in a cold boot. Once in this state, the only way to recover and get WiFi again is erase flash and reload the firmware.

Xykon

@robert-hh Any chance you can try without assigning a fixed IP?

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.?

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

New firmware release 1.10.1.b1

Pycom on Twitter