XM112 / XB112 - does not seem to answer commands

Question

XM112 / XB112 - does not seem to answer commands

chmousset opened this issue 3 years ago · 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

Screenshots

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

AndersBuhl · Answer 1 · Mon Jan 17 2022 16:54:51 GMT+0800 (China Standard Time)

Hi,

Thanks for the feedback on the documentation, we will update this.

Have you tried unplugging and plugging the module back in?

BR,
Anders

chmousset · Answer 2 · Tue Jan 18 2022 06:01:10 GMT+0800 (China Standard Time)

Hi Anders,

Have you tried unplugging and plugging the module back in?

Yes, I did try but it didn't solve the issue.

AndersBuhl · Answer 3 · Tue Jan 18 2022 18:30:10 GMT+0800 (China Standard Time)

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?

Anton Martinsen · Answer 4 · Mon Jan 24 2022 23:20:32 GMT+0800 (China Standard Time)

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?

chmousset · Answer 5 · Sat Jan 29 2022 16:32:14 GMT+0800 (China Standard Time)

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?

Anton Martinsen · Answer 6 · Thu Feb 03 2022 18:03:32 GMT+0800 (China Standard Time)

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.