STM32 arm debuggolás

C/C++

Bare metal szintről próbálok beletanulni az ST arm alapú processzorainak debuggolásának. A fejlesztő rendszer egy Debian 12 gépen fut.
Az első a tool chain és aztán a jó öreg "blinky" és miután ez működik jöhet a debugger.. Miután fe
Több bare metal ismertetőt átolvastam mindegyik arra fut ki, hogy addjam ki a parancsot:

$ arm-none-eabi-gdb main.elf

Úgy tűnik ez elavult, a tool chain megvan, azonban a gdb ügyében a Debian elküld, hogy telepítsem fel az arm architecturát. Csináltam már ilyesmit, de konkrétan a debuggolás viszonylatában nem :(
Nem találok hozzá leírást.

Ha feltelpítem az arm architecturát hogy indíthatok egy debug sessiont?

( apal v | 2024. 04. 23., k – 13:51 )

Kulcsszo: `openocd`. Kiindulasnak ez pl egy jo leiras(nak tunik).

Lehet ez lesz a megoldás, de amit eddig követtem, az az openocd-t meg sem említi. Helyette az ST Link csomagot rakja fel a git-ről. Én a Debian repóból raktam fel és kipróbáltam az STLink V3SET-el. Flashalni tudtam.

“Bare Metal” STM32 Programming (Part 1): Hello, ARM! – Vivonomicon's Blog

* Én egy indián vagyok. Minden indián hazudik.

Openocd tudtommal rávehető ST-Linkkel való kapcsolatra is. Egyébként attól is függ, hogy mi kell neked, hogy a JTAG/SWD portját használod az MCU-nak, vagy az STLink-et.

Az ST-Link amúgy egy USB interface az SWD-hez, meg ha jól emlékszem, az egyik UART is rá van kötve, oda írhatsz debug üzeneteket, amit leolvashatsz valamelyik GUI-s program konzolján.

Az ST-Link amúgy egy USB interface az SWD-hez, meg ha jól emlékszem, az egyik UART is rá van kötve

Sajnos ez csak felig igaz :/ A gyari ST-Linken nincs kivezetve debug UART, de az ST Nucleo sorozataba beepitett progamozo is 1:1-ben ST-Link kompatibilis, es ott mar tettek ra egy debug UART-ot (ami /dev/ttyACMx-kent jon fel, egy fuggetlen endpoint-parkent). Az ST Nucleo nyakok (egy resze legalabbis) perforalt, igy le tudod valasztani es/vagy ki tudod vezetni akar a debug UART-ot is, ha kell. 

( balagesz | 2024. 04. 23., k – 14:43 )

Szerkesztve: 2024. 04. 23., k – 14:44

Eddig debugolnom nem kellett, illetve pontosítok: elég volt egy UART-ra a kérdéses dolgokat kidumpolni. De az alapot kipróbáltam, akkor működni látszott. :)

Debugnál a felépítés ilyen "szerver-kliens" megoldás, maga az arm-gdb ebből a kliens, az adja az UI-t. Ez csatlakozik a gdb-server-hez, ami ez esetben lehet az előbb emlegetett openocd. Viszont mindenféle paraméter nélkül az arm-none-eabi-gdb-t elindítva a gdb parancsértelmezőjének kellene előjönnie, ahol a gdb szerverhez való kapcsolódáshoz ki tudod adni a megfelelő parancsot. (pl: target remote localhost:3333) Nyilván ehhez előbb el kell indítani a "szerver"-t, ami itt a megfelelően felparaméterezett openocd. (Itt írtam erről pár mondatot, az ne zavarjon, hogy nem STM, a logika ugyanaz.)

És a vicc: a linkelt oldalon is emlegetett, arm-tól letöltött gcc csomag szintén tartalmazza a gdb-t, de az most nem akar elindulni, valami Python-os problémára panaszkodik. :) A próbát akkor a disztribúcióban elérhető csomaggal csináltam, annak nem volt semmi nyűgje. Viszont ezekből lehet, hogy muszáj lesz frissebbet felrakni mint ami Debianon az alap tárolókban van, jó kérdés, mennyire régiek, az openocd elég sokat fejlődött az elmúlt pár évben, akár STM támogatás oldaláról is.

