Sok flash memoriaban tárolt és mindig flashre mutató static const char* pointerem van, ami sok helyet foglal, mert 32bitesek a pointerek. A flash maga csak 32kB, tehát 16 bites pointerek is lehetnének. Lehet csökkenteni a méretüket valahogy 16 bitre?

base és alma típusa bármi lehet. Ha tudod mire van mappelve a flash címe, akkor konstans számot is használhatsz a basePtr helyett. És akkor az offset tuti pozitív lesz, lehet uint16_t-re is kasztolni.
C-ben a pointerek is csak számok, lehet aritmetikát végezni velük, illetve számmá castolni és vissza, csak ismerni kell az architektúrát, hogy mi működik és mi nem. Ha a pointer nem char típusú, akkor a kivonás és hozzáadás akkora egységekben történik, amire mutat a pointer, erre figyelni kell, ezt el lehet rontani. De nyerni is lehet vele, ha mondjuk 4 bájtos egységeid vannak (pl uint32_t), akkor 2 bájtos címmel 256 kB-ot is tudsz címezni.

Azt azért érdemes megnézni, hogy a pointerenkénti 2 bájt nyereség nem úszik-e el a 16 bites pointer felhasználásához szükséges bonyolultabb (és ez miatt hosszabb) kód miatt.

Ezt a csodálatos hibaüzenetet kapom időnként fordításnál. Majd elmondom miért nem értem, de először is, pontosan mi baja is van a write_RealTime-al?
.\Objects\jcd.axf: Error: L6286E: Relocation #REL:5 in jcd1.o(.text.write_RealTime) with respect to Veneer$$LitPool. Value(0xfffff543) out of range(0 - 0xff) for (R_ARM_THM_PC8)

Még ha fix cimre rakom is, az 5-ös sorra "initializer element is not a compile-time constant" a forditó reakciója.

MCU folyamatosan újraindul

Sziasztok.

Elsőnek fejlesztek egy vezérlőt STM32G474 procival.

Nagyon nehezen sikerül még egy ledet is villogtatnom mert sokszor el sem indult a program.
Már leszedtem mindent csak egy LED van és azt akarom pörgetni.
Sikerült oda eljutnom hogy a program elindul de szabályosan 400msec után újra újra indul.

Elszórakoztam vele újabb 3 órát és az megoldotta az folyamatos restartot hogy bekapcsoltam az options byte ben a WWDG_SW és IWDG_SW biteke.

A kérdésem annyi lenne hogy mit csinálnak ezek a bitek és miért működik a program ezekkel és nélkülük miért nem?

köszi

Azért indul újra, mert ez az elvárt működés.
Bővebben: Datasheet 3.24.6 és 3.24.7
A pipa azt jelenti a kétféle watchdog előtt, hogy szoftverből kapcsolod be őket. Ha nincs pipa, akkor automatikusan indulnak. Mivel nem eteted őket, az idő lejártával újraindítják a mikrokontrollert.
Bővebben: Reference manual 42.3.3 és 43.3.2

Értem, köszönöm szépen!

Stop MODE magas áram fogyasztás

Sziasztok.

Olyan kérdésem lenne hogy még mindig STM32G474 procis fejlesztéssel bajlódok.

A problémám az hogy próbálom a lehető leg alacsonyabb fogyasztás kihozni ehhez Stop módba léptetem a procit.
A baj ott van hogy maga a leállítási rutin ránézésre jól megy.
Ha a main() ből hívom elő akkor szépen leáll és kb 50uA a fogyasztás ami teljesen OK.
Ha viszont bármelyik interrupt megszakítátsból próbálom akkor 1mA.

Legyen az TIMER vagy EXTI nyomógomb bemenet megszakítás mindenhol ez van.

Jelenleg azt csináltam vészmegoldásnak hogy beraktam egy stop_mode=1; sort a megszításba és amikor kilép a program a megszakításból és folytatja a dolgát a main() részben ott egy if(stop_mode) feltételben indítom a leállítást.

Így úgymond működik az interrupt lefutása után main() ből indítva végülis jól leáll a proci csak nem értem tisztán interuptban futtatva miért nem megy jól?

