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? :)

( Zsugabubus | 2025. 11. 09., v – 20:26 )

Nem biztos, hogy értem, mit akarsz, de nincs valami reset controller azon az MCU-n?

Pl. ATSAMV71-en ez működik:

RSTC->RSTC_CR = RSTC_CR_PROCRST | RSTC_CR_EXTRST | RSTC_CR_KEY_PASSWD;

AT91SAM-on:

*AT91C_RSTC_RCR = 0xA5 << 24 | AT91C_RSTC_PERRST | AT91C_RSTC_PROCRST | AT91C_RSTC_EXTRST;

Vagy valamiért követelmény, hogy csak és kizárólag az ARM coret lehessen használni?

 

Hm... ez jo kerdes hogy az CMSIS-en kivul van-e valami reset lehetoseg ezeken az STM32F0x-es csippeken. Soha nem is hasznaltam es igy hirtelen nem talaltam a doksiban semmit. Van mindenfele related cucc (PWR: power control, RCC: reset and clock control), de konkretan ilyesmit nem lattam igy hirtelen (nehanyszor 10 perc keresgeles). Szoval lehet hogy en vagyok a vak es van a fentihez hasonlo itt is. 

Vagy valamiért követelmény, hogy csak és kizárólag az ARM coret lehessen használni?

Hogy erted? Most ez az egesz problemakor egy par ARM-os csipp eseten merult fel (STM32F0x: Cortex-M0, EFR32MG24: Cortex-M33), hogy tisztan SWD-vel tudjam reset-elni, ne kelljen az nRST-t hasznalni. Annyira nem kritikus mert ez csak fejlesztes/teszteleshez kell, meg ugyis van remote power cycling meg ilyesmi. De azert lehet nem lenne baj ha tudnam. Akar mint altalanos "reset over SWD" mint amit nehol olvasok hogy ilyen ~50 clock cycles valami, illetve akar mint regiszterbe valo irkalas. Ezutobbi persze jo lenne ha altalanos ARM lenne, de ha per-csipp specifikus az sem (akkora) baj. 

Ettol fuggetlenul nekem fura hogy egy ilyen dolog mint ez az MCU reset mashogy viselkedik ha van racsatlakoztatott debugger. Vagyis, mukodik, de elobb kell egy nRST reset is... utana mar nem viselkedik mashogy... erdekes. 

Találtam STM32H kódot, ott én is az NVIC-et használtam:

   NVIC_SystemReset();

Ami a CMSIS-ben a Cortex M0-hoz így van definiálva:

 __DSB();                                                          /* Ensure all outstanding memory accesses included 
                                                                      buffered write are completed before reset */ 
 SCB->AIRCR  = ((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) | 
                SCB_AIRCR_SYSRESETREQ_Msk); 
 __DSB();

Hogy ez openocd-n keresztül miért nem ment nálad, azt nem tudom. Most én sem tudom próbálgatni.
 

ARM-os chip az ugye a Cortex core, a köré aggatott perifériák meg nem ARM specifikusak. Úgy értettem, hogy ér-e ezeket használni (mint az Atmeleken a reset controllert).

Igen, ez ugyanaz... be akartam másolni a kódrészletet de nem működött a featúra... Mindenesetre megnézem jobban más csippekre meg gyári devboardokra (Nucleo) is nemsokára. 

Úgy értettem, hogy ér-e ezeket használni (mint az Atmeleken a reset controllert).

Persze, ér. Csak naivan ugy gondolnám hogy ennek működni kéne az ARM core-ra is. Meghát végülis egy "kis" side effekt mellett végülis megy. Mondjuk ettől pont a gyakorlatban használhatatlan de mindegy :) Csak közben agyalok hogy mi lehet ennek az oka így digtális logika szintjén de reset-ekben (legyen az sync vagy async) sosem voltam jó :/

( apal v | 2025. 11. 13., cs – 11:26 )

Lehet megvan a hiba. Az OpenOCD mintha bugosan inicializalna az FTDI reset labat. Eloszor valamiert push-pullra teszi es csak az elso nSRST event utan hasznalja open drain jelleggel. Es ha az elejen, bekapcs/init utan push-pullon van ugy hogy logikai 1 akkor a belso reset logika (lasd: RM0091, 96. oldal, Fig. 9) nem tudja lehuzni azt a belso tranzisztorat. Szoval vsz bugos az OpenOCD FTDI drivere es/vagy valamifele konfiguralasos gond van ottan. Szoval ezt meg szinten kicsit nyomozni kell, de furcsa hogy elso korben pushpullra teszi majd masodik korben, hasznalat utan rendesen open drain (ami ugye egy GPIO labnal lenyegeben azt jelenti hogy input-on hagyjuk: a high allapotban a GPIO az input, az active low esetben meg a GPIO az output lesz es 0-ra hajtja).