A gdb-nek (ha csak esetleg nem valami összeintegrált változat, aminél kérdés, mennyire releváns az eredeti doksi) érzésre kelleni fog valamilyen gdb-server, de lehet hogy a csiphez felrakott környezet hoz sajátot. (Ami simán lehet, hogy egy lebutított openocd... :-D ) Ez a stuff kommunikálna esetedben az ST-Link segítségével a csippel közvetlenül, és ehhez csatlakozik a gdb maga: csip <-> kábel <-> gdb-server <-> gdb a konfiguráció.

Az, hogy flash-elni tudod az eszközt, az nem jelenti azt, hogy a debug is megy! Az ST-Link-et nem (sem...) ismerem, de mintha az egy "rendes" jtag/swd interfész lenne, (az?) így gyorsan rákeresve, van az openocd-ben valamilyen konfiguráció hozzá. (Én egy saját építésű, FT2232 alapú jtag/swd interfészt használtam /-ok, emiatt nem biztos, hogy releváns itt a többi tapasztalatom, de a logika "gyárilag" ez.)

Igen, az `openocd` mind telnet-szerver, mind gdb-szerver mind pedig batch uzemmodban szepen megy FT2232/FT4232 alapu programozokkal (sok ilyet csinalok/hasznalok en is) illetve ST-Linkkel is :) Szoval a logika az teljesen ugyanaz, vagyis inkabb igy mondanam: csipp <-> SWD kabel <-> SWD programozo <-> (altalaban) USB kabel <-> szamitogep + openocd = gdb-server <-> tcp/ip <-> gdb. Az `openocd`inditasakor megmondod hogy milyen programozot hasznalsz, es mar kesz is:

openocd -f interface/stlink-v2.cfg \
        -c "transport select hla_swd" \
        -f target/stm32f0x.cfg \
        -c "adapter_khz 100" \
        [...]

Kerdes persze hogy a kerdezo kolleganak milyen hardvere is van konkretan - ha azt megirja akkor tudunk ra kanyaritani openocd konfigot :)

Köszönöm előre is, lehet élek a felajánlással.
Én is eddig mindenütt az openocd-t láttam erre a célra (debugger hw - openocd - gdb). Olvasgattam a VSCodehoz készült IOPlatform-ot is ott is az openocd-re hivatkoznak. Szóval én sem értem.
Ráadásul most ez a csavar, hogy akkor nem "patkolt gdb" hanem architektúra. Valami itt hiányzik.

Egyébként a HW egy kínai minimal board rajta egy STM32F051C8 (azért ez mert kell a DAC) és mindezt egy STLink V3SET debuggerel SWD módban hajtom.

* Én egy indián vagyok. Minden indián hazudik.

Akkor elso korben az interface/stlink.cfg-t nezd meg:

#
# STMicroelectronics ST-LINK/V1, ST-LINK/V2, ST-LINK/V2-1, STLINK-V3 in-circuit
# debugger/programmer
#

adapter driver hla
hla_layout stlink
hla_device_desc "ST-LINK"
hla_vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753 0x0483 0x3754

Szoval amit irtam fentebb, de stlink-v2.cfg helyett stlink.cfg, a 0.12-es openocd-tol kezdve mar igy hivjak ezt az altalanos STLink drivert. Sajna nekem ilyen V3-as programozom nincs (csak klasszik, V2, Nucleo, pont F051-eshez egy discovery meg sajat gyartmanyu FT2232/FT4232-esekbol egy rakat), de elvileg ennek igy mennie kell.

Ha a fenti (modositott) openocd elidnul, akkor egy ilyesmit kiprobalhatsz:

