Pymakr does not connect to LoPy using WiFi

[robert-hh]

Pymakr does not connect to a lopy device using a telnet address. It shows the welcome message once, and then goes silent. Telnet works.

[Ralph]

hi @robert-hh, @Frida, After robert posted his response here an hour ago, I went on to do some tests and found that a telnet session (from terminal) indeed gets stuck after a soft reboot. The same thing over serial works fine. It happens on the latest firmware versions of both the lopy and wipy2. So it's definitely a but on the firmware side. Since Pymakr is sending soft reboots on connect, this is causing the connection issue with a lot of people. We'll try to find a solution asap.

We started reporting the issues on github. You can find and subscribe to update for this issue here

[Frida]

On serial it works ok, but on wifi I get:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/share/pymakr/modules/Plugins/PycomDevice/pyboard.py", line 110, in on_timer
    callback()
  File "/usr/share/pymakr/modules/Plugins/PycomDevice/pyboard.py", line 446, in _keep_alive
    self.__disconnected_callback(Pyboard.LOST_CONNECTION)
AttributeError: Pyboard instance has no attribute '_Pyboard__disconnected_callback''

on latest software

[robert-hh]

Hello @PatSenn and @Roberto, I do not get this message because:

a) I modified the file pyboard.py of pymakr (/usr/share/pymakr/modules/Plugins/PycomDevice/pyboard.py) in the telnet section at about line 290, such that the function keep_alive() always returns True. That allows a WiPy 1 with the recent firmware form the micropython site to deal with pymakr. It does not help with lopy, but may suppress the error message others receive (just the message).
b) Since pymakr is using a telnet session, I'm testing with a simple telnet client. You may use the command line telnet version or for instance putty. That is a simple and robust set-up. pymakr may have it's own bugs too.

[PatSenn]

I just tested it. I can attach through the COM port, but if I try 192.168.4.1, then I get "error communicating". If I hit reset and then try 192.168.4.1, it attaches for a moment then it gives "QStackedWidget::setCurrentWidget: widget 0x6a0a1e0 not contained in stack" followed by "error communicating.

[robert-hh]

Hello @roberto,
I tried this firmware already yesterday evening, when it was published. While it fixes the ftp issue, it does not fix the telnet issue. Telnet works until I push Ctrl.D for soft reset, the same pymakr does. After that, input to lopy is locked, but the output from lopy is still received. Closing telnet does not close the session, so I have to reset lopy.
Regards, Robert

[AgriKinetics]

@ralph Hi, our LoPy's connect over WiFi with PyMakr and 1.9.4.b1 without any issue until the 'Stacked Widget' error message appears in PyMakr. After that it seems to disconnect and refuse to reconnect again.

[Roberto]

Hi @robert-hh,

We released a new firmware version today that might help you with your problem since it includes several stability updates.
Please download it at
https://www.pycom.io/support/supportdownloads/
and follow the instructions

Best,
Roberto

[robert-hh]

I do not know what you want to tell me.
If I start a session in Telnet, and then issue soft reset, the telnet session simply stalls. I guess
that is what happens with pymakr. An here is in my boot.py:

# boot.py -- run on boot-up
import os
from machine import UART
uart = UART(0, 115200)
os.dupterm(uart)

What should I change or add?
Update: Interestingly, it's the input to the device which get's locked. The output from lopy is still delivered.

[Ralph]

Hi @robert-hh, @PatSenn,

Do the two of you have any wifi connection code in the boot.py? You might have the same issue as in this topic, where I posted the solution (second response).

Let me know if that solves it or if the problem remains.

[PatSenn]

I am experiencing the same problem. I am currently attached thru the USB and have been for 5 hours. The default WiFi address either connects and immediately drops out, or it never connects at all.