Pysense issues

[cbnatrix]

(sysname='WiPy', nodename='WiPy', release='1.8.0.b1', version='v1.8.6-760-g90b72952 on 2017-09-01', machine='WiPy with ESP32')
WiPy 2.0
Pysense firmware updated to 0.0.4, board v1.0
I synced the pysense software using pymakr and the WiPy in the expansion dock as syncing was erratic when the WiPy is in the Pysense dock.
When booting in the Pysense dock I get:

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff9010,len:12
ho 0 tail 12 room 4
load:0x3fff9020,len:388
load:0x40078000,len:11584
load:0x4009fb00,len:848
entry 0x4009fc9c
Hello from playtime/boot
Hello from playtime/main
MicroPython v1.8.6-760-g90b72952 on 2017-09-01; WiPy with ESP32
Type "help()" for more information.

(boot.py and main.py each contain only a simple print statement)

At this point the behavior is unpredictable. Sometimes I can interact with the REPL, mostly not. If I can and import pysense, it becomes unresponsive.

This is being done on an 11 inch Macbook Air using CoolTerm for interactions with the REPL. I have no issues at all when the WiPy is in the expansion doc. I suspect that the Pysense board is defective.

[g0hww]

I have a similar problem with a Lopy on a PyTrack board, and I'm using Linux. There is a forum topic here about the problem:
https://forum.pycom.io/topic/1418/failed-to-set-dtr-rts

Whilst there is info online about similar issues with other entirely unrelated hardware, the solutions that others propose as fixes for their experiences are trivial (typically the removal of the dreaded "ModemManager" package) and do not apply in my case. There is no evidence to suggest that it is actually a Linux kernel bug at this time. My Arduino Uno has the same kind of USB UART device as the PyTrack but functions without issues using the same Linux kernel driver.

When push comes to shove, I can gain temporary respite by rebooting my Linux box (with the Lopy/PyTrack unplugged), then plug in the USB cable to the PyTrack when I'm ready to sync some code. It seems to work for long enough to achieve results, but will probably not work after cycling the USB connection, etc. This is not really a viable workaround.

As a result, I've learned to ensure that I can almost always "operate" the Lopy/Pytrack exclusively over telnet/FTP and not use the PyTrack's USB UART unless I really have to. I haven't had the PyTrack long enough to have had to update it's firmware since the first time, so I don't know what will happen when I try that again.

Sorry if this entirely unrelated, but it seems as if the symptoms are the same. It is my understanding that the USB UARTs on the PyTrack and PySense are the same, and use the same drivers. The USB UART on the Exp. Board2 is different and doesn't manifest the same problem. Like cbnatrix, my Lopy/ExpBrd2 functions perfectly when attached via USB.

Here using Ubuntu 16.04 LTS for x86_64 on kernel 4.10.0-33.

[stroobandt]

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!

[stroobandt]

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 

[stroobandt]

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.

[stroobandt]

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

[stroobandt]

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

[stroobandt]

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

[g0hww]

@stroobandt
I recently updated the firmware on my PyTrack and LoPys, which had been not used for a couple of months. My Linux box had been freshly rebooted, so I hoped that I'd be able to update the PyTrack FW before the RTS issue manifested itself. Fortunately, I was able to update the PyTrack FW without issue, and then proceeded to update the LoPy on the PyTrack, and then the LoPy on the ExpBrd2.
Since then I have not had any issues with serial connectivity to the LoPy/PyTrack although to be fair, I tend to connect to it over telnet & FTP. I had begun to wonder if the new PyTrack FW fixed this issue, or if some changes in the Atom plugin had fixed it.

I have just hooked it up to my Linux box again and confirmed that I have had no further RTS issues after cycling the USB connection a few times. I can still connect to the LoPy/PyTrack on /dev/ttyACM0 and update its code with no apparent issues.

On the matter of ModemManager, I can confirm that it was not installed on my machine when I started experiencing the RTS issue, as I have learned from bitter experience that it can do bad things to serial attached devices that are having their FW updated, so I uninstall it ASAP after bringing up a new Linux box.

Regarding your SYN flood issue, I see no sign of that here with my pair of LoPys. They are both hooked up to my WLAN and have connections open to the MQTT broker on this Linux box. Have you inspected the headers of the SYN packets in WireShark to see what their source address is? Note that SYN floods would typically have spoofed source IP addresses anyway.

[g0hww]

I forgot to mention that I had to retry the DFU Update on the PyTrack a couple of times when I updated its FW. I had the same experience with the initial FW update too some months back. I suspect that it is just quite difficult to hold down the tiny button when inserting the micro-USB cable without releasing the button by accident.

[stroobandt]

Placing the .dfu file in my home directory (instead of my file server) and running dfu-util with sudo finally allowed me to update the Pysense and Pytrack 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.

Now, I am only half way. Let's see if I can get the module firmware to update.

[stroobandt]

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.

This issue may be closed.