Cube IDE Debugging -- Proper Sequence?

[Chandler]

Hi -- just wondering if anyone has tried importing a project generated by the Designer to the Cube IDE, and then had any success running it using the GDB debugger on either a 746 or 769 Discovery board? Everything seems to build fine in Designer and IDE, and the projects can run on the target board directly from Designer, but I can't get the IDE debugger to work after importing them. On the 746 Disco board, I get this message, right as the switch is being made from flash to debug mode:

----

Download verified successfully

(Read)Failed determine breakpoint type

Error! Failed to read target status

Debugger connection lost.

Shutting down...

----

On the 769 disco board, I don't even get that far. There is a popup saying "Error in final launch sequence. Failed to execute MI command"...

Pictures of the screens are attached.

Maybe I misunderstand what is supposed to happen between the Designer build phase and the IDE debugging phase? I thought IDE is supposed to import the GFX generated project, create the hex code, and all is good, no? If anyone knows how to get to this stage, please share details. Thanks to all. **Cube IDE 1.2 GFX 4.13, all templates version 3**

[HP_it]

I've made a short video describing the steps... It's really simple to get it up and running now :)

https://www.youtube.com/watch?v=eiPtQp4chG0

[Chandler]

Also of note for anyone following this: if you import a GFX generated project to the Cube IDE and wish to use some of the functions defined in the general board support ("BSP") files of your ST kit (such as for instance, the handy i2c calls in the stm32746g_discovery files, and so forth), you will have to manually add the stm32746g_discovery.c and .h files to the project (because GFX does not do this; just copy the files into the GFX generated Drivers/BSP folder, then manually drag and drop the c source file to your IDE project explorer); finally, you have to get rid of the touch screen functions found in that added .c file (TS_IO_Read, TS_IO_Write, and TS_IO_Delay), since these functions are already taken care of for you by the GFX code generator. In other words, the compiler will complain of multiple definitions. I just bracketed those functions out, using "#ifdef NOTUSING_GFX.....#endif", and that took care of it. Maybe, as integration proceeds, we will see less overlap. I think this would be a good time for the IDE group to break up their BSP options into smaller, selectable segments within the Cube, which would go a long way in making other packages integrate more smoothly.