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

    Firmware release 1.7.1.b1

    Scheduled Pinned Locked Moved Announcements & News
    firmware
    73 Posts 12 Posters 39.3k Views 12 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 @Innocenzo
      last edited by robert-hh

      @Innocenzo I had the same trouble (see my posts below): After using the updater tool once, you have to erase the flash BEFORE you use you load youe own-built firmware. You can do that with:

      make erase

      HOWEVER, after doing that, the board does not run boot.py or main.py any more. It considers itself in the safeboot mode. This is a software fault.
      I'm interested if that happes to you too? If yes, you could still call boot.py and main.py from frozen/_boot.py, which is called always.

      I 1 Reply Last reply Reply Quote 1
      • I Offline
        Innocenzo @daniel
        last edited by

        @daniel said in Firmware release 1.7.1.b1:

        @Innocenzo have you rebuilt the bootloader? The command is erase instead of flash

        yes.

        • I have erased the old repository ;
        • I have downloaded the new pycom-micropython-sigfox and pycom-esp-idf;
        • git submodule update --init in all repository
        • in pycom-micropython-sigfox/mpy-cross make all
        • in pycom-micropython-sigfox/esp32:
        • make BOARD=WIPY TARGET=boot;
        • make BOARD=WIPY TARGET=app;
        • make BOARD=WIPY flash.
        robert-hhR 1 Reply Last reply Reply Quote 0
        • I Offline
          Innocenzo @robert-hh
          last edited by

          @robert-hh Yes. The boot.py and the main.py present in /flash/ dir, do not start after flashing my own firmware.

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

            @Innocenzo Before the step:
            make BOARD=WIPY flash
            you have to do:
            make BOARD=WIPY erase
            In order to erase the flash memory on the device. Obviously, all content on the device will be lost!

            I 1 Reply Last reply Reply Quote 1
            • I Offline
              Innocenzo @robert-hh
              last edited by

              @robert-hh Yes. I do it and now I can flash my own firmware, but the file main.py and boot.py do not start "on boot".

              robert-hhR 1 Reply Last reply Reply Quote 1
              • D Offline
                daniel
                last edited by

                Issue with the safeboot fixed here: https://github.com/pycom/pycom-micropython-sigfox/commit/f29075e4b0a1f713af1d2579465ffd35e360eb12

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

                  This post is deleted!
                  1 Reply Last reply Reply Quote 0
                  • robert-hhR Offline
                    robert-hh @daniel
                    last edited by

                    @daniel Thanks. That looks like the right place. I cannot check it before this evening, by innocenzo may do so.

                    I 1 Reply Last reply Reply Quote 1
                    • T Offline
                      this.wiederkehr @this.wiederkehr
                      last edited by

                      @daniel: Any ideas why I get those LoadProhibited exceptions? Any hint where I should start searching. I'm just lost on these ...
                      The first two seem very low level which makes me wonder .... the third might be related to the issue with ntp_sync.

                      1 Reply Last reply Reply Quote 0
                      • D Offline
                        daniel
                        last edited by

                        @this.wiederkehr we are investigating this now.

                        1 Reply Last reply Reply Quote 0
                        • I Offline
                          Innocenzo @robert-hh
                          last edited by

                          @robert-hh I check it. Now It works.

                          1 Reply Last reply Reply Quote 0
                          • D Offline
                            daniel
                            last edited by

                            @this-wiederkehr this:

                            import machine
                            import os
                            
                            sd = machine.SD()
                            os.mount(sd, '/sd')
                            
                            f = open('/sd/test', 'a')
                            
                            while True:
                                f.write('blabla')
                                print('about to disable irq')
                                machine.disable_irq()
                                print('about to flush to file')
                                f.flush() # <-- freezes reproducible at that call
                                print('about to enable irq')
                                machine.enable_irq()
                                print("I'm done")
                            

                            is expected to freeze as the SD card uses interrupts. If you disable them before flushing the SD card driver stays waiting for the operation to finish, which never happens as the interrupt doesn't trigger.

                            Still working on the other crash...

                            Cheers,
                            Daniel

                            T 1 Reply Last reply Reply Quote 0
                            • R Offline
                              rdixey @daniel
                              last edited by

                              @daniel Does the current updater tool for release LoPy_868-1.7.1.b2.tar.gz incorporate the fix for the ntp_sync issue?

                              I want to be sure before installing the update. Please confirm.

                              1 Reply Last reply Reply Quote 0
                              • D Offline
                                daniel
                                last edited by

                                @rdixey no, that fix is not out yet. The release will be out tomorrow together with other fixes and new features (like the WDT).

                                I 1 Reply Last reply Reply Quote 2
                                • P Offline
                                  peekay123
                                  last edited by

                                  When I ran the Firmware Udpater last night, it installed 1.7.1.b2 (on LoPy) which still has the ntp_sync issue. I also noticed that rtc.local(), which worked on 1.6.7.b1, no longer works on 1.7.1.b2. The following no longer runs (from my boot.py file):

                                  # We are here because wifi connected so set the RTC time
                                  from machine import RTC
                                  
                                  rtc = machine.RTC()
                                  rtc.ntp_sync("pool.ntp.org")
                                  utime.sleep_ms(750)
                                  time.timezone(-14400)
                                  print(rtc.local())
                                  
                                  1 Reply Last reply Reply Quote 0
                                  • I Offline
                                    Innocenzo @daniel
                                    last edited by

                                    @daniel I've found some other bugs in this release:

                                    • the disconnect() function of the Bluetooth class does not work!
                                    bt = Bluetooth()
                                    conn = bt.connect(b'\x00\x15\x83\x00\x4A\x67')
                                    services = conn.services()
                                    for service in services:
                                        time.sleep(0.050)
                                        if type(service.uuid()) == bytes:
                                            print('Reading chars from service = {}'.format(service.uuid()))
                                        else:
                                            print('Reading chars from service = %x' % service.uuid())
                                        chars = service.characteristics()
                                        for char in chars:
                                            if (char.properties() & Bluetooth.PROP_READ):
                                                print('char {} value = {}'.format(char.uuid(), char.read()))
                                    conn.disconnect()
                                    

                                    the WiPy returns in REPL, but the BLE peripheral does not detect the disconnect (the peripheral remains cennected to WiPy and cannot be detected by other devices).

                                    • The ssl socket server side causes a core dump or throws an exception!
                                    newsocket, fromaddr = bindsocket.accept()
                                    connstream = ssl.wrap_socket(newsocket,server_side=True, certfile='/flash/cert/cert.pem', keyfile='/flash/cert/key.pem')
                                    
                                    1 Reply Last reply Reply Quote 0
                                    • D Offline
                                      daniel
                                      last edited by

                                      @peekay123 I guess that you mean: time.localtime() this is related to the same ntp sync issue which has already been solved internally. Thanks.

                                      P 1 Reply Last reply Reply Quote 0
                                      • P Offline
                                        peekay123 @daniel
                                        last edited by peekay123

                                        @daniel, rtc.local() worked fine before. However, I'll use time.localtime() in the future.

                                        1 Reply Last reply Reply Quote 0
                                        • T Offline
                                          this.wiederkehr @daniel
                                          last edited by this.wiederkehr

                                          Thanks @daniel for letting me know. Is this behavior documented somewhere. It's not basically what I would expect ;-)

                                          Here is a script to reproduce the crash. I could reproduce the crash on address 0x40087eb9 with it. Though, it does not trigger on the first instance but you might have to run it for several minutes till the exception occurs. I'll try further and see if it also triggers the other exceptions I got...

                                          import machine
                                          import os
                                          import utime
                                          
                                          sd = machine.SD()
                                          os.mount(sd, '/sd')
                                          
                                          f = open('/sd/test', 'a')
                                          t1 = utime.ticks_ms()
                                          while True:
                                          
                                              print('about to initialize buffer')
                                              k = bytearray(1024)
                                              print('about to write to file')
                                              f.write(k)
                                              print('about to flush to file')
                                              f.flush()
                                              t2 = utime.ticks_ms()
                                              print("I'm done %i"%(t2-t1))
                                              t1 = t2
                                          
                                          

                                          Update: Yes, this also triggers the other exception at address 0x400875b9.
                                          Update2: It also reproduces the freeze or at least I can see a slow down of the python interpreter by factors. I just see cycle times which are usually in the range of 10 - 500 ms (500 most likely during gc) going up to ~20000 or even 30000.

                                          Let me know if you can reproduce those issues...

                                          1 Reply Last reply Reply Quote 0
                                          • S Offline
                                            sthomson
                                            last edited by

                                            Hi,
                                            I have used the updater tool to flash 1.7.1.b2 to my LoPy board. I am running the following:

                                            wlan = network.WLAN(mode=network.WLAN.STA)
                                            wlan.connect(ap.ssid, (ap.sec, mypassword))
                                                while not wlan.isconnected():
                                                    machine.idle() # save power while waiting
                                            

                                            This was working without problems with the previous firmware (1.6.7.something), but now it is stuck in the machine.idle() loop and never seems to connect. Is this related to one of the bugs discussed here?

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

                                            Pycom on Twitter

                                            Pycom