FiPy Core Dump



  • Hi, I have a serious issue with one of my 2 FiPy's.
    The first one works pretty well, while the second one is impossible to use, always prompting that in the console (like every 6 seconds).
    I assume the firmware is corrupted, and it keeps reeboting > Core Dump ...

    Do you have any idea on how to fix this and bring back the factory firmware ?

    Thanks

    AAAAAA==
    ================= CORE DUMP END =================
    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:1060
    load:0x4009fa00,len:0
    ho 12 tail 0 room 4
    load:0x4009fa00,len:14084
    entry 0x400a05d4
    Guru Meditation Error: Core  1 panic'ed (LoadProhibited)
    . Exception was unhandled.
    Register dump:
    PC      : 0x4008d9ff  PS      : 0x00060e33  A0      : 0x80083c11  A1      : 0x3ffd3e30
    A2      : 0x3f800000  A3      : 0x0000003c  A4      : 0x3fbc0134  A5      : 0xffffffff
    A6      : 0x3f940080  A7      : 0x3fbffff4  A8      : 0x00000050  A9      : 0x3ffd3e10
    A10     : 0xc0400004  A11     : 0x00000001  A12     : 0x00000000  A13     : 0x00000001
    A14     : 0x3ffc58a6  A15     : 0x00000000  SAR     : 0x00000000  EXCCAUSE: 0x0000001c
    EXCVADDR: 0xffffffff  LBEG    : 0x4009a78d  LEND    : 0x4009a7a1  LCOUNT  : 0xfffffffe
    
    Backtrace: 0x4008d9ff:0x3ffd3e30 0x40083c0e:0x3ffd3e60 0x40083cab:0x3ffd3e90 0x4015dfb4:0x3ffd3ee0 0x4015ce87:0x3ffd3f00 0x4014c9fd:0x3ffd3f40 0x400e7fd0:0x3ffd3f60 0x400dcd2a:0x3ffd3fa0


  • I've merged what was comprehensible:

    ets Jun  8 2016 00:22:57
    
    rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
    coUMP END =================
    Rebootin0,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
    mx17 (SPI_FAST_FLASH_BOOT)
    configsip: 0, SPIWP:0xee
    clk_drv:0x0:1060
    load:0x4009fa00,len:0
    ho 12 tail 0 room 4
    load:0x4009fode:DIO, clock div:1
    load:0x3fff9028,len:8
    load:0x3fff9030,lenabort() was called at PC 0x4008dbb4 on core 1
    
    Backtrace: 0x4a00,len:14096
    entry 0x400a05e0
    x40083c16:0x3ffd42f0 0x40083cb3:0x3ffd4320 0x4015ea88:0x3ffd437008e05f:0x3ffd4280 0x4008e090:0x3ffd42a0 0x4008dbb4:0x3ffd42c0 03f0 0x400dce42:0x3ffd4430
    
    ================= CORE DUMP START 0 0x4015d95b:0x3ffd4390 0x4014d4d1:0x3ffd43d0 0x400e8a2c:0x3ffd4T+JBAAALFP8PyxT/D+8RP0/JFP8PxQAAAAAAAAAAAAAALxE/T8AAAAA
    BQAAAL=================
    
    Connecting on /dev/cu.usbmodemPy343431...
    /Users/danicampora/Code/Espressif/IDF/esp-idf-20180112/componena00,len:14096
    entry 0x400a05e0
    bort() was callea at PC 0xs008aaa8 on cor0x00
    
    Backtrace: 0x40ts/freertos/./queue.c:718 (xQueueGenericSend)- assert failed!
    a4015d282:0x3ffd3bb0 0x4015d41a:0x3ffd3bd0 0x40155916:0x3ffd3c00 0x4014e3ec:0x3ffd3c20
    
    ====x3ffd3b50 0x4008aaa8:0x3ffd3b70 0x=============
    HC0AAA4AAABsAQAA
    BFP9P3A6/T+wPP0/
    oDn9P1A8/T+N 0x4014e3ec:0x3ffd3c20
    
    ================= CORE DUMP END =================
    Rebooting...
    ets Jun  8 2016 00:22:57
    
    rst:0xc (SW_CPU_RESET),boot:0x12 (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:1060
    load:0x4009fa00,len:0
    ho 12 tail 0 room 4
    load:0x4009fa00,len:14096
    entry 0x400a05e0
    abort() was called at PC 0x4008dbb4 on core 1
    
    Backtrace: 0x4008e05f:0x3ffd4280 0x4008e090:0x3ffd42a0 0x4008dbb4:0x3ffd42c0 0x40083c16:0x3ffd42f0 0x40083cb3:0x3ffd4320 0x4015ea88:0x3ffd4370 0x4015d95b:0x3ffd4390 0x4014d4d1:0x3ffd43d0 0x400e8a2c:0x3ffd43f0 0x400dce42:0x3ffd4430
    
    ================= CORE DUMP START =================
    

    Looks like this line will provide you more infos:

    Backtrace: 0x40ts/freertos/./queue.c:718 (xQueueGenericSend)- assert failed!


  • @adrien3d

    If you can share the complete back trace generated by the latest firmware, I'll pass this on to the firmware team to look over again. With the back trace they can pinpoint where the error occurs.



  • @seb Not fixing anything :/



  • Can you please try the new firmware and report if this fixes the issue you are experiencing?



  • @adrien3d
    Hi,

    Unfortunately this issue is proving more elusive than we previously thought. It is being actively investigated, I will keep you updated with the progress.



  • Does the 1.16.0b1 firmware solves the problem ?



  • @ssmith
    Hi,
    I've been informed it is caused by a race condition that occurs early in the boot process, I'm afraid that's all I know. It is actively being worked on as we speak and a fix will be released along with our next firmware update.



  • @seb Can you provide some more details on this? We've been fighting a crash like this for the past week on the LoPy4.

    Thanks,
    Steve



  • @adrien3d
    I can't provide an exact date but it will be included with the next firmware version which will be released within the next two weeks



  • @seb Do you have any ETA for a firmware release that will fix this bug?



  • @robert-hh
    Erasing the flash does not erase the registration details, these are kept in a database on our end and the firmware updater will automatically add them in with each update. If there is an issue with registration details we recommend customers email support@pycom.io and we will be able to reset the info in our database.



  • Hey,

    We are aware of this bug, it seems to be a race condition in the firmware. The next firmware release will have this bug fixed.



  • @adrien3d It used to be an option to erase flash and then reload the formware. I'm not using the standard firmware loader, so I do not know whether this method is avalable, and erasing the whole flash also erases the registration information for the communication modules. May @seb could shed some light on that.



  • @robert-hh The 2 boards are loaded with the same latest firmware (1.15.0b1), so I have to send the defective one back to Pycom ?
    There is no hardware reset or something else to try before ?



  • @adrien3d There is nothing like a factory firmware in the board. The only thing you can do is to run the firmware install process, which will load the most recent firmware. There is also a method for installing previous versions of the firmware.
    if one of the board runs well with firmware version x, and the other constatly shows a core dump, then thsi device is defective and should be returned to the vendor for replacement.


Log in to reply
 

Pycom on Twitter