New firmware release 1.10.2.b1

[daniel]

NEW UPDATER TOOL PATCH: Some users are experiencing Guru meditation errors on the 4MByte of RAM devices with this update. An intermediate solution for this while we release a new version of the updater is to patch the current one.

Please follow these instructions:

Find the location where the Pycom Firmware Update application is installed. Then enter the directory (on Mac OS you need to right click and select "Show Package Contents").

Within the files of the app, locate the one named updater.py.

Inside that file find the following 3 lines which appear twice:

args.flash_size = '4MB'
args.flash_mode = 'dio'
args.flash_freq = '40m'

Change the lines to read:

args.flash_size = 'detect'
args.flash_mode = 'dio'
args.flash_freq = '80m'

A new firmware release is out. The version is v1.10.2.b1. This release brings full external RAM support for the newer modules. With this the MicroPython heap is as big a 3 MBytes.

The Github sources have been updated as well with the changes from this release.

Here's the full change log:

• esp32: Introduce machine.temperature().

  Read ESP32 internal temperature sensor (not an official API, unreliable - see
  https://github.com/espressif/esp-idf/issues/146)

  • Make sure to call nvs_commit after nvs_erase_all
  • Allow adding channels with LoRaWAN datarates lower than DR5 - fixes issue #96

• esp32: Do not close the WLAN connection before changing the STA IP config.

• esp32: Update the IDF libraries. Fix memory corruption problems. Fix UART garbage after soft reset or WDT reset.

• esp32: Erase NVS space if no free pages during init.

• esp32: Improve uart 1 pin mode reliability. Fixes comm issues with the deepsleep shield.

• esp32: Faster way to check if the UART TX_FIFO is empty.

• esp32/frozen: Fix bug in AWS libraries with disconnect method missing.

As usual this new firmware can be applied using our firmware update tool: https://pycom.io/downloads/

Cheers,
Daniel

[livius]

@daniel
what about internal hall sensor? :)
https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/esp32-hal-adc.c

[jmarcelino]

@livius
It's coming, we need to keep some features for the next release :)

[robert-hh]

@daniel said in New firmware release 1.10.2.b1:

machine.temperature()

Do you have some information about the value which is returned. I read something between 119 and 124. What is the physical representation of that value? °F, °C, or just something, that must be scaled to a temperature value?
Looking through the net, there is a sketch at https://github.com/pcbreflux/espressif/blob/master/esp32/arduino/sketchbook/ESP32_int_temp_sensor/ESP32_int_temp_sensor.ino which indicates that the returned value is °F, so ~120 results in ~50°C((value - 32) / 1.8).
Update: Another guess based on the information, that the sensor is specified at a range of -40°C~125°C, and temprature_sens_read() returns a unit8_t value. That would result in a scaling formula for °C of (value/1.55)-40, and a return value of 120 is then equivalent to 37°C. Assuming a power dissaption of 500mW, a typical thermal resistance of a QFN package of 30°C/W, and an ambient temperature of 20°C, this is reasonable, at least more than 50°C.

[jmarcelino]

Hi @robert-hh,
I noticed that example on the Arduino ESP32 repo but I'm not sure it's actually a valid interpretation.

There is no documentation for this yet from Espressif - the most official source if on the github issue linked above - but realistically the sensor is only useful to detect changes in temperature, so I guess you'd have to calibrate a starting point.

This post from a user who attached an external temperature sensor to the ESP32 may be interesting: https://github.com/espressif/esp-idf/issues/146#issuecomment-311336468 but on Pycom boards with the metal shield, varying number of PCB layers, other heat sources and attachments you'll have a real hard task getting actual external temperature values.

May be more useful when clock frequency switching is implemented :)

[robert-hh]

@jmarcelino Hello Jose, yes, I've seen that link, but it did not tell me much. For the scaling ratio, I can apply the to device a known temperature ratio range, like between 0°C and 50°C, but that would not tell me the offset between internal and external temperature, which depends on many factors.
Finally, it may only be useful to test, whether the device overheats, which would happen under normal power conditions at an ambient temperature of about 100°C, pretty cozy!

[crumble]

Has firmware update never worked when LoPy is plug in PyTrack and pin 10 is shortened? I got a lot of trouble updating 1.10.1 to 1.10.2

I wish this damn update GUI has a retry button and will show up some other reasons than failed. Wwwuaahh, this wasted a lot of time. I shorten pin 10 to enter my develop mode, which breaks the main loop and go into the REPL. Switching off develop mode was the last step I tried, after a LoPy in expansion board updated from 1.9.x

[Xykon]

@crumble You need to connect P2 / G23 (or Pin 5 on the external expansion header) to GND and reset the module to enter firmware update mode.

I'm working on a new firmware update tool that will do this automatically for the Pysense and Pytrack... hopefully this will be ready with the next firmware release.

[crumble]

@xykon said in New firmware release 1.10.2.b1:

@crumble You need to connect P2 / G23 (or Pin 5 on the external expansion header) to GND and reset the module to enter firmware update mode.

Yes, did that.

