A pontos típust nem adtad meg, és feltételezem, hogy C-ben írod a programot.
Ott a leggyakoribb eshetőség, hogy valamilyen buffer túlírása történik, és ezzel a stack felülírása. A stackben lévő visszatérési címek átírása pedig okozhat ilyen jelenséget. A fordítók általában az adatmemória végére teszik a stack-et, ezért lehet ezt viszonylag könnyen elérni.

Megnézném az string műveleteket, Ha eddig nem így csináltad, akkor kerülni kell a nem limitáltakat. strcpy, strcat, strtok, sprintf, etc. Ha ezeket nem használod, akkor még mindig van sok lehetőség a buffer túlírásra, például a cast nem megfelelő használatával, stb.

A másik lehetőség, ami szokatlan újrainduláshoz vezethet, ha túl kicsi a stack, de ha jól sejtem akkor a _StackError trap ennek figyelésére van, szóval itt az - ha minden igaz - nem játszik, de nem vagyok erről teljesen meggyőzve, legalábbis egy dspic adatlap alapján amit néztem, ezért is kellene a pontos típus.
Az INTCON2, SWTRAP-et 1-be állítottad?

Igen, ez is egy lehetséges ok tud lenni ilyenkor!
Viszont mivel ez a jelenség ugyanazon a hardveren, egyetlen egy üzemmódjában fordult eddig elő úgy, hogy közben a hardveres körülmények nem változtak, így inkább kizárnám az ilyen jellegű okot! Én azt gondolom tisztán szoftveres eredetű jelen esetben a probléma. Azt viszont nagyon nem zárom ki, hogy a fordító a ludas(vagy az én hiányos tudásom a C nyelv speciális rejtelmeit illetően)

dsPIC33EP32GS504 a konkrét típusa a mikrovezérlőnek! Igen, teljesen C-ben írta a program, sehol sincs asm betét benne, így pl a W regisztereket sem birizgálom közvetlenül.


Ez...benne van a pakliban! Van erre lehetőség, hogy módosítsuk a stack elhelyezkedését? Mondjuk, már a méret módosítása is lehet erre hatással, azt könnyen ki tudom próbálni majd...

Nem használom az általad megadott függvényeket, minden string művelet gyakorlatilag abban merül ki, hogy string-re mutató tömbökből jelenítek meg szövegeket. Semmi manipuláció velük nincs...


Nem, tegnap óta nem volt időm foglalkozni ezzel, most ültem le először gép elé ) Gyakorlatilag még azt sem néztem meg, hogy a feljebb jelzett megszakítások működtek e?! Ez alapján gondolom nem... ) Kösz, hogy felhívtad rá külön a figyelmem...!

Akkor teszteléssel, logolással be kell szűkíteni a hiba előfordulását és utána a kód elemzésével, debuggolásával meg kell találni.

Ez zajlik most! De roppant nehéz leszűkíteni a kört, amikor csak annyi infóm van, hogy a hiba keletkezése kb milyen üzemmódnál van?! Mert hogy nagyjából ugyanazokat a függvényeket használom mindenhol...!
Ez a legnagyobb bajom, hogy nem tudom, hogy lehetne elkapni azt a pillanatot, amikor keletkezik a hiba, hogy debugeren megnézhessem, hol, mi száll el, vagy kap olyan értéket, amit nem kellene...
Az ilyen típusú hiba nem egy normál hiba, amit általában simán ki debugol az ember fia..., max csak némi fantázia és türelem kell hozzá, ilyennel még nem volt dolgom..., pedig már több mint 20 éve programozok mikrovezérlőket...

dsPIC esetén az adatlap mellett érdemes a Reference manual-okat is átolvasni, mert sokkal részletesebb infókat ad. Például az RCON bitjeit mi állítja be és mi törli, ebben le van írva részletesen: Bővebben: Link 8.3 fejezet
És az is, hogy milyen eseményre állítódik be a IOPUWR a PCON-ban.

A másik a Trap-ekről: Bővebben: Link
3.1.1 fejezet
Ha a stack error trap bekövetkezik, akkor a handler-ben a W15 és a SPLIM regiszterek tartalmát érdemes megnézni, lementeni későbbi vizsgálatra.
De ha jól értem az SPLIM-et egyszer írni kell a program elején, hogy a stack túlcsordulás ellenőrzés működjön.

Ahogy látom a stacket az xc16 automatikusan a felhasznált adatterület után és a memória végéig teszi a fordító. Esetleg a stack elé lehet fixen lehet tenni x byte-ot, amit fix mintával, pl 0xDEADBEAF feltöltesz, és ha reset után az felülíródik akkor az van amit írtam.

Szabad lábakra ledeket rakni, programba befűzni, így is szűkíthető a hiba keletkezési köre...A program meg "ne induljon" automatikusan, hanem pl gombnyomásra várjon, itt esetleges újraindulásnál meg tudod állítani debuggerrel, és megnézni a memóriát/regisztereket, már amiket az esetleges reset nem töröl

Nincs szabad láb! Mind a 44 foglalt...
Az a gond, újraindulásnál a debug folyamat is meg fog szakadni, így minden ilyen maga után vonja a legtöbb hadveres regiszter törlődését is. Abban igazad van, hogy a ram tartalma megmarad, de elég sok adatot kellene végig mazsolázgatnom ahhoz, hogy bármit is kezdjek vele. Nem túl reális ez...a leges legvégső esetre tartogatnám csak.

Tegnap tesztelgettem a programot..., elsősorban a stack beállításokra voltam kíváncsi, ad e valami változást?!
Igen, a doksik alapján a fennmaradó ram-ot felhasználta a stackre a fordító alapban, minusz az eseteges heap méret...
A stack-et legkönnyebben a heapon keresztül tudtam módosítani..., de a méret változáson kívül nem okozott javulást. Vagy csak még jobban romlott a helyzet...

Majd arra gondoltam, talán kevés lehet a fennmaradó kb ~160byte ram a megfelelő méretű stack igényhez?! Megváltoztattam az egyik nagy puffer által lefoglalt méretet úgy, hogy kb 60byte plusz ram szabadult így fel, a stack számára.
Meglepetésre, az így lefordított program hibátlanul fut, egész éjszaka futott, és nem volt egy reset sem!

Szerintem ez is azt mutatja, valójában itt egy nem létező program hibát kergettem, ahol is nem a forráskód volt kivételesen a ludas, hanem inkább a fordító okozott valamit, amit nem kellett volna, de legalábbis ha kevés a stack, azt valahogy jobban meghatározni, és figyelmeztetni a programozót...

Amit korábban írtam, hogy ugyanaz a program(fordítás), de debug módban futtatva a készüléket, sem produkálta már a hibát. Ez is számomra azt mutatta, feltehetően nem konkrétan a kódban van itt a kutya elásva...

A probléma úgy tűnik, megoldódott, mindenkinek köszönöm az agyalást és segítséget!