SWD, RST, MWW... avagy a debugger debuggolasa(?)

Erdekes kiserlet: reset-eljunk egy Cortex-M0-t tisztan SWD-n keresztul, az nSRST hasznalata nelkul. Hogy ezt hogy is kell, erre nem tudom a valaszt (az internetek szerint lehet hogy nem is lehet megcsinalni de a nyomozas folyamatban), mindenesetre egy erdekes dolgot vettem eszre. Konkretabban: ha csak ugy megadom az OpenOCD-nek hogy "mww 0xe000ed0c 0x05fa0004", ami ugye a CMSIS szerinti NVIC_SystemReset()-nek megfelelo ertekadas akkor nem csinal semmit, nem resetel semmit. Se nem interaktivan (telnet 4444), se nem startup command line argument command (-c) formajaban. Ugyanitt az "mdw 0xe000ed0c" mukodik, szepen visszaadja hogy "0xfa050000". Viszont ha elobb az nSRST-vel kiresetelem (sima "reset" parancs a megfelelo beallitas, a "reset_config srst_only"  - es persze a harmadik drotmadzag bekotese - utan) akkor ugye szepen ujraindul a cuccmany, megy is, es akkor mar ki tudom resetelni ugy hogy "mww 0xe000ed0c 0x05fa0004". Es akkor megegyszer (meg utana tobbszor) is lehet mar resetelni igy szoftveres(ebb)en. 

Avagy jol mukodik a software reset miutan a hardware reset sikeresen lefutott. Avagy most ki kellene debuggolni a debuggert hogy tulajdonkeppen mi is tortenik. Lehet hogy az egyebkent kotelezoen kiadando OpenOCD "init" csinal valami turpissagot... erdekes...

Azert majd egy szep napon az X problemara (Cortex-Mx resetelese SWDIO + SWCLK-val, /RST nelkul) is jo lenne megoldast talalni :) 

( VaZso v | 2025. 11. 07., p – 23:41 )

Nem biztos, hogy segít és nem Cortex-M0, hanem Cortex-M3 és M4, valamint STM32 és a saját konfigurátora, de van benne a SYS rész alatt egy Debug beállítás, ez "Serial Wire" érték mellett resetelhetővé teszi SWD-vel.

Ha korábban volt másként konfigurált projekt az MCU-ban, akkor le kell húzni akár kézzel a reset lábat a programozás során, de utána resetelhető lesz SWD-n és az is marad.
Első felprogramozáskor felmegy a szoftver a reset láb piszkálása nélkül is.

Közelebb vihet a megoldáshoz, ha generálsz vele két projektet és összehasonlítod, mit csinál másként initkor.

( arpi_esp v | 2025. 11. 08., szo – 10:14 )

egyaltalan nem ismerem azt az arch-ot, de x86-nal is vannak olyan cpu vezerlo regiszterek, amit a bios letilt az hw init folyamat vegen, tehat az OS alol mar nem mukodnek. nem lehet itt is ilyesmi, hogy a bootloader letiltja, de ha valahogy raveszed menet kozben hw-esen egy resetre utana mar azert mukodik mert nem fut le ujra a letilto kod? (es pl. x86-nal voltak olyan erdekessegek bugok, hogy sleep-eles utan maskepp viselkedett, mert a cpu ujraindult de a bios nem futott le megegyszer ugye)

Igenigen, azt siman el tudnam kepzelni hogy valami letiltja az 0xe000ed0c (SCB->AIRCR) regiszter irasat es/vagy az iras soran aktivalodott reset pulse-t. Csak ugye kerdes hogy mi. Ha csak ugy hasznalom az MCU-t akkor semmi ilyen nincs, cold start es/vagy hw reset utan irhato ez a regiszter, azaz a NVIC_SystemReset() mukodik. Ha rajta van a debugger es utana van hw reset akkor azutan is mukodik. Szoval marad az hogy a debugger racsatlakoztatasa (ott valami SWD aktivitas) valtja ki. 

Hm... megnezem, hatha az mww maga tiltott... de nem valoszinu, kismillioszor hasznaltam. Vagy hatha kell egy mdw az mww elott... Mindemellett a debugger hw is sajat takolmany, de ez nagyon nem kene hogy gond legyen. 

Őő... sleepelés utan miert kene ujraindulnia a biosznak? Vagyis ugy sleepeles hogy WFI vagy ugy mint a hibernalas? Na, ehhez sem ertek, pedig x86 (x <= 3) assemblyn nottem fel... de jo ilyeneket tanulni :)

sleepelés utan miert kene ujraindulnia a biosznak?

hat pont ez az hogy nem kell es nem is indul ujra, de a cpu viszont igen, igy amit esetleg eredetileg letiltott az ilyenkor esetleg feloldohat :)

Vagyis ugy sleepeles hogy WFI vagy ugy mint a hibernalas?

wifi??? ugy ertem elaltatod a gepet (gyakorlatilag a memorian kivul minden off), kb mint a hibernalas, de nem annyira melyen (hibernalasnal a memoriatartalmat kiirja diskre es a ram is off).  de ennyire en se ertek hozza csak olvasgattam errol sok eve. pedig en is x86 assemblyn nottem fel de meg a 286-386 idejen :)

Ah, rosszul irtam a relaciot, nekem is x <= 3, persze...

WFI: wait for interrupt, de sok arch szereti sleep-nek hivni. Hogy az x86 minek hivja azt nem tudom :] [...] Ah, HLT, igen... de reg volt... Nem mintha anno az event driven dolgoknak olyan nagy divatja lett volna, ld még valodi operacios rendszerek hianya azokbol (x <= 2 ... 3) az idokbol... 

ja hogy a context nem mentodik... de jo lehet... 

( apal v | 2025. 11. 08., szo – 17:30 )

Kozben annyit sikerult kideritenem hogy valoban nem az mww ... debug utasitassal van a baj mikor az SWD debugger racsatlakozik hanem magaval azzal hogy az 0xe000ed0c (SCB->AIRCR) regiszterbe irok. Konkretan, ha a szoftvernek kiadom kulso buszon (CAN, UART, barmi) a "rebootolj lecci" parancsot debugger nelkul akkor szepen rebootol, de ha a debuggert racsatlakoztatom (OpenOCD lefut az init-ig bezarolag) akkor tovabbra is szepen fut a szoftver, interaktal a kulvilaggal ugy ahogy kell, de a rebootolasba belefagy. 

Konkretan utana a 4444-es konzolon lehaltolva latszik hogy a NVIC_SystemReset() vegen levo, az SCB->AIRCR irasa es a barrier utani while(1)-ben porog. Azaz az SCB-be torteno irast (vagy az iras altal kivaltott reset) a Cortex-M0 ilyenkor ignoralja es megy tovabb mintha mi sem tortent volna. Azt is sikerult kideriteni hogy nem az OpenOCD "init" parancsaval van a baja. Ha azt kihagyom akkor ugyanugy nem megy. 

Illetve ha ez a racsatlakozott debugger eloszor kireseteli az MCU-t az nSRST drotmadzagon at, akkor utana a nyitoban leirt esettel azonos modon megy a kulso buszrol kiadott reboot is igy racsatlakoztatott debugger mellett.

Tehat... kicsit kepzavar ez a "rebootolasba belefagy dolog", de... hogyan is kell/lehet akkor debuggolni a debuggert? :)