While typing I traced back the wires and figured out, That I soldered a switch on the pytrack external IO header between pin10 and 3V3_sensors. Maybe this was a bad idea, but I already used GND for my HT-22 sensor. So I had a cunning plan...

The switch for P2/G23 is soldered directly on the LoPy developer board.

If both switches are set, the LoPy shows up in device manger of Win7 but will not be detected as connected by the firmware updater. If switch of p10/3v3 is open, everything works fine.

[JuanMa]

I've just update my Lopy device and I experiment a Core Dump each time I call py.go_to_sleep(). Is this a known error??
This is the backtrace:

abort() was called at PC 0x4008ca64 on core 0

Backtrace: 0x4008cf0f:0x3ffda5a0 0x4008cf40:0x3ffda5c0 0x4008ca64:0x3ffda5e0 0x40083482:0x3ffda610 0x400834c4:0x3ffda640 0x40083205:0x3ffda660 0x4000bef5:0x3ffda680 0x4013f786:0x3ffda6a0 0x40102ab3:0x3ffda6d0 0x40102b85:0x3ffda710 0x400f35c6:0x3ffda740 0x400eff91:0x3ffda770 0x400efff9:0x3ffda790 0x400fb27d:0x3ffda7b0 0x400f365c:0x3ffda850 0x400eff91:0x3ffda890 0x400efff9:0x3ffda8b0 0x400fb27d:0x3ffda8d0 0x400f365c:0x3ffda970 0x400eff91:0x3ffda9b0 0x400efff9:0x3ffda9d0 0x400fb27d:0x3ffda9f0 0x400f365c:0x3ffdaa90 0x400eff91:0x3ffdab30 0x400effbe:0x3ffdab50 0x400dd887:0x3ffdab70 0x400ddb3c:0x3ffdac10 0x400dcb83:0x3ffdac30

Thanks,
JuanMa

[Colateral]

Same build problem with pypic using msys2 and no pysense or pytrack

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 62, in open
raise SerialException("could not open port {!r}: {!r}".format(self.portstr, ctypes.WinError()))
serial.serialutil.SerialException: could not open port 'COM7': WindowsError(2, 'The system cannot find the file specified.')

[Xykon]

@colateral said in New firmware release 1.10.2.b1:

self.serial = serial.Serial(port, baudrate=115200, bytesize=serial.FIVEBITS, timeout=0.25)

Can you please try the following:

Open tools/pypic.py and find the line:
self.serial = serial.Serial(port, baudrate=115200, bytesize=serial.FIVEBITS, timeout=0.25)

Replace it with:
self.serial = serial.Serial(port, baudrate=115200, bytesize=serial.FIVEBITS, timeout=0.25, exclusive=True)

Please let me know if that works for you. I have tested it only on Windows 10 Pro.

[Smeedy]

Hi there,

As always, thanks for the fine work. I noticed a crash on the PyTrack with this firmware when I try to put it to sleep or even issuing a pt.setup_sleep(n). Anyone else? I tried this on some lopy devices and a wipy rev2. Same problem.

Thanks,
Martijn

[Xykon]

@crumble If you check with Putty on Windows you should see a message "Waiting for download" if P2/G23 is pulled to GND while you press the reset button on the module.

If you see that message, close Putty and the firmware update tool should detect the device.

[Colateral]

Hi,

With this build I have I2C crash many times on different L01 boards:

Using BME280 with I2C on P22 P23 I tried several time read it and deinit the bus

With this build after bus.deinit() I got the dump many times ..

abort() was called at PC 0x4008ca64 on core 0

Backtrace: 0x4008cf0f:0x3ffbd470 0x4008cf40:0x3ffbd490 0x4008ca64:0x3ffbd4b0 0x40083482:0x3ffbd4e0 0x4008366e:0x3ffbd510 0x4012e195:0x3ffbd530 0x40120fa9:0x3ffbd560 0x40120cda:0x3ffbd580 0x40119e37:0x3ffbd5b0 0x4011a104:0x3ffbd610 0x40110c32:0x3ffbd660 0x401112b7:0x3ffbd730 0x40127445:0x3ffbd750 0x40128f77:0x3ffbd7a0

================= CORE DUMP START =================
xCYAAAsAAABsAQAA
VNj7P7DT+z9M2Ps/
oNb7P+DX+z/9zznC8EP8P/BD/D9U2Ps/6EP8PwIAAADkwfs/5MH7P1TY+z8AAAAA
FwAAAFDI+z93aWZpAI6WpE51xRNSgpQAAAAAAEzY+z8BAAAAIA4GABcAAAABAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAADcSf0/REr9P6xK/T8AAAAAAAAAAAEAAAAAAAAA
iFJAPwAAAAAcjAlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

[Colateral]

L01 board: listening on IRQ on pin 18 and pin 15 in the same time, raise Guru Mediation randomly.

            pin15=Pin('P15',mode=Pin.IN)
            pin18.callback(Pin.IRQ_FALLING , callback)

            pin15=Pin('P18',mode=Pin.IN)
            pin18.callback(Pin.IRQ_FALLING , callback)

With the previous build this issue is not present.

