New firmware release 1.10.0.b1 (External 4MByte RAM support)

[rcolistete]

@daniel said in New firmware release 1.10.0.b1 (External 4MByte RAM support):

Add .voltage() method and calibration functions to the ADC class.

Please update the Pycom docs about this new calibration method to the ADC. Many people want to use the ESP32 ADC with better readings.

[yahia]

@daniel First, thanks for the update! I was just asking about freezing main and boot, having _main.py should make it even easier.

There is one thing I noticed though: when flashing or erasing the chip, the script gets stuck at "Staying in bootloader" and then crashes. However, the chip gets erased or flashed (depending on the command) even though the crash occurs so it is not really affecting the process. I guess it just doesn't hard reset like before.

[hay4to]

with the new update the machine.reset() call block the board.
[edit] the board run a pure version of the new release, updated via Pycom firmware update

[daniel]

@affoltep can you be more specific? The new firmware has the same amount of MicroPython heap available as before (67K). What is the error that you are seeing in your app?

Cheers,
Daniel

[daniel]

@hay4to thanks. We will investigate this.

[ssmith]

@daniel I'm getting the following error while trying to boot

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff9028,len:8
load:0x3fff9030,len:932
load:0x4009fa00,len:0
ho 12 tail 0 room 4
load:0x4009fa00,len:13232
entry 0x400a04e8
adding frozen/lib to load path
Debug print statements TRUE
Debug print statements TRUE
mem_free:
creating ody_globals
SN: c400b6f0
_main_interval: 600
boot_monitor interval: 600
starting bluetooth configuration
creating new bt instance
/Users/danicampora/Code/Espressif/IDF/esp-idf-20171106/components/freertos/./timers.c:670 (prvProcessReceivedCommands)- assert failed!
abort() was called at PC 0x4008b864 on core 0

Backtrace: 0x4008cf33:0x3ffd9d50 0x4008cf64:0x3ffd9d70 0x4008b864:0x3ffd9d90

================= CORE DUMP START =================
jDwAABEAAABsAQAA
NJ79P5Cc/T8snv0/
wJv9P8Cd/T8AAAAA6D/8P+g//D80nv0/4D/8PxgAAABkl/0/ZJf9PzSe/T8AAAAA
AQAAADCY/T9UbXIgU3ZjAHn5N0qhEt8AAAAAACye/T8AAAAAIQAGAAEAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAB4Kf0/4Cn9P0gq/T8AAAAAAAAAAAEAAAAAAAAA

Any ideas?

Thanks,
Steve

[livius]

@ssmith said in New firmware release 1.10.0.b1 (External 4MByte RAM support):
do you have reproductive test case?

prvProcessReceivedCommands

@daniel interesting which path in xTimerGenericCommand return this failed response

[ssmith]

@livius I haven't tried to narrow it down yet. This occurs while trying to load our whole application. Has something changed with the timers?

[daniel]

@ssmith said in New firmware release 1.10.0.b1 (External 4MByte RAM support):

prvProcessReceivedCommands

The stack size of the timer task changed. This is probably the culprit (stack overflow).

[daniel]

@hay4to we have fixed the machine.reset() hang.

[daniel]

Hi everyone,

Thanks for the quick feedback. We are working through all the issues you have reported and a new update will be out within 48hrs.

Cheers,
Daniel

[ssmith]

@daniel said in New firmware release 1.10.0.b1 (External 4MByte RAM support):

@ssmith said in New firmware release 1.10.0.b1 (External 4MByte RAM support):

prvProcessReceivedCommands

The stack size of the timer task changed. This is probably the culprit (stack overflow).

Is there a way to monitor the stack size and also available memory for loading modules? We have been fighting out of memory issues for months. I know we can move things to frozen bytecode but things are still changing so we can't really do that yet.

[Xykon]

@ssmith said in New firmware release 1.10.0.b1 (External 4MByte RAM support):

Is there a way to monitor the stack size

import machine                                                              
machine.info()                                                              
---------------------------------------------                                   
System memory info (in bytes)                                                   
---------------------------------------------                                   
MPTask stack water mark: 5520                                                   
ServersTask stack water mark: 988                                               
LoRaTask stack water mark: 1720                                                 
TimerTask stack water mark: 976                                                 
IdleTask stack water mark: 268                                                  
System free heap: 64744                                                         
---------------------------------------------                                   

Returns the high water mark of the stack associated with xTask. That is,
the minimum free stack space there has been (in words, so on a 32 bit machine a value of 1 means 4 bytes) since the task started. The smaller the returned number the closer the task has come to overflowing its stack.

Hope this helps.

[ssmith]

@xykon That's perfect. Thanks!

[Smeedy]

@crumble Have you been able to fix this?

Probably related. I just updated two plain LoPy units to the 1.10.0.b1 and lost the ability to use the REPL for input. Looks like some timings are wrong. I am able to send an occasional ctrl-c if I'm lucky - as it is still running the old main.py, which is odd in it self after the flash.

[Smeedy]

Ok. Managed to get the system up and running again by putting P24 low and erasing the flash using the esptool and start clean. I now have the REPL input back on the LoPy.

So if you haven't already

pip3 install esptool
esptool.py --port /dev/ttyUSB2 --baud 230400 --chip esp32 erase_flash

now you can use the UI flasher for 1.10.0.b1

[affoltep]

@daniel said in New firmware release 1.10.0.b1 (External 4MByte RAM support):

@affoltep can you be more specific? The new firmware has the same amount of MicroPython heap available as before (67K). What is the error that you are seeing in your app?

Cheers,
Daniel

I was wrong. It doesn't seem to be a memory issue, but a deepsleep shield for LoPy issue. As soon I want to use the deepsleep shield an error message occurs. Unfortunately I can not send you the message, because I flashed back to the old version before doing a print.

But here is the code I used to check:

import deepsleep

ds = deepsleep.DeepSleep()

# get the wake reason and the value of the pins during wake up
wake_s = ds.get_wake_status()
print(wake_s)

if wake_s['wake'] == deepsleep.PIN_WAKE:
    print("Pin wake up")
elif wake_s['wake'] == deepsleep.TIMER_WAKE:
    print("Timer wake up")
else:  # deepsleep.POWER_ON_WAKE:
    print("Power ON reset")

#Initiate deep sleep shield
ds = deepsleep.DeepSleep()
ds.enable_auto_poweroff()
ds.disable_pullups(['P17', 'P18'])
ds.disable_wake_on_raise(['P17', 'P18'])
ds.disable_wake_on_fall('P18')
ds.enable_wake_on_fall('P17')

ds.go_to_sleep(20)  # go to sleep for 60 seconds

[Smeedy]

Last remark. Since 1.10.0.b1 a boot.py fragment on the UART was preventing the REPL input as it seems when using the serial connection. I commented the following part:

# uart = UART(0, 115200)
# os.dupterm(uart)

and I was able to use the REPL again on the 1.10.0.b1 firmware

[marmarti]

I found an issue with this version on sipy. I was simply not able to send a message to sigfox.

[ksid]

@smeedy I think you meant P2 here or G23 on the breakout. This is exactly what I needed and solved my problem. As a note to others after erasing the flash I had to remove and re-apply power before running the UI flasher.