Firmware release 1.7.1.b1

[this.wiederkehr]

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

[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!

[daniel]

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

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

[daniel]

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

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

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

[Innocenzo]

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

[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!

[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".

[daniel]

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

[robert-hh]

This post is deleted!

[robert-hh]

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

[this.wiederkehr]

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

[daniel]

@this.wiederkehr we are investigating this now.

[Innocenzo]

@robert-hh I check it. Now It works.

[daniel]

@this-wiederkehr this:

import machine
import os

sd = machine.SD()
os.mount(sd, '/sd')

f = open('/sd/test', 'a')

while True:
    f.write('blabla')
    print('about to disable irq')
    machine.disable_irq()
    print('about to flush to file')
    f.flush() # <-- freezes reproducible at that call
    print('about to enable irq')
    machine.enable_irq()
    print("I'm done")

is expected to freeze as the SD card uses interrupts. If you disable them before flushing the SD card driver stays waiting for the operation to finish, which never happens as the interrupt doesn't trigger.

Still working on the other crash...

Cheers,
Daniel

[rdixey]

@daniel Does the current updater tool for release LoPy_868-1.7.1.b2.tar.gz incorporate the fix for the ntp_sync issue?

I want to be sure before installing the update. Please confirm.

[daniel]

@rdixey no, that fix is not out yet. The release will be out tomorrow together with other fixes and new features (like the WDT).

[peekay123]

When I ran the Firmware Udpater last night, it installed 1.7.1.b2 (on LoPy) which still has the ntp_sync issue. I also noticed that rtc.local(), which worked on 1.6.7.b1, no longer works on 1.7.1.b2. The following no longer runs (from my boot.py file):

# We are here because wifi connected so set the RTC time
from machine import RTC

rtc = machine.RTC()
rtc.ntp_sync("pool.ntp.org")
utime.sleep_ms(750)
time.timezone(-14400)
print(rtc.local())