Hali!
Akkor az interruptot, és az abban használt főprogrammal közös váltózokat, pointereket nézd át alaposan.
ezek legyenek volatile-k, mint írták... és int. disable a főprogramban amikor hozzányúlsz, akár olvasod, akár irod, illetve ha trükközöl és ugyanazt a függvényt hívod megszakításban is meg a főprogramban is az is nagy gáz.

Mára már letettem de holnap átnézem még egyszer. Pár órája úgy láttam ahogy a nagy könyvben meg van írva, amíg uartbusy true a főprogram vár, ha false akkor írhat az isr-ben lévő változókba és az isr-ben állítom false-ra.
Arra tippelnék ezzel nincs gond, anno nagyon kiteszteltem és sok mást is küld a gsm-nek, azok megfelelően működnek.

Attól lesz egy változó globális, hogy bekerül az object file-ba a változó neve, és így a neve alapján más file-okból is lehet rá hivatkozni. Ez nem C nyelvi kérdés, hanem linkelési.

Azért mert te szereted, attól még nem feltétlenöl kell másoknak ezt ajánlani, mert ettől a programjuk feleslegesen lassú és nagy lesz.

Látod, kiderült, hogy megszakításban is használja. A lassúság mindig relatív. Egy 200MHz-es PIC-nél ez nem olyan kritikus, de egyébként igazad van általánosságban. Ellenben vakon válaszolva, amikor a feldobott probléma az, hogy véletlenszerűen megváltozik egy memóriaterület tartalma, ez is lehet az ok.

Kellene _abban_ a fejlesztői környezetben az strcpy() forrása. Be tudod azt is koppantani?

Szerintem a string lezáró 0x00 hiánya ciki egy kicsit, ha mindenütt default string kezelő függvényeket használsz.

Senki sem mondta hogy nyelvi kérdés, hanem hogy értelmezési eltérés van!
Ilyen alapon minden változó, ami él a program végéig, ismert a címe, az globális akkor ?! Nyilván nem(pl függvény szintű statikus változók)!
Még egyszer, és részemről utoljára, attól globális egy változó, hogy azzá teszed! Egy modul szintű változó önmagában még nem az! De azzá teheted...

Mondasz valamit!! )

Az strcpy is default c függvény, nem tudom bemásolni.
Akkor lehetséges, hogy ezért hülyül be!
Utánanézek...átírogatom. Elég csak a 0x00 lezáró karakternek?

Teoretikusan, ha a TxB tömb után helyezkedik el a memóriában a számokat tartalmazó tömb, akkor könnyen előfordulhat olyan helyzet, hogy a másolás során, a hiányzó 0x0-ás szövegvéget jelző karakter hiánya miatt akkora memóriaszeletet másol át a függvény, ami túlmutat a TxB tömb határán. Márpedig, ha utána van valahol a memóriában a számok tömbje, akkor akár azt is felülírhatja.
Mondjuk ez nem magyarázza meg, miért csak az engedélyezett számok íródnak felül...
Szerintem máshol lesz a hiba. De ezt is javítanod kell..., vagy hagyd el a felesleges másolást!

A másolás nem felesleges! Javítani fogom. Magyarázhatja, mert az strcpy-ig csak az engedélyezett telefonszámok jutnak el!
Akkor a telefonszámokat tartalmazó tömböt úgy módosítom, hogy 12 helyett 13 elemű lesz és az utolsó elemet fixen beállítom 0x00-nak. Más nem szükséges, mivel soha sem nyúlok a 13. elemhez.

Jelen esetben elég lesz egy szem 0x00 lezáró karakternek (feltételezem, suttyonban nem 16/32 bites unicode strcpy()-d van).

Az strcpy() lehetségesen csak egy macro a strings.h header file-ban, vagy akármi is a neve annak a header file-nak abban a környezetben. Nem kizárt, hogy asm-ben külön meg van írva, előre le van fordítva, de nem az a jellemző.

Ha nincs lezáró 0x00 karakter, akkor a memcpy-t kell használni az strcpy helyett. Ott meg kell adni a másolandó bájtok számát is.

