XC8-ban hogyan lehet force-olni, hogy ne inicializálódjon egy változó?

C/C++

Ki akarom deríteni, hol volt az a RESET utasítás, amelyik végrehajtódott. Eltenném a __LINE__ értékét egy változóba, s nem szeretném, hogy a változóm felülíródjék, mert a program újraindulását követően kiíratnám az értékét.

( apal v | 2025. 02. 06., cs – 23:37 )

Inkabb egy regiszterbe ird ki, joesetben azokat nem inicializalja a hardver reset utan. Legalabbis zero reg-et, meg par speci regisztert (ARMvX-M eseten az sp) leszamitva nem tudok ilyenekrol. Vagy esetleg egy hasznalaton kivuli periferia-regiszter?

Ha GCC-t hasznalnek akkor ugy probalnam meg hogy csinalnek egy hasznalaton kivuli szegmenst (mondjuk .tmp), abba tennem bele a valtozot ( __attribute__ ((section(".tmp"))) ), a linker szkriptben csak siman hozzacsapnam a .bss utan ezt a .tmp-t (pl: .bss: { ... } > ram .tmp: { *(.tmp) } > ram), es akkor ez joesetben megmarad ha a hardver nem buzgeralja a RAM-ot jobban a reset soran. No, es ha van ennek megfelelo direktiva az XC8-ban, akkor azt megkeresnem. Ezt nem tudom, ennyire nem merultem el az XC8-ban, de nem kizart hogy van ezzel teljesen ekvivalens megoldas.

Ha a függvényen belüli static változó nem inicializálódna, akkor kívülről simán hozzáférhetnék a változóhoz annak címével:

uint16_t *fnc(void) {

    static uint16_t var;

    return &var;
}

Csak az a gyanúm, hogy a var is inicializálódni fog. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A belso statikusok is a .bss-be mennek... szoval igen, az is 0-val indul. 

Vagy olyat is tudsz csinalni talan hogy egy "preinit" code section-t csinalsz, ami meg a crt0 elott hivodik meg. MSP430*-nal voltam kenytelen ilyeneket csinalni 1x amikor a beepitett default watchdog hamarabb resetelt mint ahogy a .bss-t torolte volna a crt0 :) De ehhez is csak GCC-specifikus hekkelest tudok csak :/ (lenyegeben ez is ugyanaz mint fentebb: speci section attribute-k csak itt nem adatra hanem kodra, illetve linker szkript modositasok).

( locsemege v | 2025. 02. 07., p – 00:33 )

Amúgy az a jelenség, hogy soros buszon kérdezgetek egy hardware-t kb. másodpercenként, bírta majdnem 5 percig, aztán elhasalt, és a reset oka reset insruction. Egyrészt az unhandled interruptoknál csinálok software resetet, másfelől lehet neki erre parancsot adni, harmadrészt software-es watchdog timeout esetén is lehet. Valahogy szeretném megtudni, mi történik. Reprodukálható, hol kevesebb, hol több idő alatt.

Amíg működik, addig szépen logolja, amit csinál, és ott minden jó. Csak aztán elhasal. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én úgy csinálnám, hogy a RESET helyett egy reset függvényhívás lenne. És ebben a hívásban permanens logba írnám a kurrens sort - például a proci saját EEPROMjába, ha van lehetőség erre. Feltéve, hogy valóban magát indítja újra, akár megtehetjük, hogy mégse, hanem csak a log elmentése után indítja magát újra. Ha elektronikai oka van, hogy újraindul, csak akkor nem működik ez a megoldás.

Alternatíva, ha nincs EEPROM, hogy a soros portra kiírom, aztán várakozok, ameddig kicsorog valóban UART-ból, és csak aztán reszetelek.

Lényegében egyetértek. Kicsit általánosabban: a hardverben legyen olyan debug konzol, amely (a) nulla konfigurációt igényel, (b) nulla konfigurációt tesz lehetővé, és (c) dedikált (= csak debug kimenetre használható, így nem lesz kísértés, hogy valami "üzleti funkciót" ráépítsünk). A CPU által végrehajtott legelső utasításnak már képesnek kell lennie a debug konzolra írni, és a debug konzol használata / használhatósága nem függhet CPU üzemmódtól, az MMU állapotától, megszakításoktól, stb.

Olyan hardverre fejleszteni, amiben nincs ilyen debug konzol, kínszenvedés.

A különbséget jól szemléltetik a QEMU x86_64 pc/q35 kontra aarch64 virt alaplapjai. Az előbbieken van egy debug IO port; tudja a fenti három jellemzőt. Az utóbbin van egy (ill. most már akár kettő) PL011 soros port, amely memory mapped -- egyszerre tud túl sokat és túl keveset ahhoz, hogy jó debug konzol legyen.