Olvastad a dokumentációt? Nem szabad ISR-ből stopba küldeni, csak a main-ből.
A HAL-os enterStop függvény meghívja a Wait For Interrupt függvényt, aminek nem lesz jó vége, ha már eleve ISR-ben vagy.
Szóval jól csinálod: Az ISR-ben beállítasz egy flaget, amit a main loopban figyelsz.

Oké köszi olvasgatom folyamatosan de ezt nem tudtam.

ARM-on futó Linuxszal van valakinek mélyebb tapasztalata? Lenne egy Allwinner cuccom, amin már fut egy Arch, de a táp IC-t (AXP20*) nem sikerül életre keltenem.

ARM kvarc stabilitás

A véleményetekre vagyok kiváncsi. Feltártunk egy hibát, a proci kvarcoszcillátora érzékeny az ipari zajokra. Pontosabban, hardfaultokat kapunk, RC oszcillátorral meg nem. 24.000MHz 20pF-es YIC kvarc, 22pF kondikkal, a mért frekvencia 23.998 , a digitális szkóp szerint (hogy ez mennyire pontosan mér azt ki tudja.) 15pF-el hozza 24.000-t vagy 24.001-t. A jel amúgy gyönyörű szinuszos, gyorsan indul, instabilitásra utaló jel tehát nincs. Van tapasztalat, 15pF-ekkel csökkenne a zajérzékenység? Számit ennyi?
(Zaj az van gazdagon, a külső megszakitások is meghúznak, aztán mire nézem a szintjüket, már nincs semmi. Valami nagy jelfelfutási sebességű impulzus. Ritka, nem sikerült megfogni méréssel. )

Első körben a tápellátás körül keresgélj, ha random IRQ-k is vannak, ne kristály oldalon.
Utána nézd meg, hogy a 24MHz-es oszcillátornál biztosan jó-e a feszültségszint, előfordulhat, hogy illesztetlenség miatt túl alacsony vagy túl magas az amplitúdó. Érdemes szabályzott impedanciát létrehozni úgy, hogy az XTALO/XO/tehát az output lábra 10 Ohm ellenállással jössz ki a prociból, csökkentve a CMOS kimenet meredekségét, ami felharmonikust üthet az oszcillátornál.
Tápon is használj láncban több elemű szűrőkondi sort, 100nF/10nF/1nF/100pF mert mindegyiknek más a szerepe, máshol vág.
A kristály kapacitásainak hangolásával csak indirekt hatása van a zajérzékenységre, ehelyett elrontod / javítod az oszcillátor amplitúdóját, növeled a dinamika tartományt, vagy csökkented a túlvezérlését a CMOS oszcillátor inputnak.

Először táp, szkópos vizsgálat AC csatolva, szkóp mérőfej rugós földelővel (nem saját földelő krokijával), majd utána amplitúdó vizsgálat az oszcillátornál.

Info: Itthon próbapadon ugyanolyan berendezéssel semmi baja, csakis a helyszinen. Ott mérni nem tudunk, lehetetlen helyeken vannak. RC osc megoldja. Ez a nehézség.

A táp engem is zavar, bár még sehogy sem tudtunk hibát találni benne. Tiszta, stabil. Hegesztettem tőle pár centire, kondis csatolással próbáltam tüskét vinni bele stb.
Van valami jó ötlet h hogyan tudnánk házilag generálni a hibajelenséget?
(A táprendszer felépitése: SK34 dioda forditott bekötés ellen, utána DC konverter 24Vről 5Vre, LDO 4.15V, a proci előtt 10R előtétellenállás(hogy 4.096 legyen), 10uF, 100nF, 10nF hidegités. Csillag Gnd természetesen, az AD mérés nagyon szép zajmentes.)

Jól értem, hogy a proci tápja egy 10 Ohm-os ellenálláson eső feszültséggel van szabályozva? Ha ez így van, dobd ki nagyon-nagyon gyorsan onnan, és csináld meg rendesen a tápot. Kondenzátor nem fogja megjavítani a tönkretett 10 Ohm-os tápegység impedanciát. 10 ohm-os soros impedanciával a mikrovezérlő nem fog tudni hirtelen áramokat felvenni, még megkondizva sem.