Már miért lenne szükség a másolásra ? Mindenhová szépen címként adod át az adatokat, aztán a végén mégis másolatot készítesz belőle, s azt dolgozod fel! Ez milyen előnyt nyújtana ?

Igen, ha mindenáron string kezelő szabvány függvényekkel akarod kezelni, akkor célszerű egy 13. elemet létrehozni, 0x0 tartalommal. Így korrekt lesz.
Azért nem magyarázza, mert ha ez következne be, nem azt az egy szem telefonszám tömböt írná csak felül, hanem még egy másik halom számot is, meg még ki tudja miket, ami útjába esik addig, míg egy 0x0 értékű memóriát nem talál a kiindulási címtől(ami az aktuális szám első byte-jának címe.) Ezt mind megpróbálja majd bemásolni a TxB-be, de ha túlmutat rajta, és mögötte vannak a tel számok pufferei, akkor akár mindet felülírhatja, válogatás nélkül...
De nem ez történik, a leírásod szerint...

Írtál egy ?40k? soros alkalmazást úgy, hogy nem használod a volatile kulcsszót és a string lezárást ahol kellene. Nyilván vannak más problémák is. Ez hamar visszaüt mint a mellékelt ábra is mutatja



Magam részéről MCU kódban nem tekintek semmit fixnek. Memória tartalom változhat.
Elég egy hiba és következik belőle a többi.
Jobban jársz ha a szám beírásakor minden alkalommal utána biggyesztesz egy 0x00-t.
Nem emiatt az egy darab lezáró miatt számít; része annak a szemlélet módnak ami stabilan működő kódot/alkalmazást eredményez.

Sem a fuggveny szintu statikus valtozoknak, sem a csak az adott forrasra nezve globalis valtozoknak nem ismert a cime az adott forrason kivul, nem kerul ki a valtozo neve az object file-ba, a linker nem fog rola tudni. Csak a .bss, .const vagy .data szegmensben lesz neki lefoglalva a hely, de nev nelkul. Ha egyaltalan le lesz. Sokszor az egesz valtozot kioptimalizalja a fordito, nem is lesz neki memoria foglalva, hiaba irtad te oda, hogy static char tomb[2000]. Ha nem hasznalod, akkor le sem foglalja egy jo fordito. Ha volatile, akkor persze lefoglalja. Ha nem static-nak deklaralod, akkor le kell foglalnia, mert ezt mas file-bol is kereshetik. Ezert globalis, nem attol, hogy egy header-ben vagy eppen egy masik forrasban extern-nek deklaralod.

Az igaz, hogy ha nics semmi extern-ezes, es egy masik C forrasban letrehozol egy ugyanilyen nevu valtozot, akkor annak semmi koze nem lesz ehhez a globalis valtozohoz. Az extern mondja meg a C forditonak, hogy a megnevezett valtozot nem kell letrehoznia, csak a neve alapjan hivatkozhat ra, majd a linker kitolti a ponots cimet. De a globalisnak letrehozott valtozo attol meg globalis marad, hogy esetleg mas forrasokban ugyanaz a valtozonev mast jelent. Siman lehet olyat csinalni, hogy az 1.c file-ban letrehozod:

int var;

2.c file-ban hasznalod:

extern int var;

void foo(void)
{
var = 1;
}

es 3.c file-ban meg csinalsz egy fuggetlen var valtozot:

static long var;

Elso ketto ugyanaz a globalis valtozo, harmadik meg egy fuggetlen dolog.

Regebbi rendszereken, ha ket forrasban letrehoztal ket azonos nevu nem static valtozot, akkor azok a nevuk alapjan ugyanoda kerultek a memoriaban. Pedig az is lehetett, hogy az egyik int, a masik char. A memoriaban az int-nek megfelelo teruletet foglalta le. Mai kornyezetek mar altalaban nem engedig a multidefined common valtozokat, de z80-on meg siman ez ment.

