2024-07-04 10:28 AM
An internal error occurred during: "Launching teste".
Cannot invoke "org.eclipse.cdt.core.model.ICProject.getProject()" because the return value of "org.eclipse.cdt.debug.core.CDebugUtils.getCProject(org.eclipse.debug.core.ILaunchConfiguration)" is null
Solved! Go to Solution.
2024-07-04 12:32 PM
Make new project, without any non-ascii characters. (as Radosław said.)
No space, +, € ... only ascii , like teste_04_07_24.
Then try .
2024-07-04 11:00 AM
space sign in project name
2024-07-04 12:32 PM
Make new project, without any non-ascii characters. (as Radosław said.)
No space, +, € ... only ascii , like teste_04_07_24.
Then try .
2024-07-04 01:11 PM
I DID WHAT YOU SAID BUT UNFORTUNATELY THE ERROR PERSISTED
2024-07-04 01:42 PM
So show: project name
+ .ioc
+ main.c
+
Just : is this your first test ? Made any projects (with IDE ) before ?
2024-08-02 06:00 PM
I've got the same problem. I go to run the very, very basic code that was generated and somehow the name is null. I'm coming to this as ARM mbed is going away and the STM Cube was hyper buggy when I used it (v1.3 is where I bailed out) now I'm on Apple Silicon and wanting some kind of usable HAL for development, I thought I'd give it another go. If it is because the project is called Test - then I'm done with this and I'm off to something else, anything else.
2024-08-02 11:31 PM
>I go to run the very, very basic code
Yes, very, very basic - but not for STM32 chip.
So start stm32 project (give it a name) , use Cube/Mx ,
set the cpu functions you want/need , gen.code , write in user areas something to do - compile and debug.
Maybe somewhat unsporting, but read the manual - would help.
https://www.st.com/resource/en/user_manual/um2609-stm32cubeide-user-guide-stmicroelectronics.pdf
see getting started ANxxx ->
https://wiki.st.com/stm32mcu/wiki/Category:STM32CubeIDE
2024-08-03 05:45 AM
Yeah, I'd done all the switching fabric stuff and the clocks etc. The only way I could get out of this was to delete the working folder (strangely wasn't in the Documents folder but in the USR root. Then import the project into a new workspace. Yeah, this is still a buggy mess, but I'll persevere and port over a couple of the smaller ARM mbed projects and see how I go. I'm also thinking of consolidating from other manufacturers mainly TI, Fujitsu and NXP to a single manufacturer to avoid platform pain. I have memories of terrible support from ST for mbed, one of the reasons I used NXP for the last project. I'm not new to SGS-Thomson, I've still got my first project here based on the lovely gold, windowed, ST90E40 / ST9 8/16 bit microcontroller (pre-ARM) from the 90s