Ha az ADC miatt kell 4.096V akkor csináld meg a ref fesztültséget csak az ADC-nek pl. TL431-el tápláld be neki a VREF-be, a procit meg egy másik tápról járasd. Amúgy milyen ARM hogy 5V-os? (hogy elviseli egyáltalán a 4.096V-ot?).

Ez így eléggé nem szerencsés tápellátás!
Gondolj bele, van egy 2mA-es átlagos fogyasztás, ami 10R-en ejt kb 20mV-ot. Biztos vagy abban, hogy mérések közben is csak ennyi a fogyasztás? Szinte biztos hogy nem... Így a táp és a referencia is meghatározhatatlan módon úszkál, csak a szerencsén és a csillagok együttállásán múlik, mit kapsz...
A digitális táp viszonylag igénytelen lehet, oda nagy stabilitás nem kell, viszont kis impedancia igen! Főleg impulzusokra...
Van egy analóg táp(láb) is, na ide célszerű stabil, kis zajú tápellátást kialakítani, min hatásos szűréssel, még jobb ha LDO-val van megcsinálva.
Ebben az elrendezésben nem nagyon fog függeni a konkrét fogyasztástól a mért érték.

A konkrét problémádra... A kvarcoszcillátor bemenete nagy impedanciás. Ott nem nehéz egy masszív elektromágneses impulzussal kiütni egy pillanatra az oszcillátort. RC oszcillátornál nagy impedancia nincs, ezért sem jelentkezik az effektus! Ráadásul az utóbbi belül van, minimális vezetékhossz adódik hozzá, míg a kvarchoz külsőleg kell eljutni, nagyságrenddel nagyobb úthossz adódik hozzá...így ennyivel(+a nagy impedancia) könnyebb ott megzavarni!
Ha mindenképpen kell a kvarcstabilitás, akkor lehet próbálkozni mechanikus árnyékolással..., vagy külső oszcillátort lehet alkalmazni, közel a mikrovezérlőhöz, kisimpedanciás meghajtással....

APM32F003. Nincs külön Vref lába. Értem mindkettőtök aggodalmát a 10R miatt, egy baj van, ha kiveszem se történik javulás, csak a ref lesz pontatlanabb. Szóval nem ő a felelős.
A cortex mag külön ic-n belüli ldo-ról megy, annak külön hidegitői vannak stb. A 4V gyakorlatilag csak a GPIO, meg a ADC.

A válaszomnak nem a 10R problematikája volt a lényege!

Ha a kvarcos részre gondolsz, az is folyamatban van. De ott nagyon lassú minden változtatás. Csak míg felszerelik és tapasztalat lesz, az is hetek.
Ha pedig a táp és ref részre gondolsz, sajnos nincs külön láb, így pont a 10R-es megoldás lett a kompromisszum. Az eszközök nagy részénél kitűnő is. Csak az a pár helyszín ne lenne...

Ha fix a design/doboz/stb akkor dobj hozzá két ground plane-t a nyákhoz és gyártasd újra 4 rétegen. Minden marad ugyan ott, csak középen két ground plane.

Ha nem fix a hiba, akkor a krisály impedancia illesztését és odavezetését javítsd ki (növeld a XTALO kimeneti impedanciát soros ellenállással és csökkentsd a hurokerősítést a kristályra párhuzamos 1M-val) és a tápot mindenképp. Mindegyik kelleni fog a megoldáshoz.

Ha nem csinálod meg normálisan és csak tapaszolod, akkor még random memória hibád is lesz. Ha az IRQ-k fantom meghúznak akkor táp hibád is van, fogadd el.

Átnéztem a szoftvert, ha a 10R kikerül, egy kis osztás/szorzásra az AD-nél még van gépidő. Ennyi forrasztgatás még belefér a melóba(600db van). A kvarc sajnos csak a következő projektbe. Minél többet olvasok róla, annál nagyobb falatnak látom. Itt most RC oszcillátor lesz.