A számítástechnika arról szól, hogy egyetlen egy bit sem változik meg indokolatlanul!
Ha ez valami miatt mégis bekövetkezik, akkor rossz a hardver.
Rég megette a fene az egészet, ha ezen múlna egy program stabil működése. Viszont...hibák elfedésére még tökéletes lehet..., ami után ember legyen a talpán, aki meg is találja ezeket a logikai szintű hibákat...

Pont ezt írtam én is. Csak simán 13 elemű legyen és az utolsó karakter fixen 0x00.
Késő délután indul a teszt!

Ez csak akkor lesz jó, ha mindig ugyanolyan hosszú a telefonszám. Ha netán egyel rövidebb lesz, akkor a másoláskor egy számot, ami az előző számból maradt, feleslegesen fog a végére másolni, ami hibás számot ad. Miért nem tudod a számok karakterei után beírni a 0x00-t akkor, amikor feltöltöd a tömböt?

Ha nagyon akarom megcsinálhatom újra, eredetileg úgy volt, hogy a szomszédos országok SIM kártyáival is működjön, de kivettem belőle épp a hiba miatt, még a legelején, hátha az okozza.

Erről hosszasan lehetne értekezni; az ipari elektronikában ez az állítás nem feltétlenül igaz.
Az a része persze igaz, hogy nem indokolatlanul, de az okot gyakran nem ismerjük, vagy másodlagos. Lehet HW-es vagy SW-es oka. Első esetben sem feltétlenül szükséges hozzá rossz HW, legfeljebb fellépett egy olyan hatás, amelyre a HW nem volt méretezve.
Még egy költői kérdés; az ellenőrzőösszegeket (CRC, checksum, hash, stb.) miért is találták ki?

Az ECC RAM-okról nem is beszélve.

Ez nem költői kérdés!
Ezekre akkor volt, van és lesz is szükség, amikor az információt valamilyen analóg közegen keresztül visszük(tároljuk) át. Itt velejárója lehet az információ vesztés, sérülés, ami ellen redundanciával védekezünk.
De amikor egy program működéséről van szó, ami egy tévedhetetlen(?) hardveres felületen fut, ott ez értelmét veszíti. Ha egy bit megsérül, akkor az azt jelenti, rossz a hardver, alkalmatlan számítások elvégzésére. Egy analóg számítógép kb ilyen, tele lehet hibával, amit kezelni kell. De egy digitális eszközben az 1 bit véletlenszerű meghibásodásának(mármint adat) esélye igen kicsi.

Jó, menjünk vissza a hőskorba, biztosan találunk még megbízhatatlanabb eszközöket is )
Egyébként ok, hogy chechsum-mos volt a RAM, de konkrétan te láttál olyat, hogy hibázott, és azt valami lekezelte, és minden ment tovább, mintha mi sem történt volna ?! Ezek csak arra valók, hogy jelezzék, hogy gond van. Arra tökéletes, aztán eldöntheted mi a teendő vele. De azt nem programból fogod korrigálni, hanem odamész, és kicseréled kb...

Az ECC RAM, az nem csak eszreveszi, hanem javitja is a hibat (Error Correction Code). Szavankent egy bit hibat kijavit anelkul, hogy tudnal rola, hogy megserult egy bit a RAM-ban. Es nem mellesleg a mai napig hasznaljak oket szerverekben, meg nagymegbizhatosagu rendszerekben.

Egyebkent tenyleg van olyan, hogy error tolerant programozas. Pl. ha mondjuk van egy szamlalom, amit 0 es 4 kozott leptetek, akkor en nem azt irom a kodba, hogy
if(++valtozo == 5) valtozo = 0;
hanem azt, hogy if(++valtozo > 4). Ez azert van, mert ha barmi miatt megserul a valtozo erteke, akkor az utobbi modszer helyrehozza, mig az elozovel szepen el fog menni a vilag vegeig. Nyilvan nem mindenutt van ennek eredmenye, mert van, ahol egyetlen bit hibatol elszall az egesz (pl. egy pointer eseteben), de speciel egy egyszeru idozitesnel, ami mondjuk valaminek a kiirasat idoziti, ott nem dol ossze a vilag, ha ezzel a modszerrel 3 utan 0 fog jonni, mert megserult a RAM-ban egy bit, es nem negyre lepett a szamlalo. Es ezek a technikak hardware tervezesnel is hasznosak, pl. FPGA irasnal. Abban igazad van, hogy ne seruljon meg egy bit, de sajnos neha megserul, es ha semmibol nem all ellene tenni valamit, akkor miert ne? Persze, ha egy 12 byte-os karakter tomb tele lesz kerdojellel, az mar eleg durva HW hiba lenne, arra nem lehet felkeszulni... De ez valoszinuleg nem is HW hiba.

