WiPy 2.0 not working after firmware update.
-
I just updated to the latest firmware (1.6.12.b1) with the firmware updater tool over serial. The tool said the update was successful, but when I reset the board after removing the update mode cable (P2 to GND) here is what i saw on the serial terminal after pressing the reset button:
ets Jun 8 2016 00:22:57 rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:QIO, clock div:2 load:0x3fff9010,len:8 load:0x3fff9018,len:248 load:0x40078000,len:4056 load:0x4009fc00,len:920 entry 0x4009fde4 I (1571) wifi: wifi firmware version: 90b1b8b I (1572) wifi: config NVS flash: disabled I (1572) wifi: config nano formating: disabled I (1587) wifi: Init dynamic tx buffer num: 32 I (1587) wifi: wifi driver task: 3ffd5558, prio:23, stack:3584 I (1588) wifi: Init static rx buffer num: 10 I (1590) wifi: Init dynamic rx buffer num: 0 I (1594) wifi: Init rx ampdu len mblock:7 I (1597) wifi: Init lldesc rx ampdu entry mblock:4 I (1602) wifi: wifi power manager task: 0x3ffda914 prio: 21 stack: 2560 I (1608) wifi: sleep disable I (2597) wifi: wifi timer task: 3ffdb990, prio:22, stack:3584 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒The character you see at the bottom is the Unicode 'Medium Shade` chatacter U+2592, and it is constantly getting printed to the serial monitor (Putty in this case). I have repeated the update procedure multiple times, and I get the same result. In some cases when I press the reset button only a single medium shade character is printed, but this seems to happen at random.
I have also tried the safe boot mode, to no avail. The orange LED flashes as usual, but the same thing is printed every time, no matter when I remove the cable. Any help would be appreciated.
-
@robert-hh Unfortunately deep sleep hasn't been implemented in the latest version I can use (1.6.3). I will try to implement it myself later today though.
-
@BluCode No clue. I think you have to wait for Pycom solving that issue, and use meanwhile an working version of the firmware, if possible.
-
@robert-hh I have used esptool to erase my flash, and that changes nothing. Do you know if anything is stored somewhere else that may be causing the issue?
-
@robert-hh I am using LXSS (bash on ubuntu on windows) to build, and then copying the files over to a folder on my windows machine and using esptool to actually flash. I have tried that once, with no effect, but I may as well try again, just in case.
-
@BluCode Since you have the build environment ready, have you ever tried to erase the flash and then reload the firmware. Erasing can be accomplished by:
make BOARD=WIPY erase
Sometimes that helps.
-
@bucknall I just built and tested with the latest update to the repo, and here are my boot messages:
ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) ets Jun 8 2016 00:22:57 rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:QIO, clock div:2 load:0x3fff9010,len:8 load:0x3fff9018,len:248 load:0x40078000,len:4072 load:0x4009fc00,len:940 entry 0x4009fdec I (1550) wifi: wifi firmware version: 90b1b8b I (1551) wifi: config NVS flash: disabled I (1551) wifi: config nano formating: disabled I (1566) wifi: Init dynamic tx buffer num: 32 I (1566) wifi: wifi driver task: 3ffd5608, prio:23, stack:3584 I (1567) wifi: Init static rx buffer num: 10 I (1569) wifi: Init dynamic rx buffer num: 0 I (1573) wifi: Init rx ampdu len mblock:7 I (1576) wifi: Init lldesc rx ampdu entry mblock:4 I (1581) wifi: wifi power manager task: 0x3ffda9c4 prio: 21 stack: 2560 I (1587) wifi: sleep disable I (2576) wifi: wifi timer task: 3ffdba40, prio:22, stack:3584 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
-
-
I have done more testing, and I think I have narrowed down the issue. It works fine with versions before 1.6.4.b1, and 1.6.4.b1 and up all break in the same way. The boot messages of 1.6.3.b1 are:
ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) ets Jun 8 2016 00:22:57 rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:QIO, clock div:2 load:0x3fff9010,len:8 load:0x3fff9018,len:248 load:0x40078000,len:4056 load:0x4009fc00,len:920 entry 0x4009fde4 I (1611) wifi: frc2_timer_task_hdl:3ffd491c, prio:22, stack:2048 I (1626) wifi: Init lldesc rx mblock:10 I (1627) wifi: Init lldesc rx ampdu len mblock:7 I (1627) wifi: Init lldesc rx ampdu entry mblock:4 I (1628) wifi: pp_task_hdl : 3ffdba58, prio:23, stack:8192 I (1633) wifi: sleep disable I (2622) wifi: mode : softAP (24:0a:c4:00:b0:43)and the boot messages of anything above that are:
ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) ets Jun 8 2016 00:22:57 rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:QIO, clock div:2 load:0x3fff9010,len:8 load:0x3fff9018,len:248 load:0x40078000,len:4056 load:0x4009fc00,len:920 entry 0x4009fde4 I (1564) wifi: wifi firmware version: 2a22b2d I (1579) wifi: pp_task_hdl : 3ffd64dc, prio:23, stack:8192 I (1579) wifi: Init lldesc rx mblock:10 I (1579) wifi: Init lldesc rx ampdu len mblock:7 I (1581) wifi: Init lldesc rx ampdu entry mblock:4 I (1586) wifi: sleep disable I (2575) wifi: frc2_timer_task_hdl:3ffdc52c, prio:22, stack:2048 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ etc...This leads me to believe the issue is cause when the
pp_task_hdlandfrc2_timer_task_hdllines were swapped and slightly re-ordered. I can't find either of those lines in the pycom-micropython-sigfox repo, or the pycom-esp-idf repo, so I don't know what causes them, but maybe @daniel or @bucknall has a clue?
-
Oh, I meant what the program used. Sorry for being unclear.
-
@BluCode I just looked at the various URLs behind the version links and gave it a try.
-
@robert-hh Oh awesome! Thanks! By the way, how did you figure that out?
-
@BluCode I guess that these are the places. The upgrade tools fetches the software versions from the downgrade page. If on the downgrade page you hover over one of these image links, you''ll get an URL, like https://software.pycom.io/downloads/WiPy-1.6.0.b1.tar.gz
for version 1.6.0. You can enter these URL manually in the brwoser and modify the version number, which gives you access to all the interim versions between 1.6.0 and 1.6.12.
-
@robert-hh Is there a place I can get different versions of the firmware to test? All I can find is the old firmware from the downgrade page, the automatic upgrade tool, and the github.
-
@robert-hh Yes I am sure I used BOARD=WIPY for both.
-
@BluCode No, the most recent version of the code on github is 1.6.9b1, and I have that running here on an esp32 device (not WiPy, but Sparkfun esp32 thing, which is mostly compatible to WiPy), built from the sources.
I have a LoPy which runs the code too. I have no clue, about the difference between 1.6.0 and for instance 1.6.4 with respect to your devices behavior.
Are you sure, that when building your own image, you chose BOARD=WIPY and made both bootloader and app? That should not affect the automagic update, but the manual update does not check for the device type.
-
@robert-hh The version that worked was 1.6.0.b1, and I have tried 1.6.12.b1 and whatever version I built from https://github.com/pycom/pycom-micropython-sigfox as of 4/20/2017, which seems to be 1.6.9.b1. Is there a place (github) I can find the code for the most recent version (1.6.12.b1) or at least a more recent one? Also where can I find past firmware versions, so I can test? Al well I am willing to test flashing binaries, if anyone can tell me where to get them or send me one to test.
-
@BluCode Good to hear, that the board is fine. May I know which version worked, and which version you tried to build & upload? The 'most recent' version for own builds is here: https://github.com/pycom/pycom-micropython-sigfox
@daniel, @bucknalla : Have you any clue what is the for the problem?
-
I just built and tried to flash the latest firmware version, and got the same result as before. Do you have any ideas as to what could be causing the infinite loop?
-
Downgrading to an older version worked perfectly, thank you!
