Azért nem akarok nagyon vitába szállni a Visual Studios témában, mert kb. 5 éve próbáltam a VS + VisualGDB párost, nagyon mélyen akkor sem veséztem ki a funkcióit. Akkor nekem úgy tűnt, hogy a VS nem ad több mindent hozzá a dologhoz, mint egy nagyra nőtt szövegszerkesztőt némi Intellisense képességgel. Ha tévedtem, akkor bocs.

A VisualGDB szerintem szuper. Az pedig CSAK Visual Studiohoz létezik. Ami pedig nem rossz IDE. Úgyhogy, én elvagyok ezzel a kombinációval.

Munkaeszközöd?

Igen.

A klón Jlink-el csak óvatosan, mert a CubeIDE-vel nem biztos hogy fog menni (tudom nem is írtál erre vonatkozó szándékot). Nálam a klón Jlink a 6.3 verziós programjával hajlandó csak működni, a későbbi verzióknak nem tetszik a klón mivolta. A CubeIDE meg nem hajlandó a régi Jlink szoftverekkel együtt dolgozni. Én úgy oldottam meg, hogy a régi 9.3.0 verziós truestudiot használom, mert az hajlandó kommunikálni a 6.3-as Jlink programokkal. Szerencsére ez a régi truestudio is képes a mostani verziós 'Makefile' toolchain beállítással generált CubeMX projecteket beimportálni magának, bár első alkalommal kicsit nehézkes a dolog, mert a Symbols és az 'include directory' beállításokat kézzel kell hozzáadni.

A CubeIDE-ben még a saját maga által generált projektet sem tudtam hiba nélkül átvinni másik gépre. ST-linken kívül szerintem nem is kompatibilis más probe hardverrel. Az MCSDK (motor control SDK) projekt generálás/importálás pedig rémálom, csak igazi hardcore mazochistáknak ajánlom.

A J-link nagy előnye az RTT (Real-time transfer), ami a futás közben (debug megállítása nélkül) biztosít memória írás/olvasást, így pl. live variables-t, csak sajnos iszonyat drága. Ráadásul állandóan frissíteni akarja a firmware-t, ami persze állítólag jó eséllyel téglásítja a klónokat.

Azonban van egy ingyenes alternatívája, a probe-rs (Rustban íródott), amely nem GDB szervert használ, hanem saját megoldást. Ez támogatja az ST-linket, J-linket (szerintem a klónokat is), DAP-linket, Black Magic Probe-ot... Jól hangzik, de még nem sikerült kipróbálnom.
Ha van valakinek ezzel tapasztalata, kérem ne tartsa magában!

CubeMX generálta CMake projektekkel dolgozunk a munkahelyemen. Többen, több számítógépen is dolgozunk ugyanazon. Ide az kinél mi, VScode, VS+VGDB, CubeIDE, CLion. Mindegyik teljesen jól kezeli a projekteket.
A MCSDK az tényleg borzalom. Sajnos ott az ST saját dolgozói nem tartották magukat a más dolgozók által készített CubeMX követelményeihez.
CubeIDE jól működik J-Linkkel is.
Ha van STM32 devboardod, akkor van J-Linked is. A Segger ugyanis ad egy szoftvert (reflash), ami J-Linket csinál egy onboard ST-Linkből.
Minden Cortex-M CPU beépített debug szolgáltatása, hogy a debugger hozzáfér a memóriához a CPU leállítása nélkül. Így a target halt nélküli, élő memórianézet elérhető CubeIDE-ben ST-Link használatával is. Ha jól tudom, a J-Link adatátvitele gyorsabb.

Az MX szerintem nem annyira rossz, mint a CubeIDE és az MCSDK. Már gondolkodtam azon, hogy nálam lehet, hogy egy láthatatlan gonosz kis manó mindig elront valamit, mert a CubeIDE magától nem lehet ennyire sz@r.
A CubeIDE-ben már tényleg van J-link beállítási lehetőség, rosszul tudtam! Butított j-link firmware-t rá lehet tölteni ST dev. boardokra, amin van -talán- ST-linkV1-es hardver, de ott a licenc csak annak a boardnak a debugját engedi, más boardot nem enged, és azt is csak lassan: J-link 15-50MHz, ST-link V1 talán 4 MHz, persze ettől még használható.
A Cortex-M engedi ugyan futás közben a memória kiolvasását, de a GDB ezt nem használja. Ezért a GDB-s (pl. OpenOCD) debug szoftveres megoldások nem tudnak pl. live variables-t, ott mindig léptetgetni kell, ha a változó értékét akarod folyamatosan figyelni, de akkor lőttek a megszakításoknak. Mások (pl. VisualGDB, Segger J-link, EBlink) nem, vagy nem teljesen a GDB-t használják, ott működnek az emelt szintű debug szolgáltatások.
Az ST saját GDB alapú szervert használ. Igazából a fejlesztésüknek köszönhetően sikerült lassítani rajta, és egy kissé sánta Live variables-t bevezetni. Tudtommal nem használ RTT-t, ami folyamatos és gyors adatátvitelt tenne lehetővé pl. a memória futás közbeni kiolvasásához, hanem helyette meg-megszakítják a futást, és ekkor olvassák a változók értékeit.
Azt nem tudom, hogy ez mennyire üzembiztos, de tegnap CubeIDE-ben még egy megszakításban lévő breakpointot sem sikerült vele megtalálnom. Bár lehet, hogy csak azt a kis manót kéne fülöncsípnem!

Még annyival egészíteném ki az előző hozzászólásomat, hogy J-linkre átflashelt ST-link szerintem nem tudja a legjobb feature-t, az RTT-t. Így marad a nagyobb stabilitású, de alap J-link szolgáltatás.

Én úgy tudom, nem állítja meg. Használjuk egy csomó időkritikus (HW-t működtető, megszakításokat használó) kód globális változóinak figyelésére, és működik jól. Tudtommal a globális változókat képes target halt nélkül olvasni/írni.
Az ST-Link V3 24 MHz működésre is képes.
Mindezt csak kiegészítésként írom. Nem vitatom, hogy a Segger J-Link szuper debugger. Talán a legjobb.

A build log alapján benne kellene lennie a debug symboloknak. Lövésem sincs miért nem működik.

Elnézést a kései válaszért, elég sűrű volt a hét.

Köszi mindenesetre. Én már feladtam. Saját projektekhez az Embitz simán használható továbbra is, az ST lib-es projekteket pedig igyekszem kerülni, ha lehet.
Vargham: lehet, hogy én tévedek, és a GDB-t jobban átvariálták, mint hittem. Próbálom ezt az STCube rendszer-szörnyeteget megszokni, mert egy projekthez használnom kell, és a fórumon olvasott vélemények azt mutatják, hogy van remény. Bár az ST marketinges gyomrosával, amelyben szétreklámozzák a ZeST funkciót (MCSDK kellék), aztán közlik, hogy csak kiválasztottaknak biztosítják, eléggé lejáratták magukat előttem.
Apropó, CubeIDE dark módban hol kell a függőleges folder fehér csík színét (amiben összecsukhatók az egyes függvények) valami kevésbé világosra változtatni. A Preferences->Appearence-ben már mindent átszíneztem, de még mindig beleég a retinámba a fehér csík, mint plazma TV-be a TV2 logo.

Megjelent az Embitz 2.65-ös verziója az EBlink 6.21-gyel, tehát mindkettő új verziót kapott.
"
Nem tudom igazából, hogy a debug gondom kapcsán mi változott, de most megy a debug -dwarf-4 kapcsolóval és a beépített GCC15.2-vel.