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

    failed to set dtr/rts

    Scheduled Pinned Locked Moved Issues & Bugs
    lopypysensepymakr
    25 Posts 6 Posters 17.3k Views 6 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.
    • G Offline
      g0hww @g0hww
      last edited by

      I got someone else with a Windows PC to try it, and it seemed to be working for him. I laughed when he used Labview to decide whether or not it was working :)

      After I googled around a bit, I stumbled across hints that rebooting the host might resolve it, so I did and it is now connecting again via the USB UART on the pytrack board. I've just been able to sync the 3 libs across and still have the REPL up. Will post back if there are other developments.

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

        This is still giving me grief. My first lopy is on a pytrack board, and I now find that I can never sync it without first running os.mkfs('/flash'), otherwise i get these errors:

        "Synchronizing failed: Write failed. Please reboot your device manually."

        That means that i then have to sync again using the USB UART. As the CDC ACM device on the PyTrack doesn't work properly with my Linux kernel (see above), I have to temporarily borrow the ExpBrd2 from my other lopy in order to sync with it using the FTDI USB UART. This makes it hard to debug code specifcally written for the pytrack!

        It also sounds like my first lopy's /flash is worn out after a couple of weeks! Is this possible? What else might cause this sudden inability to reprogram it over telnet?

        1 Reply Last reply Reply Quote 0
        • on4aaO Offline
          on4aa
          last edited by

          I am having exactly the same issue on Ubuntu 16.04 LTS with Linux kernel 4.4.0-104-generic.

          [ 4839.468011] usb 1-7.2: new full-speed USB device number 13 using ehci-pci
          [ 4839.562840] usb 1-7.2: New USB device found, idVendor=04d8, idProduct=f013
          [ 4839.562842] usb 1-7.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
          [ 4839.562844] usb 1-7.2: Product: Pytrack
          [ 4839.562846] usb 1-7.2: Manufacturer: Pycom
          [ 4839.562847] usb 1-7.2: SerialNumber: Py343434
          [ 4839.564381] cdc_acm 1-7.2:1.0: ttyACM0: USB ACM device
          [ 4839.604727] cdc_acm 1-7.2:1.0: failed to set dtr/rts
          [ 4841.039182] TCP: request_sock_TCP: Possible SYN flooding on port 46233. Sending cookies.  Check SNMP counters.
          

          The TCP SYN flooding seems to coincide with the failed to set dtr/rts. The port number changes with every attempt. I hope it is no Chinese malware that sneaked its way into my new LoPy PyTrack & LoPy PySense devices!

          A Pycom bug report has been opened for this issue.

          on4aaO 1 Reply Last reply Reply Quote 0
          • on4aaO Offline
            on4aa @on4aa
            last edited by

            I also tried disabling the Modem Manager service as this has been seen to interfere with other development boards. It did not cure the problem, though.

            $ sudo systemctl disable ModemManager.service
            
            1 Reply Last reply Reply Quote 0
            • on4aaO Offline
              on4aa
              last edited by

              I made some progress. ModemManager is part of the problem as Pycom devices are not blacklisted in the following file:

              $ less /lib/udev/rules.d/77-mm-usb-device-blacklist.rules
              

              Editing this file is of no use since it will be overwritten with any update.
              One may file a bug report against ModemManager to have Pycom devices added to this system file.

              User device rules reside in /etc/udev/rules.d/. These device rule files take precedence over those located in /lib/udev/rules.d/ if their name is identical.

              Hence, a file under a different name was created, namely 77-mm-pycom.rules:

              $ sudo vim /etc/udev/rules.d/77-mm-pycom.rules
              

              which contains the following rule:

              # All devices from Pycom LTD
              ATTRS{idVendor}=="04d8", ENV{ID_MM_DEVICE_IGNORE}="1"
              

              If only the most recent Pysense devices are to be blacklisted, use:

              # Pycom Pysense
              ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="f012", ENV{ID_MM_DEVICE_IGNORE}="1"
              

              Similarly for the most recent Pytrack devices:

              # Pycom Pytrack
              ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="f013", ENV{ID_MM_DEVICE_IGNORE}="1"
              

              I do not own any other or earlier version expansion boards. These will undoubtedly carry another idProduct. Since Pycom is not producing any modems, it is safe to blacklist all Pycom LTD devices.

              RESULT
              Upon device connection, there is no longer a failed to set dtr/rts error in the dmesg listing.
              However, it reappears there when attempting a ./update, which still fails.
              The TCP: request_sock_TCP: Possible SYN flooding on port nnnnn. Sending cookies. Check SNMP counters. still appears in dmesg at device connection.

              CONCLUSION
              ModemManager was part of the problem. There is still another unresolved issue.

              PS: I find it hard to believe there are so few people developing on Pycom with Ubuntu.

              on4aaO 1 Reply Last reply Reply Quote 0
              • on4aaO Offline
                on4aa @on4aa
                last edited by

                In the ./update script, the error occurs at get_wmac.

                Manually running ./updater.py results in:

                $ ./updater.py --port "/dev/ttyACM0" --speed 115200 wmac
                Connecting...
                Exception: [Errno 32] Broken pipe, on line 161
                
                on4aaO 1 Reply Last reply Reply Quote 0
                • on4aaO Offline
                  on4aa @on4aa
                  last edited by

                  The same issue seems to affect any attempt to upgrade the firmware of the Pysense or Pytrack itself (instead of the plugged in LoPy): dfu-util: Cannot open DFU device 04d8:f014

                  dfu-util -D pytrack_0.0.8.dfu 
                  dfu-util 0.8
                  
                  Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
                  Copyright 2010-2014 Tormod Volden and Stefan Schmidt
                  This program is Free Software and has ABSOLUTELY NO WARRANTY
                  Please report bugs to dfu-util@lists.gnumonks.org
                  
                  Match vendor ID from file: 04d8
                  Match product ID from file: f014
                  dfu-util: Cannot open DFU device 04d8:f014
                  dfu-util: No DFU capable USB device available
                  
                  on4aaO 1 Reply Last reply Reply Quote 0
                  • on4aaO Offline
                    on4aa @on4aa
                    last edited by

                    (LoPy) module updates via the Pysense or Pytrack board is neither currently possible with other GNU/Linux distributions; for example Manjaro XFCE, which I tried.

                    From what I am reading, GNU/Linux users can only install module firmware upgrades using the ordinary Expansion board, which I currently do not own.

                    L 1 Reply Last reply Reply Quote 0
                    • L Offline
                      livius @on4aa
                      last edited by livius

                      @on4aa

                      can only install module firmware upgrades using the ordinary Expansion board,

                      And also by any 3V3 UART/TTL converter

                      think about people first, then computers

                      1 Reply Last reply Reply Quote 0
                      • X Offline
                        Xykon administrators
                        last edited by

                        It should also be possible to upgrade the esp32 firmware using the Pytrack / Pysense by disabling high speed transfer and connecting a jumper wire between Pin 1 and Pin 5 on the external IO header.

                        We're planning to release a new firmware update tool today (or very shortly) that will support updating via Pysense / Pytrack using high speed transfer and without needing a jumper wire.

                        This should work on all operating systems when using the GUI version of the firmware update tool. This will not initially work with the dialog based cli updater that is included in the Linux version of the firmware update tool, but I will post some workaround instructions when the software is released.

                        Christian Ehlers

                        on4aaO 2 Replies Last reply Reply Quote 0
                        • on4aaO Offline
                          on4aa @Xykon
                          last edited by

                          @xykon

                          I could update the firmware of the Pysense & Pytrack boards, but still no luck with the ESP32 firmware.

                          $ sudo dfu-util -D pysense_0.0.8.dfu
                          $ sudo dfu-util -D pytrack_0.0.8.dfu
                          

                          The sudo should be added to the documentation.

                          X 1 Reply Last reply Reply Quote 1
                          • on4aaO Offline
                            on4aa @Xykon
                            last edited by

                            @xykon
                            At last, success! The ESP32 firmware update (GUI-version) succeeded now, after creating /etc/udev/rules.d/77-mm-pycom.rules containing:

                            # All devices from Pycom LTD
                            # Since Pycom is not producing any modems, it is safe to blacklist all Pycom LTD devices.
                            ATTRS{idVendor}=="04d8", ENV{ID_MM_DEVICE_IGNORE}="1"
                            

                            and rebooting! (I probably forgot to do so late last night.)

                            I am not sure whether first upgrading the firmware of the Pysense or Pytrack board with sudo dfu-util is a necessary preceding step, but that is what I did first.

                            Anyhow, I filed a ModemManager bug report so that fellow Pycom developers on GNU/Linux will no longer be bothered with this issue in the future.

                            J 1 Reply Last reply Reply Quote 2
                            • J Offline
                              jmarcelino @on4aa
                              last edited by jmarcelino

                              @on4aa
                              Hi,

                              Thanks a lot for your investigation but I have to say 0x04d8 is Microchip's vendor ID (Pycom uses a Microchip PIC micro for the USB-serial interface and we sublicense their VID) so it's probably unwise to add it as a general rule for all ModemManager installs.

                              on4aaO 2 Replies Last reply Reply Quote 2
                              • X Offline
                                Xykon administrators @on4aa
                                last edited by

                                @on4aa said in failed to set dtr/rts:

                                I could update the firmware of the Pysense & Pytrack boards, but still no luck with the ESP32 firmware.

                                $ sudo dfu-util -D pysense_0.0.8.dfu
                                $ sudo dfu-util -D pytrack_0.0.8.dfu
                                

                                The sudo should be added to the documentation.

                                A better solution is to use sudo usermod -a -G dialout $USER once and then logout or reboot your PC. Then you can use dfu-util without sudo.

                                I will make sure this gets added to the documentation.

                                Christian Ehlers

                                on4aaO 1 Reply Last reply Reply Quote 1
                                • on4aaO Offline
                                  on4aa @jmarcelino
                                  last edited by

                                  @jmarcelino
                                  Well, then a list of all of Pycom's current (and planned?) idProduct values is needed. See examples below.
                                  Any future additions will have to be reported to freedesktop.org ModemManager maintainers.

                                  1 Reply Last reply Reply Quote 2
                                  • on4aaO Offline
                                    on4aa @Xykon
                                    last edited by

                                    @xykon Oddly enough, I have been a member of the dialout group long before this. This is why it also surprised me.

                                    Either the python script is not getting full privileges or I was not trained at the beginning with pressing the buttons. This needs more testing.

                                    PS: A reputation point or so is more than welcome. As a newbee I have nada ;-)

                                    1 Reply Last reply Reply Quote 2
                                    • on4aaO Offline
                                      on4aa @jmarcelino
                                      last edited by

                                      @jmarcelino The ModemManager bug report has been amended for the Pysense & Pytrack; which is all I have.

                                      Can some good soul look up the idVendor and idProduct for the other boards (Expansionboard v1&2 etc.)?
                                      Doing so allows the ModemManager maintainers to be correctly informed.

                                      @xykon Today's new pycom_firmware_update_1.1.4.b1 GUI updater also works flawlessly!

                                      PS: Reputation points, please, I have to wait 10 minutes between every post…

                                      J 1 Reply Last reply Reply Quote 3
                                      • J Offline
                                        jmarcelino @on4aa
                                        last edited by

                                        @on4aa
                                        Thanks a lot! That should cover all the current boards - the Expansion board (v1,v2) is based on the super popular FTDI USB-Serial chip - it's not PIC based - so it should have no problem.

                                        I'll make a note to submit new IDs to ModemManager as new products arise.

                                        on4aaO 1 Reply Last reply Reply Quote 0
                                        • on4aaO Offline
                                          on4aa @jmarcelino
                                          last edited by

                                          @jmarcelino Because of the Microchip VID sublicensing, it will be not always clear if Pycom products are being dealt with. For this reason, the ModemManager maintainer has added the Pysense and Pytrack rules to 77-mm-usb-serial-adapters-greylist.rules.

                                          Neither is this bad, because ModemManager will try to make a connection only when run manually. Automatic annoyances will be a thing of the past over a month of 2­—3, when the ModemManager updates will roll into stable GNU/Linux releases.

                                          1 Reply Last reply Reply Quote 0
                                          • on4aaO Offline
                                            on4aa
                                            last edited by

                                            What Removed Added
                                            Resolution --- FIXED
                                            Status REOPENED RESOLVED

                                            Comment # 5 on bug 104320 from Aleksander Morgado

                                            I've pushed the 2 blacklisted devices with rules including vid:pid, but I've
                                            also added the whole vid to the "usb adapters greylist", which are only probed
                                            if manually requested to do so, so should help to avoid interference with other
                                            Microchip-vid-tagged devices.

                                            https://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=c2b956aefce495865cbdcb9971e2b3cd99cd0e99

                                            All fine & dandy in the end…

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

                                            Pycom on Twitter

                                            Pycom