Én csak olyan RAM-okról tudok, amik detektálni tudják a hibát paritás okánál fogva. Ettől függetlenül lehet hogy van olyan RAM-blokk ami képes javítani is, sok értelmét nem látom ennek.
Akkor megkérdezném, mennyivel jobb a helyzet, ha azért hibás a program működése, mert a bármi(??) miatt megsérült adat miatt helytelen működést kezd produkálni, vagy egy "toleráns" programozási szemlélet miatt nagyrészt elfeded a gondot, talán észre se veszed, hogy hülyeség van, mert az "intelligens" programozó mindent elkövetett azért, hogy a program látszólag helyes működést mutasson?!
Szerintem nincs értelme olyan funkcionalitást "adni" a biteknek, ami nincs bennük, tehát ha hiba van, akkor ott hardveres gondok vannak! Azt kell megszüntetni, és nem programból elfedni a hibát...
Természetesen mindez már rég nem érinti 12 byte hibáját, ez már egész másra vonatkozik...

Hiba nélküli program nincsen.
Talán elvétve űrtechnikában, katonai alkalmazásokban előfordulhat,
de valószínűleg ott is inkább stabil kódról lehet beszélni.
Minél nagyobb a kód, annál több hibát tartalmaz.

Ha az a cél, hogy egy előre nem látható hiba miatt összeomoljon a rendszer egy előre nem meghatározható időpontban, akkor nem kell kezelni az előre nem látható hibákat.

Ha azt szeretnénk, hogy a hibás állapot megszűnjön és az alkalmazás határozatlan ideig megint hibátlanul működjön, célszerű olyan programozási technikákat alkalmazni, amelyek ezt lehetővé teszik.
Ez nem holmi megvetendő trükközés, vagy szőnyeg alá söprés. Szükséges elővigyázatosság.

Más dolog elfedni a hibát(aminek meg sem kell történnie, tehát ha mégis, már itt kezdődik a gond...!), és más dolog detektálni azt, és annak megfelelően lépni! Nem ugyanaz!
Ez utóbbiak a hibakezelések, akár hardveres eredetű, akár logikai. De az semmire sem megoldás, hogy úgy tesz a program, mintha semmi sem történt volna, mert az okos programozó "előrelátóan" felkészítette bizonyos esetekre, ám erről senki sem tud, mert bár hibás módon, hibás adatokkal, vagy hibás logikával, de látszólag jól fut a keletkezett hiba ellenére is a program. Na erre mondtam én, hogy ez az igazi szivatós hiba....

Az a baj, hogy a kozmikus sugarzassal nehez mit kezdetni. Ha elolvasod a Wikipedia-n az ECC RAM oldalt, ott eleg sokat leirnak errol. Szamszeruleg is, hogy mennyi bithiba tortenik, meg sok mast is. Valoban nem a 12 byte-os tombrol beszelgetunk, csak ha valaki valaminek kapcsan olyasmit allit, ami nem igaz, akkor bele szoktam szolni az eredeti tematol fuggetlenul.

Na persze, kozmikus sugárzás )) Wikipédia....hát...khm..., na erről ennyit!
Nem is értem, hogy a világ összes számítástechnikai eszköze, hogy nem omlik össze azon nyomban, menthetetlenül a ko(z)mikus sugárzástól, biztosan valami csoda program fut mindegyik eszközben egytől egyig, vagy a sok buta adat nem tudja hogy hibás, és ezért mégis jól működik minden!