WiPy 2.0 not working after firmware update.
-
@BluCode The messages you show are the one sent when the device wait for the download, as if P2 is still tied to GND.
-
I already tried that, again to no avail. Exact same issue. Also it seems i copy/pasted too much, I will edit my post to reflect what the actual output was (that was from testing if it would boot with P2 to ground). Also how do I earn the reputation needed to post more than once any 10 minutes? It is annoying to be forced to wait to reply.
-
@BluCode People have to upvote your post.
-
@BluCode You could try to install an older version using the downgrade procedure https://forum.pycom.io/topic/517/downgrading-firmware-advanced-users/15.
The images there are quite old, but ifyou look at the URLs of these images,you can easily guess for instance the name for image 1.6.9b1.
But there no complaints like yours so far with version 1.6.12. -
Downgrading to an older version worked perfectly, thank you!
-
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?
-
@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? -
@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 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 Yes I am sure I used BOARD=WIPY for both.
-
@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.
-
@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 Oh awesome! Thanks! By the way, how did you figure that out?
-
@BluCode I just looked at the various URLs behind the version links and gave it a try.
-
Oh, I meant what the program used. Sorry for being unclear.
-
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? -
-
@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 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ -
@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. -
@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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login