Regression with CubeIDE V1.2.0 - Breakpoint ignored ?

[nick67]

Hi everybody,

I've just installed STM32CubeIDE 1.2.0 on Ubuntu 18.04.

It seems that breakpoints on Cortex-M4 don't work. 

When I debug via ST-Link on stm32mp157c-dk2 everything is fine but breakpoints, they are simply ignored.

Any suggestion?

With previous installation (STM32CubeIDE 1.1.0) breakpoints on Cortex-M4 worked well, allowing to stop execution wherever I wanted.

In the "Progress" tab in Eclipse it seems that Configuring GDB hangs on (at 93%), even if the execution really starts.

[Olivier GALLIEN]

Hi @nick67​ ,

This regression has already been identified and fix internally.

The patch upgrade might be available very soon.

Keep you posted.

Sorry for inconvenience,

Olivier

[nick67]

Thanks a lot

Nicola

[Olivier GALLIEN · Accepted solution]

Hi @nick67​ , all

Patch release V1.2.1 is available !

"Check for upgrade" and proceed.

BR,

Olivier

[nick67]

Just upgraded and breakpoints on CM4 work now 😎

Thanks for the very fast response.

Nicola

[nick67]

Hi everybody,

just to share how breakpoints work now.

On STM32MP157C-DK2 I can debug two applications concurrently, in the same STM32CubeIDE: one on Cortex-M4 and the other on Cortex-A7, using both USB connections (ST-Link and Ethernet over USB). The first connection with CN7 (USb type-C), the second one with CN11 (USB_STLINK). Applications communicate each other using one Virtual UART device based on IPCC and rpmsg channels (I used examples from SDK).

In the CA7 project there are three buttons from a GtkBuilder object, developed with Glade.

Each button has its own callback, and one breakpoint within the function, as you can see in the picture.

Once I press a button a string goes into Virtual UART device, declaring the button that has been pressed.

In order to debug the CA7 project I used C/C++ remote application and a new connection with 192.168.7.1 as host address and root as user.

The second project runs on Cortex M4 and creates the Virtual UART Device.

The CM4 manages three GPIO output pins, connected to three leds on the board: green (LD5), red (LD6) and orange (LD7).

Each time the CM4 receives a string from CA7 it analyzes the command and toggles the related led.

I added a breakpoint here, too.

The debug for CM4 is the usual STM32 Cortex-M C/C++ Application, production mode, with ST-Link (OpenOCD), serial port: /dev/ttyACM0 and Inet Address: 192.168.7.1

During the debug session I launch the debug for CM4 first, in order to create the Virtual UART device.

After that I launch the debug for CA7, that creates the GUI on the target screen with the three buttons.

When I press a button on the screen the CA7 project stops at the related breakpoint.

Then I use the Resume command in the debugger and the IDE switches to the other project ( 😎 ) , the one with CM4 with its breakpoint.

When I use the Resume command here the led on the board toggles and then all the procedure can repeat again.

That's all folks

Have a nice evening

Nicola