XM112 / XB112 - does not seem to answer commands
chmousset opened this issue · comments
Describe the bug
It is not possible to communicate with the XM112/XB112 combo.
The module does not seem to answer the serial commands.
To reproduce
- Following the update procedure from the manual, I put the device in bootloader mode using 'ERASE' and 'NRST' buttons.
- Using Bossa, flash
acc_module_server.bin
. "Erase All" and "Boot to FLASH". Successfull - Using Bossa again, click "Verify" to make sure flashing is OK (verify successful)
- Close Bossa.
- press "NRTS"
- run
python gui/main.py
- Select the right ttyUSB0 and push "connect"
Traceback
gui/main.py output from the UI:
Traceback (most recent call last):
File "/home/max/rn/acconeer/acconeer-python-exploration/gui/main.py", line 1601, in connect_to_server
info = self.client.connect()
File "/home/max/rn/acconeer/acconeer-python-exploration/src/acconeer/exptool/clients/base.py", line 36, in connect
info = self._connect()
File "/home/max/rn/acconeer/acconeer-python-exploration/src/acconeer/exptool/clients/reg/client.py", line 214, in _connect
raise ClientError("could not connect, no response")
acconeer.exptool.clients.base.ClientError: could not connect, no response
Environment (please complete the following information):
- Host OS: Manjaro, python 3.10.1 (same result with python 3.9.9)
- Acconeer hardware: XM112 + XC112
- Acconeer software version: 2.10.0 from https://developer.acconeer.com/download/acconeer_xm112_module_software_v2_10_0-zip/
- Exploration version: rss-v2.9.0-9-g2d4f5c0 (master 2d4f5c0)
Additional context
The documentation refers to file acc_module_server_xm112.bin
but is acc_module_server.bin
is distributed in acconeer_xm112_module_software_v2_10_0.zip
.
Result of pip freeze:
-e git+https://github.com/acconeer/acconeer-python-exploration.git@2d4f5c04647f647b94d25b709bd523d73d25652d#egg=acconeer_exptool
attrs==21.4.0
click==8.0.3
cycler==0.11.0
docutils==0.18.1
Flask==2.0.2
fonttools==4.28.5
h5py==3.6.0
itsdangerous==2.0.1
Jinja2==3.0.3
kiwisolver==1.3.2
MarkupSafe==2.0.1
matplotlib==3.5.1
NuMPI==0.3.0
numpy==1.22.1
packaging==21.3
Pillow==9.0.0
pyparsing==3.0.6
PyQt5==5.15.6
PyQt5-Qt5==5.15.2
PyQt5-sip==12.9.0
pyqtgraph==0.12.3
pyserial==3.5
python-dateutil==2.8.2
PyYAML==6.0
scipy==1.7.3
six==1.16.0
Werkzeug==2.0.2
Hi,
Thanks for the feedback on the documentation, we will update this.
Have you tried unplugging and plugging the module back in?
BR,
Anders
Hi Anders,
Have you tried unplugging and plugging the module back in?
Yes, I did try but it didn't solve the issue.
Hi,
Have you tried scanning the ports to see if any other ports appear?
If you unplugg the module and scan ports, does any ports appear?
Hello @chmousset ,
I am a bit curious regarding this issue.
In src/acconeer/exptool/clients/reg/client.py line 177 we make exceptions for the SerialLink depending if the OS is Windows or OSX. These exceptions have been needed in order to run UART on these operating systems.
Perhaps Manjaro does not handle the SerialProcessLink that is default for Linux.
if platform.system().lower() in ["windows", "darwin"]:
self._link = links.SerialLink(port)
else:
self._link = links.SerialProcessLink(port)
Try and remove the if statement and simply create the standard SerialLink.
I.e. self._link = links.SerialLink(port)
After changing this you need to reinstall the acconeer library using:
python -m pip install -U --user .
Does this help at all?
hi @vackraetraed ,
that was it!
Using I.e. self._link = links.SerialLink(port) did the trick. Now we can start evaluating the performances of this chip :)
diff --git a/src/acconeer/exptool/clients/reg/client.py b/src/acconeer/exptool/clients/reg/client.py
index 1eb2c22..54c47ba 100644
--- a/src/acconeer/exptool/clients/reg/client.py
+++ b/src/acconeer/exptool/clients/reg/client.py
@@ -174,10 +174,7 @@ class UARTClient(RegBaseClient):
self._streaming_control_val = "uart_streaming"
- if platform.system().lower() in ["windows", "darwin"]:
- self._link = links.SerialLink(port)
- else:
- self._link = links.SerialProcessLink(port)
+ self._link = links.SerialLink(port)
def _connect(self):
self._link.timeout = self.CONNECT_ROUTINE_TIMEOUT
It's the first time I've had any issues with Python serial
lib (and I've used it a lot). read()
and write()
'just works' and since that the buffering is done at the OS (or driver) level I never had to worry about polling rate.
What exactly forced you handling the serial link in a seperate thread? Buffer overruns?
Hello @chmousset
I talked a little bit with Erik who wrote the code and he confirmed that it was buffer overruns which forced handling it in a daemon process.
This is for sure an issue that we may need to discuss on how to handle buffer overflows and different types of OS in the future.
But for now I suggest you continue using the code for SerialLink as long as it works for you.