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



  • @xykon That's perfect. Thanks!


  • administrators

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



  • @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.



  • 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



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



  • @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).



  • @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?



  • @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



  • @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



  • @hay4to thanks. We will investigate this.



  • @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



  • 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
    0_1510223491893_failed reset.PNG



  • @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.

    0_1510220827428_Screenshot from 2017-11-09 10-35-51.png



  • @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.



  • @robert-hh the reason the board doesn’t automatically programs anymore is because we added the no_reset options to the command line arguments of esptool.
    Probably the software doesn’t run anymore because it’s trying to initialize the pSRAM in a device that doesn’t have it fitted. The new firmware uses the chip revision to decide if it’s a gen1 or gen2 of our boards.

    Cheers,
    Daniel



  • As some others I have problems to connect via USB after this update. I have a LoPy mounted on a PyTrack. Both with latest firmware. The host is Win7 running Atom with the Plugin before the change with the splitted sync button.

    If the timing is right, data will be send from the LoPy to the PC. I can see output from my main.py and the REPL with the prompt.
    The other direction seems not to work. Typing will not show echo from the LoPy. Selecting reconnect or the "show version" does not work.

    To see the output I have to deinstall the PyTrack in the device manager and hope that reinstall is ready before the prompt is send.

    Have you changed the default settings for the serial?



  • @xykon Thx, Xykon

    I just realized that it may has a context with the new deepsleep functionality of 1.10.0.b1. Does the deepsleep shield lib 1.0.1 need to be updated?



  • @daniel

    Looking into the diffs, it looks like you also addressed the glitch between OTA and USB loads.

    No, you did not. No problem, just important to know.



  • @daniel This is nothing directly affecting xxPy, but maybe useful observations for the future:
    I tried to load the WiPy image to a LOLIN32 and a LOLIN32 Lite.
    a) For both, the automatic enabling of pulling GP23 low does not work any more. Changing a line in application.mk to:
    ESPTOOLPY_SERIAL = $(ESPTOOLPY) --port $(ESPPORT) --baud $(ESPBAUD)
    made it working again.
    b) The firmware does not run any more on the LOLIN32 Lite, which has a ESP32D0WDQ6 (revision 1) chip.
    Error trace:

    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:2
    load:0x3fff9028,len:8
    load:0x3fff9030,len:932
    load:0x4009fa00,len:0
    ho 12 tail 0 room 4
    load:0x4009fa00,len:13232
    entry 0x400a04e8
    abort() was called at PC 0x40081175 on core 0
    
    Backtrace: 0x4008bfd3:0x3ffe3c40 0x4008c004:0x3ffe3c60 0x40081175:0x3ffe3c80 0x400a01da:0x3ffe3cc0 0x400a0241:0x3ffe3cf0 0x400a04e2:0x3ffe3d20 0x400a05be:0x3ffe3e70 0x40007c31:0x3ffe3eb0 0x4000073d:0x3ffe3f20
    

  • administrators

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

    I need a simple way to downgrade to the version before...

    You can find downgrade instructions here. Please use the following download links for the previous version:


Log in to reply
 

Pycom on Twitter