1. Home
  2. Announcements & News
  3. Firmware release 1.7.1.b1

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

Firmware release 1.7.1.b1

  • T

    @daniel: Any ideas why I get those LoadProhibited exceptions? Any hint where I should start searching. I'm just lost on these ...
    The first two seem very low level which makes me wonder .... the third might be related to the issue with ntp_sync.

    0
  • robert-hh

    @daniel Thanks. That looks like the right place. I cannot check it before this evening, by innocenzo may do so.

    1 Innocenzo 1 Reply
  • robert-hh

    This post is deleted!
    0
  • D

    Issue with the safeboot fixed here: https://github.com/pycom/pycom-micropython-sigfox/commit/f29075e4b0a1f713af1d2579465ffd35e360eb12

    1 robert-hh 1 Reply
  • Innocenzo

    @robert-hh Yes. I do it and now I can flash my own firmware, but the file main.py and boot.py do not start "on boot".

    1 robert-hh 1 Reply
  • robert-hh

    @Innocenzo Before the step:
    make BOARD=WIPY flash
    you have to do:
    make BOARD=WIPY erase
    In order to erase the flash memory on the device. Obviously, all content on the device will be lost!

    1 Innocenzo 1 Reply
  • Innocenzo

    @robert-hh Yes. The boot.py and the main.py present in /flash/ dir, do not start after flashing my own firmware.

    0
  • Innocenzo

    @daniel said in Firmware release 1.7.1.b1:

    @Innocenzo have you rebuilt the bootloader? The command is erase instead of flash

    yes.

    • I have erased the old repository ;
    • I have downloaded the new pycom-micropython-sigfox and pycom-esp-idf;
    • git submodule update --init in all repository
    • in pycom-micropython-sigfox/mpy-cross make all
    • in pycom-micropython-sigfox/esp32:
    • make BOARD=WIPY TARGET=boot;
    • make BOARD=WIPY TARGET=app;
    • make BOARD=WIPY flash.
    0 robert-hh 1 Reply
  • robert-hh

    @Innocenzo I had the same trouble (see my posts below): After using the updater tool once, you have to erase the flash BEFORE you use you load youe own-built firmware. You can do that with:

    make erase

    HOWEVER, after doing that, the board does not run boot.py or main.py any more. It considers itself in the safeboot mode. This is a software fault.
    I'm interested if that happes to you too? If yes, you could still call boot.py and main.py from frozen/_boot.py, which is called always.

    1 Innocenzo 1 Reply
  • D

    @Innocenzo have you rebuilt the bootloader? The command is erase instead of flash

    1 Innocenzo 1 Reply
  • Innocenzo

    @daniel what is the command to erase the flash memory?

    Anyway I've update the wipy to 1.7.1.b2 using the updater tool and then I try to update my own firmware but the result doesn't change. Red Led ON.

    0 D 1 Reply
  • D

    @Innocenzo please try erasing your flash memory first as there were changes in the partitions table. Another option is to flash the firmware via the updater tool and then flashing with your own built firmware.

    1 Innocenzo 1 Reply
  • Innocenzo

    @daniel Hi, also the repository on github is updated to 1.7.1.b2?
    I've cloned the new pycom-micropython-sigfox repository and the new pycom-esp-idf repository, but the firmware generated make my wipy board in a fault state (RED led permanently on).

    I must use this procedure in order to create a wipy firmware with some frozen module!

    0 robert-hh 1 Reply
  • T

    @daniel Analyzing the output of today I see tree different stack traces.

    At least once I still got a freeze even with the CS pin switched to P22. I have the subjective feeling that freezing occurs less frequently with the CS pin on P22 rather than P9 but that could be just my imagination.

    sometimes I see strange behavior, that when the python interpreter freezes I can advance it by updating in the ftp window. So it looks like an ftp request to the lopy does advance the python interpreter...
    I do observe this by looking at the serial output which shows debug messages of my app.

    So the following is about issue 2 which indeed seem to be another 3 different issues as I get 3 different stack traces.
    All the following errors occur near flushing data to the sd-card

    Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x400875b9  PS      : 0x00060033  A0      : 0x40088c47  A1      : 0x3ffbd5d0  
A2      : 0x00050023  A3      : 0x00000000  A4      : 0x00000001  A5      : 0x3ffc3dc8  
A6      : 0x000ee81c  A7      : 0x3ffc0df4  A8      : 0x00000005  A9      : 0x00000001  
A10     : 0x3ffc3e34  A11     : 0x00000000  A12     : 0x3ffc3e34  A13     : 0x00000000  
A14     : 0x00000000  A15     : 0x00000000  SAR     : 0x00000016  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000048  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

Backtrace: 0x400875b9:0x3ffbd5d0 0x40088c47:0x3ffbd5f0 0x40088c01:0x3ffbd630 0x4013d1d7:0x000ee81c

0x400875b9: vTaskSwitchContext at /Users/danicampora/Code/Espressif/IDF/esp-idf-20170527/components/freertos/./tasks.c:4873
0x40088c47: _frxt_dispatch at ??:?
0x40088c01: _frxt_int_exit at ??:?
0x4013d1d7: lwip_accept_r at /Users/danicampora/Code/Espressif/IDF/esp-idf-20170527/components/lwip/api/sockets.c:3235


    Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x40087eb9  PS      : 0x00060031  A0      : 0x80086722  A1      : 0x3ffc07b0  
