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