Guru Meditation Error: Core 0 panic'ed (Cache disabled but cached memory region accessed)
Register dump:
PC : 0x40083948 PS : 0x00060034 A0 : 0x40082e85 A1 : 0x3ffc09e0
A2 : 0xbad00bad A3 : 0x00000001 A4 : 0x3ff5f000 A5 : 0x4008b944
A6 : 0x3ff420b0 A7 : 0x3ffdc82c A8 : 0x80083a71 A9 : 0x000001ff
A10 : 0x00000000 A11 : 0x3ff42000 A12 : 0x800968d1 A13 : 0x3ffdb080
A14 : 0x00000000 A15 : 0x3ffdb0b0 SAR : 0x00000014 EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000 LBEG : 0x40097034 LEND : 0x4009703f LCOUNT : 0x00000003

Backtrace: 0x40083948:0x3ffc09e0 0x40082e82:0x3ffc0a00 0x40097034:0x00000000

================= CORE DUMP START =================
vCMAAAoAAABsAQAA
iHP7P7Bx+z+Ac/s/

[daniel]

@Colateral thanks for the bug report. We will investigate it.

[Colateral]

L01 board. Sendn continuously MQTT messages crashing the board

1970:01:01 04:25:31 DEBUG:Conn: SEND <MqttConn object at 3f821f80> value
POS 000 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032
HEX 001 003 0CD 04B 000 017 000 07F 0AC 0A6 000 000 000 000 000 000 000 000 000 000 000 048 008 08F 042 022 042 038 046 044 045 047 0AE
DEC 001 003 205 075 000 023 000 127 172 166 000 000 000 000 000 000 000 000 000 000 000 072 008 143 066 034 066 056 070 068 069 071 174

Guru Meditation Error of type StoreProhibited occurred on core 0. Exception was unhandled.
Register dump:
PC : 0x400f55e4 PS : 0x00060a30 A0 : 0x800fe1e9 A1 : 0x3ffd6520
A2 : 0xffffffff A3 : 0x3ffd6540 A4 : 0x3f85b4a0 A5 : 0x00000002
A6 : 0x00000000 A7 : 0x00000f12 A8 : 0x00000000 A9 : 0x3ffd6500
A10 : 0x00000000 A11 : 0x00000000 A12 : 0x00000001 A13 : 0x00000001
A14 : 0x00000001 A15 : 0x00000f12 SAR : 0x00000002 EXCCAUSE: 0x0000001d
EXCVADDR: 0xffffffff LBEG : 0x40098620 LEND : 0x4009862b LCOUNT : 0x00000000

Backtrace: 0x400f55e4:0x3ffd6520 0x400fe1e6:0x3ffd6540 0x400f35d2:0x3ffd6580 0x400eff91:0x3ffd65b0 0x400fb1e7:0x3ffd65d0 0x400f365c:0x3ffd6670 0x400eff91:0x3ffd6710 0x400efff9:0x3ffd6730 0x400fb27d:0x3ffd6750 0x400f365c:0x3ffd67f0 0x400eff91:0x3ffd6830 0x400efff9:0x3ffd6850 0x400fb27d:0x3ffd6870 0x400f365c:0x3ffd6910 0x400eff91:0x3ffd6990 0x400efff9:0x3ffd69b0 0x400fb27d:0x3ffd69d0 0x400f365c:0x3ffd6a70 0x400eff91:0x3ffd6af0 0x400efff9:0x3ffd6b10 0x400fb27d:0x3ffd6b30 0x400f365c:0x3ffd6bd0 0x400eff91:0x3ffd6c10 0x400efff9:0x3ffd6c30 0x400fb27d:0x3ffd6c50 0x400f365c:0x3ffd6cf0 0x400eff91:0x3ffd6d80 0x400efff9:0x3ffd6da0 0x400fb27d:0x3ffd6dc0 0x400f365c:0x3ffd6e60 0x400eff91:0x3ffd6ef0 0x400efff9:0x3ffd6f10 0x400fb27d:0x3ffd6f30 0x400f365c:0x3ffd6fd0 0x400eff91:0x3ffd7050 0x400efff9:0x3ffd7070 0x400fb27d:0x3ffd7090 0x400f365c:0x3ffd7130 0x400eff91:0x3ffd7170 0x400fb1e7:0x3ffd7190 0x400f365c:0x3ffd7230 0x400eff91:0x3ffd72b0 0x400effbe:0x3ffd72d0 0x400dd887:0x3ffd72f0 0x400dd9dc:0x3ffd7390 0x400dcb98:0x3ffd73c0

================= CORE DUMP START =================
tDEAAAsAAABsAQAA
nEX8P2Bk/T9odf0/
oGH9PwB1/T/JMPMAiEL8P4hC/D+cRfw/gEL8PxQAAACQ2v0/kNr9P5xF/D8AAAAA
BQAAAGxV/T9NaWNyb1B5AAAAAAAAAAAAAAAAAGh1/T8AAAAAIAwGAAUAAAABAAAA
8GD7P2hO/D9cNA1AAAAAAIAAAADcSf0/REr9P6xK/T8AAAAAAAAAAAEAAAAAAAAA