STM32MP157C-DK2 M4 debugging issues.

[KnarfB]

Hi,

I have 10 DK2's in a server rack for development and testing. STM32CubeIDE (1.5.0) debugging wants me to specify a serial port and an IP address for debugging. This is IMHO redundant, why? Moreover, the serial ports /dev/ttyACM* are to be selected from a drop-down list. But, those assignments are not persistent. After a reboot of the server or a reconnect of the boards, the ttyACM* changed. I would prefer using the persistent names available at /dev/serial/by-id/usb-STMicroelectronics_STM32_STLink*, but cannot select those in the Debuggger tab.

Finally, the IDE asks me for my credentials several times per debug session. Is there a log which I can inspect to see what's going on behind the windows?

Regards

KnarfB

[Olivier GALLIEN]

Hi @KnarfB​ ,

To address debugging in so call "production" mode STM32CubeIDE need 3 wires :

• serial console ( to check Linux is alive and discover network IP)
• Network ( to load firwmare .elf in Linux file system ( faster than serial )
• JTAG ( to perform debug session )

For non persistence of selected serial port we need further investigation.

Such usage of STM32CubeIDE for // - multiple target debug is a new request.

Could be please share more detail about what you want to achieve ?

One or several IDE instance ? With GUI or headless ?

Just to load and start of firmware or also debugging ( do you really need an IDE ? ) ?

Thanks,

Olivier

[KnarfB]

Hi Olivier,

thanks for your reply. Actually, this is for a student lab. Every group has assigned a board and has to bring-up some M4 code, aided by STM32CubeIDE GUI.

So there is one board per STM32CubeIDE instance. I was looking for something like specifying the ST-LINK S/N option in the debugger tab for MCUs.

This should work, as the output of

lsusb -vd 0483:3752 | grep iSerial
ls /dev/serial/by-id/usb-STM*

matches. Not sure if "by-id" is available everywhere but you ship STM udev rules anyway.

I understand that this is a new request, so we will work around by loading and starting the firmware locally from the command line and no debuging.

Anyway, multi-instance debugging is not so uncommon.

hth

KnarfB