$ telnet localhost 4444
[...]
Open On-Chip Debugger
> mdw 0x08000000              
0x08000000: 20001800

Es ha ez megy (azaz a debugger tudja debuggolni a hardvert ilyen alacsony szinten, az az memoria-regiszter iras-olvasas szintjen) akkor utana a gdb is menni fog.

A jelenleg legújabbnak mondható eredeti ST gyártmány (a Farnell-től) STLink V3SET nem tud debuggolni egy STM32F051C8 akkor kár is vele foglalkoznom.

Talán annyi, hogy az st-info szépen kiírja az mcu kódját (ha jól emlékszem 0x440) és a sorozatszámát ha lekérdezem, ill. a FLASH és a RAM méretét is helyesen jeleníti meg. Szóval eddig biztató.

* Én egy indián vagyok. Minden indián hazudik.

( gazsiazasz | 2024. 04. 23., k – 19:24 )

Én úgy szoktam, hogy fenn van a STM32CubeMX, és CLion-ban van STM32CubeMX projekt, amit ha indítok, akkor legenerálja STM32CubeMX-szel a projektet és belövi a gdb(+openocd?)-t ami kell a debug-oláshoz, csak írni kell a kódot és kis bogárkára nyomva megáll a breakpoint-okon, mikor össze van kötve a board ST-Link-kel.

( 3org | 2024. 04. 24., sze – 22:33 )

Miért válasszátok az STM32 az NXP helyett?
Elvárom, hogy telep után induljonon a debug.
Összelapáltok egy éppen elinduló valamit
, és 3év múlva kuka, mert a dolgok nem "megfelelően" változnak.
Az NXP egy komplet rendszerben frissíti az IDE, a CMSYS.

Miért nem azt használjátok?

Körtét almával. Egy cortex-M7 hol ekvivalens egy M0-sal? Én kb azóta foglalkozom cortex-Mx procikkal (Hw és SW design), mióta megjelntek. Sajnos az NXP az elején szerintem elrontta(ahogy a TI is), nem véletlenül lettek a ST talán a legnépszerűbb ARM cortex uC-k.

Egyébként fel lehetne tenni a kérdést miért nem x gyártó, mert azért manapság már minden uC gyártónak van cortex-es mikrokontrollere. Feladathoz, költségvetéshez választunk eszközt nem fordítva.

Személy szerint a ST LowLevel driverek(korábbi StdPeriphLib) a kedvenceim(a HAL drivereket viszont ki nem állhatom). Saját makfile-os fejlesztői környezetet építettem össze és messze a legkönyebben a ST lehetett customizálni.  

(Fejlesztettem ST, Atmel, Silabs uC-vel terméket és NXP, Freescale, TI ARM cortex-es uC probáltam ki).

Ráadásul, nekem úgy tűnik, az ST-kel sokkal többen dolgoznak. Számtalan kód és guide van fenn a neten és lehet tanulni / puskázni.

A távolkeletiek elárasztották a piacot mindenféle NYÁK-al és maga az ST is gyárt/forgalmaz egyszerű és olcsó eval bordokat.

* Én egy indián vagyok. Minden indián hazudik.

Részben hitvita.
Leginkább azt választja az ember, amelyik éppen kapható, meg amelyikből a devkit éppen kapható.

Viszont van egy objektív érv is az STM32 mellett: az STM32CubeIDE. Összehasonlíthatatlanul jobb, mint az MCU Xpresso, ha gyorsan akar az ember valami működő minimál verziót csinálni.

Miért válasszátok az STM32 az NXP helyett?

