"The serial device 'MPU Serial (/dev/ttyUSB0)' is not available"

[Mario Luzeiro]

I'm on Linux debugging STM32MP1, latest version of everything installed. I used to be able to debug in "production mode" but now I got:

"The serial device 'MPU Serial (/dev/ttyUSB0)' is not available."

if I start debug

"The selected serial device 'MPU Serial (/dev/ttyUSB0)' is not available anymore, please update the Debug configuration."

However, I'm able to open the /dev/ttyUSB0 with other terminal softtware, the "/dev/ttyUSB0" appears as an option on debug options, also, the status on bottom right is green.

How to fix this?

[Mario Luzeiro]

It looks there is some bug with the labels on the Debug configuration. I selected the "wrong" serial port and in the end it actually worked with the correct one. I check there is some issue with UI and select item box of the serial port.

[Markus GIRDLAND]

Hello there,

Is your project version controlled? If so, could you step in the history and select a version where it worked and send that .launch file and then step to where it no longer worked and send the .launch file for that version of the project?

If so you can compare this line in the .launch file:

<stringAttribute key="org.eclipse.cdt.debug.gdbjtag.core.serialDeviceLoader" value="my_value"/>

Perhaps this has changed between project versions?

[Mario Luzeiro]

the both lines were wrong. I was able to manually changed it. However looks the UI is reverting to the other serial port if I edit Debug configurations.

<stringAttribute key="org.eclipse.cdt.debug.gdbjtag.core.connectionSelected" value="MPU Serial"/>
<stringAttribute key="org.eclipse.cdt.debug.gdbjtag.core.serialDeviceLoader" value="/dev/ttyACM0"/>

I'm able to debug but the light bottom right status is "Serial console in use" but it works.

[LudovicR · Accepted solution]

Hi @Mario Luzeiro​ ,

the principle of debug configuration for MPU is to detect target console & IP address in order to debug in production mode. This means Target Status, the ligth on bottom right is green.

Note, that "Serial console in use" means you have opened a Linux console in our CubeIDE, and Target Status cannot be updated.

Now, if your hardware set-up has changed, or if you have rebooted your linux PC, it mays has an impact onto the numbering of /dev/ttyACMx in your case... and could mean your debug configuration is no more valid.

Rather than hacking the .launch file, I recommend in that case to create another debug configuration to get benefit of the discovery process.

Hope this help,

LudovicR

[Mario Luzeiro]

I understand your answer and is a good suggestion.

However, I think there is still some kind of bug with the UI as it doesn't allow me to change the serial port (the Apply button does not allow to be pressed) so I have to manually change it in the .launch file

This serial port thing happens when there are multiple serial ports connects on PC (eg the new STLink creates a virtual serial port ttpACM0, etc)

[LudovicR]

This is why it is not recommended to hack configuration file... the MPU Serial is the object to be updated, here you are doing only part of the job.

[rbarris]

I'm experiencing the same or very close to identical problem, attempting to set up debugging on the M4 in production mode.

In short, the STM32MP157 board's UART shows up on my Ubuntu 22.04 host as /dev/ttyACM0.

No amount of fiddling will get the debug config dialog to accept that serial port address.

However, I can open up that port in minicom, and I can also open up that port in the IDE console. I can also run "sudo lsof | grep ACM0" and confirm that the port is open when being used, and not open when not being used by minicom or console.

Can you elaborate on what steps the IDE should be taking to assess whether the port is "available" or not? Should it merely try to open the port, or is it setting the baud rate (should be 115200), and/or does it try to issue a UNIX command to the prompt at the other end of the UART (I have it logged in as root)?

Can you provide any debug logging steps to help illuminate why the IDE refuses to accept that port?

I'm going from the steps in this ST tutorial video -> https://www.youtube.com/watch?v=YIhzzgJmop0. If there is another sequence I should follow, can you link to it ?

If you have worked through this example using STM32CubeIDE latest version below, can you post a copy of the .launch file that you wind up with after successful production mode debug ?

[rbarris]

update: I made it to the STM32MP wiki and read up on the target status widget. Using that I am able to get the correct port selected and it enables the Debug button.

However I'm not able to get debugging to start as I get the "No ST-Link Detected!" error.

True: there's no physical STlink interface. All that connects host and board is ethernet and one USB cable. I have the "STLink (OpenOCD)" checkbox set in the debug config, matching the example video above.

The target board is a Digi ConnectCore MP15 DVK, running Digi Embedded Yocto (kirkstone build). Are there any packages that need to be present on the target rootfs for the IDE to be able to log in and start up the debug session ? What specifically is it looking for that results in the "No STLink Detected" error ?

[rbarris]

It appears that on the Digi Embedded Yocto distribution (4.0-r1) for STM32MP1, either in the build on their FTP site or in the locally built version I made, the sysfs nodes for remote processor support are missing.

So I have an ST devkit board where /sys/class/remoteproc/remoteproc0/... exists, and the Digi board where it's empty after /sys/class/remoteproc/...

I don't quite know enough yet about the ins and outs of Linux on MP1 to know where to look, in terms of what components or build options need tweaking to get those nodes to appear. But I think that's why I am hitting the "No STLink detected" error in this case.