Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    WiPy 2.0 not working after firmware update.

    Scheduled Pinned Locked Moved WiPy 2&3
    wipy 2.0firmware updatebug
    25 Posts 3 Posters 9.0k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • robert-hhR Offline
      robert-hh @BluCode
      last edited by

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

      B 1 Reply Last reply Reply Quote 0
      • B Offline
        BluCode @robert-hh
        last edited by

        @robert-hh Oh awesome! Thanks! By the way, how did you figure that out?

        robert-hhR 1 Reply Last reply Reply Quote 0
        • robert-hhR Offline
          robert-hh @BluCode
          last edited by

          @BluCode I just looked at the various URLs behind the version links and gave it a try.

          1 Reply Last reply Reply Quote 0
          • B Offline
            BluCode
            last edited by

            Oh, I meant what the program used. Sorry for being unclear.

            1 Reply Last reply Reply Quote 0
            • B Offline
              BluCode
              last edited by

              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_hdl and frc2_timer_task_hdl lines 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?

              B robert-hhR 2 Replies Last reply Reply Quote 0
              • B Offline
                bucknall @BluCode
                last edited by

                Hi @BluCode,

                We're aware of this issue and are looking into it.

                Cheers!

                Alex

                Developer Evangelist - Pycom

                B 1 Reply Last reply Reply Quote 0
                • B Offline
                  BluCode @bucknall
                  last edited by BluCode

                  @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
                  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
                  
                  1 Reply Last reply Reply Quote 0
                  • robert-hhR Offline
                    robert-hh @BluCode
                    last edited by robert-hh

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

                    B 2 Replies Last reply Reply Quote 0
                    • B Offline
                      BluCode @robert-hh
                      last edited by

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

                      1 Reply Last reply Reply Quote 0
                      • B Offline
                        BluCode @robert-hh
                        last edited by

                        @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-hhR 1 Reply Last reply Reply Quote 0
                        • robert-hhR Offline
                          robert-hh @BluCode
                          last edited by

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

                          B 1 Reply Last reply Reply Quote 0
                          • B Offline
                            BluCode @robert-hh
                            last edited by

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

                            1 Reply Last reply Reply Quote 0

                            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
                            • 1
                            • 2
                            • 2 / 2
                            • First post
                              Last post

                            Pycom on Twitter

                            Pycom