Azén tippem szerint azért, mert régen amikor még sokkal spártaibbak voltak a körülmények (könnyen elérhető/használható toolok meg IDE-k meg debuggerek nem nagyon voltak, vagy csak nagyon nagyon sok pénzért) meg nem volt (használható) HAL réteg meg a többi réteg, meg varázslók meg semmise, akkoriban sokan inkább regiszterszinten hajtották a vasat. Azon a szinten az STM32 sokkal jobban ki volt találva és használhatóbb volt mint bármelyik másik, annyira átgondold volt hogy sokkal könnyebben lehetett még az így megírt szoftver alatt is csereberélni a kontroller mint más gyártóknál. Ez egy nagy versenyelőny volt akkoriban, meg tán silicon bugból is kevesebb volt, szerintem kezdetben ezek miatt használták ezt a legtöbben. Aztán a szoftvertámogatás fejlődött, ezt az előnyt ma már látszólag elfedi a HAL meg ami még fölé kerül, ugyanakkor szerintem mégsem mindegy milyenek is azok az alapok amire ráépülnek manapság a rétegek. A jövő persze más lesz, az NXP is fejlődik (mivel máshogy nem sikerült ezért felvásárlásokkal), közben az STM32 fényét még látó X generáció közben szépen eltűnik.

Igen, az STM32 nagyon jol ki van talalva. Olyannyira hogy nehany esetben sajat hardverhez is onnan lopom a periferia-regiszterek alapjait, hogy 1:1ben lehessen hasznalni a szoftverkomponenseket :) 

En sokkal inkabb azt erzem hogy nem azert obfuszkaljak a gyartok a sajat cuccaikat mert barmi szakmai indok lenne, hanem mert vendor lock-int akarnak. Hogy most hany absztrakcios reteget pakolsz bele az szinte mindegy ebbol a szempontbol... 

Az STM32 szerintem is nagyon jó. (Az NXP-hez nem tudom hasonlítani, mert azt nem ismerem.) Első osztályú a dokumentációja és eddig minden pont úgy működött, ahogy le volt írva. Úgy vagyok vele, hogy a mennél vékonyabb HAL-t szeretem, nem azért mikrovezérlőzök, hogy távol legyek a vastól. De annyit mindig csinálok, hogy szimulálni tudjam a működést PC-n is.

Használtunk olyan mikrovezérlőt is (nem STM32), aminek csak a serial interfészével heteket szórakoztunk, mert semmi sem úgy működött ahogy le volt írva. Nem is sikerült megbízhatóan interruptot kicsalni belőle, pollingra át kellett terveznünk végül a már kész alkalmazás logikáját. Borzalmas, hogy milyen rakás szarokat adnak el egyesek, és ez egyéb szempontokból egy jó processzor volt ráadásul, úgyhogy nem lehetett kipöckölni a projektből.

( 3org | 2024. 04. 25., cs – 08:57 )

Szerkesztve: 2024. 04. 25., cs – 08:59

.

( cyclops | 2024. 04. 25., cs – 14:56 )

Szerkesztve: 2024. 04. 25., cs – 15:10

Én munkám során sokat szoktam debuggolni, de gdb-t parancssorból csak a legritkább esetben használok, mert nem hatékony, nem szeretem. 

Hacsak nem ragaszkodsz a debian-os gdb-hez, akkor ajánlom az STM32CubeIDE-t, ami az STM saját gyártású IDE-je, telepíthető Linux alá is, benne van a fordító is és lehet debuggolni. Eclipse alapú, és általában a csipgyártók Eclipse alapú IDE-it nem szoktam szeretni, lassúak, bugosak vagy valami nagyon drága debugger kell hozzájuk: a Renesas, TI, NXP, Infineon IDE-k jutnak hirtelen eszembe, de az STM32CubeIDE szerintem teljesen jól használható. 

Másodsorban ajánlom a Visual Studio Code-ot és a PlatformIO-t, itt a PlatformIO kiegészítőben van a fordító, meg library-k. Ehhez gyártottam oktatóvideót is, elnézést az önreklámért: https://youtu.be/8F5E5lvtygk

Szerettem volna első megközelítésben elkerülni az ide-t. Semmi kifogásom ellene, de ahhoz, hogy egy olyan bonyolult kódot mint a nop-al késleltetett "blink", nem kell ilyen nagy ágyú.
Az is hozzátartozik ehhez a történethez kicsit átlássam a debuggolás működését (debugger - openocd - gdb - és végül a megjelenítés - ide vagy szövegszerkesztő).