A2      : 0x00000001  A3      : 0x00000001  A4      : 0x000d6f4f  A5      : 0x00000006  
A6      : 0x000002aa  A7      : 0x3ffc5fa0  A8      : 0x3ffc3fbc  A9      : 0x3ffc0790  
A10     : 0x3ffc3e40  A11     : 0x00000001  A12     : 0x00000004  A13     : 0x00000000  
A14     : 0x000000aa  A15     : 0x3ffc5f00  SAR     : 0x00000016  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000009  LBEG    : 0x400f3178  LEND    : 0x400f3180  LCOUNT  : 0x00000000  

Backtrace: 0x40087eb9:0x3ffc07b0 0x40086722:0x3ffc07d0 0x40088c1c:0x3ffc07f0 0x40081861:0x3ffc0800

0x40087eb9: xTaskIncrementTick at /Users/danicampora/Code/Espressif/IDF/esp-idf-20170527/components/freertos/./tasks.c:4873
0x40086722: xPortSysTickHandler at /Users/danicampora/Code/Espressif/IDF/esp-idf-20170527/components/freertos/./port.c:420
0x40088c1c: _frxt_timer_int at ??:?
0x40081861: _xt_lowint1 at xtensa_vectors.o:?


    
Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x40148aec  PS      : 0x00060a30  A0      : 0x8013d9d4  A1      : 0x3ffc5ce0  
A2      : 0x4013d894  A3      : 0x00000000  A4      : 0x00000001  A5      : 0x3ffc5e88  
A6      : 0x3ffc5d50  A7      : 0x00000d5e  A8      : 0x3ffb483c  A9      : 0x3fff8b50  
A10     : 0x00000002  A11     : 0x00000004  A12     : 0x3ffc6a40  A13     : 0x3ffc5e60  
A14     : 0x00000002  A15     : 0x3ffc5e40  SAR     : 0x00000020  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x0000000a  LBEG    : 0x400f7ae2  LEND    : 0x400f7aeb  LCOUNT  : 0x00000000  

0x40148aec: sys_untimeout at /Users/danicampora/Code/Espressif/IDF/esp-idf-20170527/components/lwip/core/timers.c:429
0x4013d9d4: sntp_stop at /Users/danicampora/Code/Espressif/IDF/esp-idf-20170527/components/lwip/apps/sntp/sntp.c:681
0x400dd879: mach_rtc_ntp_sync at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/mods/machrtc.c:55
0x400ef371: fun_builtin_var_call at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/objfun.c:124
0x400eb850: mp_call_function_n_kw at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/runtime.c:562
0x400eb8b8: mp_call_method_n_kw at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/runtime.c:591
0x400f7430: mp_execute_bytecode at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/vm.c:980
0x400ef303: fun_bc_call at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/objfun.c:276
0x400eb850: mp_call_function_n_kw at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/runtime.c:562
0x400eb8b8: mp_call_method_n_kw at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/runtime.c:591
0x400f7430: mp_execute_bytecode at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/vm.c:980
0x400ef303: fun_bc_call at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/objfun.c:276
0x400eb850: mp_call_function_n_kw at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/runtime.c:562
0x400eb87d: mp_call_function_0 at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../py/runtime.c:562
0x400d9166: parse_compile_execute at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../lib/utils/pyexec.c:534
0x400d9435: pyexec_file at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/../lib/utils/pyexec.c:505
0x400d841c: TASK_Micropython at /builds/this-wiederkehr/pycom-micropython-sigfox/esp32/mptask.c:245

    I'll now stop the ntp_sync, ftp and telnet server and see if the app is still going to crash or freeze.

    I also noticed that core dump is not working anymore this leads to multiple exceptions raised in a row all related to the not working core dump. I think this used to work in earlier versions ...

    0 T 1 Reply
  • S
    Pycom Ambassadors

    @daniel Thanks!

    0
  • T

    @daniel Thanks for the update and great you found the issue with ntp_sync.

    P9 on the Lopy is labeld SD_DATA2 that is why I thought it might somehow be involved. I know it is not connected on the expansion board.

    Sorry about P14 should read Pin 14, GPIO25 or P22.

    I have a test going on and will report back if changeing the CS pin to that pin solved the issue with the freeze.

    0 T 1 Reply
  • D

    @Strevens the updater tool is located here: https://www.pycom.io/downloads/

    You can use the following link to the the latest release:

    https://software.pycom.io/downloads/LoPy_868-1.7.1.b2.tar.gz

    If you want a different version, just replace the version number/name on the link accordingly.

    Cheers,
    Daniel

    0 S R 2 Replies
  • S
    Pycom Ambassadors

    @daniel Thanks for the prompt action on the NTP sync. looking forward to the new build.

    could you clarify where the firmware versions are archived as the link on the web says page not found when following the link on quick start page.

    https://www.pycom.io/support/supportdownloads/#firmware

    0
  • D

    @this-wiederkehr something I don't understand. P9 is not used by the SD card, it's P8. Also P14 is an input only pin, so how is that possible that you can use it to act as chip select?

    Cheers,
    Daniel

    1 T 1 Reply
  • D

    @this-wiederkehr thanks for the extra details. We have found the issue with ntp_sync and it's being fixed. We will also add the method to query when that last sync occurred. Using your input we are also investigating the crash and freeze.

    Cheers,
    Daniel

    0
firmware 175
Log in to reply
 

Pycom on Twitter