Mi van ha a 10R helyére ferritet rakok, nem rövidzárat (0805) ? Arról van igazolt tapasztalat, vagy csak mindenki beszórja rutinból ?

Haladunk Csak nézd meg, hogy kb olyan 1-2MHz-es tartományon mi az alkalmazott ferrit ellenállása (ha meg van adva). Mert DC ellenállásuk alacsony ugyan, de frekvencia növekedésével nagyban nő az ellenállásuk is. De DC ellenállásuk se legyen nagyobb 5-600 mOhm-nál.
És érdemes Pi szűrő konfigurációban alkalmazni.

Ilyenem van itthon: Viking CBM03YTAN102-1 1kOhm /100MHz, DCR 0.25, adatlap sem ír más adatot róla. De ami nekem nem világos: mondjuk hogy a táp felől jövő zajt megszűri, oké. De nagy frekin gondolom már nagyobb impedanciája van mint az eredeti 10R-nek.(Adatlapon miért is lenne impedancia-freki görbe) Akkor ugyanúgy nem teljesül a táp felőli kis impedancia feltétele az órajel freki környékén, vagy már alatta sem ...

A kérdésed részben már tartalmazza is a választ. DC-n 0.25 Ohm (azaz kis ellenállás), de ahogy mész fel frekiben, egyre nagyobb ellenállása lesz. Míg a sima 10 Ohm-osod elvi szinten minden frekvencián 10 Ohm. Persze valóságban soros induktivitása is van egy sima 10 Ohm-osnak is.

Ferrit a DC-n kis ellenállásnak köszönhetően a kondit ha kisütöd, akkor nagyon gyorsan vissza tudja tölteni a hiányzó töltést, míg a 10 Ohm-osod csak lassan tölti vissza az impulzus fogyasztás miatt kiürült kondikat a proci mint fogyasztó oldalon.
Nem utolsó sorban a növekvő frekvencia esetén növekvő ellenállás (impedancia itt már inkább) segít abban, hogy mindkét irányba megfogja a tüske zajokat. Táptól sem tud menni a proci felé, és prociból sem tud menni táp és más részek felé.

Tüske fogyasztást továbbra is az utána elhelyezett kondik tudják csak fedezni, de nem mindegy, hogy a kondikból kiszívott energiát milyen gyorsan tudod visszatáplálni bele. Alacsony DC ellenállás előbb vissza tudja tölteni, de az induktív jellege miatt a tüskék mégsem mennek át rajta olyan egyszerűen, ott csillapítása lesz.

Jó rég volt, de ha aktuális még, akkor rájöttem mi az oka: a címek a fordító kimenetben még változók és a relokáció során lesz belőlük fix cím (architektúrafüggő, hogy milyen paranccsal történik, de ez mindenképpen egy külön lépés a fordítás után), és emiatt a fordító nem tudja kezelni ezt az esetet, nem tud konstanst csinálni belőle.

Ahogy meg lehet oldani, ha mindent egy struktúrába teszel, és azon belül offsetof-fal lekéred az offsetet, és azt kasztolod 16 bitre. Ennek már működni kell tényleg. És a struktúrának van egy kezdőcíme, ami 32 bites lesz.

Mindig minden aktuális, legfeljebb a következő projektben lesz használva Igen, ez valóban jónak tűnik. Én meg sokat nézegettem közben a disassemblyt, és nem feltétlenül pointerek ezek, hanem a nyelv és a forditó sajátsága. A globális változók cimét rakja a függvény után egy listába, és onnan pc relativan olvassa be őket. Mert annyira risc hogy nincs is más utasitása rá. Persze mind "feleslegesen" 0x2000-el kezdődik (ram báziscime). Flashnél is megvan ugyanez a logika, 0x0000-val.

Vajon miért nem tudok képet felrakni? 14kB jpeg, semmi trükk. Szkóp felvétel.

Szóval mi a jobb a tápon? 10mV beütések(10R) vagy 8 mV beütések + 6mV nagyfrekis zaj (ferrit)? Mert ennyi van összesen, legalábbis itt a próbapadon.