Egyébként a cél a VSCode és a PlatformIO lenne. A VSCode gyártófügetlennek tűnik és tényleg bárki használhatja akárhol (nincsenek licensz problémák).

* Én egy indián vagyok. Minden indián hazudik.

Kínai cucc, STM32F051C8 minimal board - még az SWD csatlakozóról is lemaradt a reset (helyette viszont van egy BOOT1 ami ennek a mcu-nak nincs is).
A "blinkelhető" lED a PC13-ra van kötve és a kivezetések két sorban vannak a NYÁK peremén, így nem lehet breadbordba dugni.

* Én egy indián vagyok. Minden indián hazudik.

STM32F0xx-es board-om nincs, de STM32F103-mal az alábbi működik (csak persze én az stm32f1x.cfg-t használtam).

Debian 12 alatt a gdb-multiarch csomagot kell telepíteni, az ismeri az arm architektúrát.

Egy terminálban indítsd el az OpenOCD-t:

$ openocd -f interface/stlink.cfg -f target/stm32f0x.cfg -c "init" -c "halt"

Ez alapból a 3333-as porton várja a GDB csatlakozását.

Egy másik terminálban a gdb-multiarch -ot kell elindítani:

$ gdb-multiarch firmware.elf
...
(gdb) target extended-remote :3333
(gdb) monitor reset halt
(gdb) b main
(gdb) info b
(gdb) c

A "target extended-remote :3333" paranccsal kapcsolódik az OpenOCD-hez és utána lehet futtatni meg töréspontokat létrehozni, stb.

Itt flash-elés nincs, a GDB feltételezi, hogy a flash ROM-ban az a kód van, aminek a szimbólumait a firmware.elf-ből betöltötte.

Remélem ez segít!

( tovis v | 2024. 04. 27., szo – 15:56 )

Egyébként, a Debian 11 repoban még van ilyen "gdb-arm-none-eabi".

* Én egy indián vagyok. Minden indián hazudik.

Tedd fel a `gdb-multiarch`-ot, es akkor ugy. Egy kis Nucleo F072-es egyszeri RS232 <-> CAN konverter kapcsan most az egyik terminalban elinditottam ezt:

$ openocd -f interface/stlink-v2-1.cfg \
          -c "transport select hla_swd" \
          -f target/stm32f0x.cfg \
          -c "adapter_khz 100"

Masikban pedig ezt:

$ gdb-multiarch main.elf
[...]
Reading symbols from main.elf...
(gdb) target ext:3333
[...]
(gdb) print global_cs 
$1 = (struct can232_state *) 0x2000176c
(gdb) print global_cs->cs_can_recv_wr
$2 = 0
(gdb) print global_cs->cs_can_recv_rd
$3 = 0
(gdb) print global_cs->cs_can_recv_rd
$4 = 6
(gdb)

Szoval kb ennyi :) Nem kell semmi dpkg-multiarch, nalam is csak tisztan x86_64-es a Debian.  Lasd meg amit cyclops kollega irt fentebb.

A dpkg multiple-arch es/vagy --add-architecture kapcsan meg x86_64 + i386-os kombinacio eseten is voltak ha nem is tragikus de nem is annyria kivanatos tapasztalataim anno, szoval en inkabb kerulnem (es ezert probalnam kerulni mas temak felbukkanasa eseten is). De itt ebben az esetben, ahogy mindketten is mondjuk, nincs szukseg erre, csak a `gdb-multiarch` csomag telepitesere :) Alapjaraton nem hasznalok embedded fejlesztesre gdb-t, csak kozvetettebben openocd + telnet:4444 + memorydump szinten debuggolgatok (ami persze a hardver szemszogebol nezve ugyanaz). De ezt is kiprobaltam most es ugyanugy jol megy: lasd: fentebbi snippetek.