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

    Flash problem

    Scheduled Pinned Locked Moved GPy
    7 Posts 4 Posters 79 Views 4 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.
    • K Offline
      kjm
      last edited by

      The gpy we're developing some code started to behave erratically, mostly locking up when we tried to run the program from Atom. So we did a full flash erase from the windows cmd prompt

      C:\Program Files (x86)\Pycom\Pycom Firmware Update>pycom-fwtool-cli.exe -p COM3 erase_all
      Running in FTDI mode
      Erasing the board can take up to 40 seconds.
      Board erased successfully in 14.1 seconds
      

      then reloaded the firmware with the Pycom firmware updater. But we seem to have gone from the frying pan to the fire, because now we can't download our code

      Reading file status
       Failed to read project status, uploading all files
      [1/1] Writing file boot.py (50kb)
      import ubinascii
       � Failed to write file, trying again...
      import ubinascii
      >>> f = open('boot.py', 'wb')
      >>> f.write( 
      NameError: name 'f' isn't defined� Failed to write file, trying again...
      import ubinascii
      >>> f = open('boot.py', 'wb')
       f.write(ubinascii.a2b_base64('IyAyMTA5c21zRnJvc3Rzb2wucHkgc2VuZHMgYWxhcm1zIGFzIGxvbmcgYXMgdGVtcGVyYXR1cmUga2VlcHMgZmFsbGluZw0KIyBfc2V0UlRDICYgc2VuZCBzcyB0byB1c3JzIG9uIHB3cnVwIG9yIHdkdA0KIyAxNSBtaW4gd2FrZXVwIGNoZWNrIGZv�ets Jun  8 2016 00:22:57
      

      We've not encountered this behaviour before, anybody know what to try next?

      1 Reply Last reply Reply Quote 0
      • G Offline
        Gijs
        last edited by

        @kjm Does this happen consistently?
        It looks like something went wrong when referencing the global f (where the NameError comes from). I was not able to reference the second part of the errormessage Failed to write file, trying again... in the firmware, is that part of the Pymakr output perhaps? It seems like you're able to access the REPL while Pymakr is not done yet..

        Could you try os.listdir() to see the files in the current directory, perhaps that could give an indication.

        Let me know!

        K 2 Replies Last reply Reply Quote 0
        • E Offline
          Elizar
          last edited by

          Did You format the filesystem after flashing the system? Maybe the filesystem is in an inconsistent state that causes write operations to fail.

          Try uos.mkfs("/flash") on the command line. [Attention! You will loose all previous data on /flash]. Then upload Your files again.

          1 Reply Last reply Reply Quote 0
          • K Offline
            kjm @Gijs
            last edited by kjm

            @Gijs The listdir looks normal to me ['boot.py', 'cert', 'lib', 'main.py', 'sys']
            After we tried os.fsformat('/flash') the listdir output changed to ['boot.py', 'cert', 'lib', 'main.py', 'project.pymakr', 'sys']

            1 Reply Last reply Reply Quote 0
            • K Offline
              kjm @Gijs
              last edited by kjm

              @Elizar Since we're running LittleFS we tried import os; os.fsformat('/flash')

              Reading file status
              Failed to read project status, uploading all files
              Creating dir lib
              [1/1] Writing file lib/onewire.py (8kb)
              � 
              NameError: name 'f' isn't defin Failed to write file, trying again...
              import ubinascii
              >>> f = open('lib/onewire.py', 'wb')
               
              NameError: name 'f' isn't defined
              � Failed to write file, trying again...
              import ubinascii
              >>> f = open('lib/onewire.py', 'wb')
              � 
              NameError: name 'f' isn't defined
              >>� Failed to write file: 
               f = open('project.pymakr', 'wb')
               
              PYB: soft reboot
              Pycom MicroPython 1.20.1.r1 [15b6d69] on 2019-11-02; GPy with ESP32
              Type "help()" for more information.
              >>>  
              PYB: soft reboot
              Pycom MicroPython 1.20.1.r1 [15b6d69] on 2019-11-02; GPy with ESP32
              Type "help()" for more information.
              >>>  with open('project.pymakr', 'rb') as f:
              ...       while True:
              ...             c = f.read(512)
              ...                 if not c:
              ...                            break
              ...                             hash.update(c)
              ...                             sys.stdout.write(ubinascii.hexlify(hash.digest()))
              ...                             
              ...                             
              ...  
              PYB: soft reboot
              Pycom MicroPython 1.20.1.r1 [15b6d69] on 2019-11-02; GPy with ESP32
              Type "help()" for more information.
              >>> Upload failed: Filecheck failed. Please reboot your device manually.
              import machine
              >>> machine.reset()
              ets Jun  8 2016 00:22:57
              

              Getting the feeling this particular gpy isn't coming back.

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

                @kjm You could try the sledgehammer approach and do a full flash erase with esptool.py. That will also remove any flasg and setting that Pycom firmware stores to the flash and will not be overwritten by the Pycom updater. After that, you have to restore the firmware using the pycom online firmware updater, resulting in a device with full factory reset.-
                If then the boards fails, the board has probably a hardware defect.

                K 1 Reply Last reply Reply Quote 1
                • K Offline
                  kjm @robert-hh
                  last edited by

                  @robert-hh Replaced the usb cable & all good now Rob. Why this particular gpy won't work with the replaced cable when all the others do is a bit of a mystery, the current looks the same, the voltage trace on the CRO looks the same, must be some subtlety there I can't measure that prevented it from running/uploading from the repl.

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

                  Pycom on Twitter

                  Pycom