STM32F103, ADC gond

Adott egy STM32F103-as proci. Az egyik ADC csatornája szoftveres indítással mér. Azt vettem észre, néha kifagy a program, mégpedig azért, mert nem indul el a konverzió, hiába volt beállítva az SWSTART bit. Debuggerben ha ekkor bepöccintem kézzel ezt a bitet, akkor egy darabig fut megint rendesen a program, aztán egyszercsak megint megáll a futás, mert nem állítódott be az a bit.
Találkozott már valaki hasonlóval? Van erre valami épkézláb megoldás?
Jelenleg azzal próbálkozok, hogy egymás után kétszer állítom be a bitet..., egyelőre még nem volt egy fagyási eset sem így, de azért ez kicsit olyan elkenése a problémának érzetet vált ki bennem...

Nekem nem volt ilyen tapasztalatom. Sok évvel ezelőtt volt a kezemben STM32F103 (blue pill) és Keil alatt ilyeneket írtam:


A főprogram végtelen ciklusában így történt a mérés:


Bővebb információ: A 2019/2020-as évadból a 2019. december 5. előadás anyaga

Beállítás után ellenőrzöd bebillent-e? (esetleg a tesztelés erejéig...)

Nem nagyon lehet ezt. A beállítás szoftveres, de amint el indult a konverzió, hardveresen törli is.

Lényegében ugyanezt csinálom én is...
Van még egy STRT bit is(ADC_SR), ami elvileg hardveresen áll be amikor elindul a konverzió. Most ezzel tesztelem...

És ha nem kétszer írod a bitet, hanem az eredeti kódhoz képest csak raksz egy minimális időzítést, akár csak néhány utasítást a bit írása elé?

Biztosan nem vagy kezdő, de nincs másik task vagy interrupt, ami beleszól? Ha vannak taskok, akkor a driver vagy osztály, ami kezeli az ADC-t (feltételezem, nem te végzel mindent bitenként), ugyanazon a task-on lett inicializálva, ahol használod? Nincs valami ext trigger engedélyezve?

A helyzet az, hogy mindent én kezelek bitenként )) Tudom, kicsit mazochista, de nekem így kényelmesebb kézben tartani mindent...
Természetesen vannak megszakítások is(ez egy viszonylag összetett project), de ez a mérés a főprogramból hívódik meg, időről-időre. Megszakításból ezt az ADC-t nem használom.

És vajon eredeti az az ARM? : -) A Blue Pill miatt (meg ki tudja, még mi miatt) állítólag szeretik hamisítani, többször olvastam már... és az okozhat hasonló jelenségeket.

Hát azt meg nem mondom neked )) Kínából vettem, ID-ek alapján az..., hogy a specifikációt mindenben teljesíti e, ki tudja...?!

Baremetal tapasztalat van. Ha nem mukodik a tap IC, akkor hogy mukodik a rendszered ?

Szerintem arra gondolt hogy nem éri el a power management ic regisztereit mert a linux modul nem működik, nem látja a rendszer.

F103nál nem tudom hogyan van , de az F003-asnál az ADC frekijét trükkösen kell állitani. Hiába állitod be a megfelelő frekit, még arra is van egy külön bit hogy 14MHz felett vagy alatt. Na ott ha ezt elfelejtem, ilyesmiket csinál. Nálad valami ilyesmi nincs ? Egészen máshol, pl RCM-ben, ahol józan ésszel nem keresné az ember?

Úgy tudom, hogy F103-nál 14 MHz a maximális megengedett ADC órajel.

Jól tudod! Nálam ez 13MHz-re adódott...
Az a fura, hogy csak az ADC1 csinálta ezt, az ADC2 nem. Viszont a legutolsó módosításom óta stabilan megy, néhány nap alatt egyszer sem akadt el az indítás...

Az ADC órajele többnyire kisebb, mint a rendszer órajele, ezért van hozzá egy osztó is. A 103-asnál is van ilyen(2,4,6,8-as osztás), ami az APB2 előosztót tovább osztja...

Kortek kapacitív érintőképernyő vezérlő panel Flash

Sziasztok!
Segítséget szeretnék kérni egy Kortek márkájú érintőképernyő vezérlő panellel kapcsolatban.
PC-hez csatlakoztatva felismer egy USB beviteli eszközt külső kezelőeszközök csoportjában, de nem működik az érintő felület.
Van mód a lapon található NUC122ZD2 ARM újra flashelésével érintőképernyőként megfelelő HID eszközként való felismerésére?

Ha van hozzá szoftvered, akkor talán.
Érdeklődj a panel gyártójánál.

EBlink és újabb arm-none-eabi forditó ütközés

Sziasztok!
STM32G4 fejlesztéséhez Embitzet használok, beépített 9.3 GCC-vel. Tudom, hogy régi, de gyors és egyszerű. Most belefutottam egy olyan problémába, hogy az ST egyik minta-projektjét szeretném debugolni, ehhez újabb arm-none-eabi-gcc verzióra kellett váltanom. Az ST tündérbogyói nem adnak mindent forráskódban, hanem van pár előfordított lib (xyz.a), amit adott verziójú arm-none-eabi-val fordítottak, így nekem is ezt kell használnom, különben a fordításnál hibát kapok. A 13.1 verziót használom fordításhoz, és a beépített EBlink-et használnám debugra. Viszont az alábbi hibaüzenetet kapom:

EmBitz embedded firmware debugger for arm-none-eabi (Nov 13 2024/17:00:02).
Based on (GDB) 7.8.2 - License GPLv3+ by Gerard Zagema.
Reading symbols from bin/Debug/_STM32G473.elf...
(no debugging symbols found)...done.

Maximum debug infóval (-g3) és optimalizáció nélkül (-O0) fordítom, de mégsem működik. Arra gondoltam, hogy az újabb arm-none-eabi-ban más formátumú a debug információ (dwarf4 helyett dwarf5), és az EBlinkbe a GDB 7.8.2 be van drótozva, így esélytelen, hogy működjön. Az elérhető legújabb EBlinket használom (6.02). Valaki meg tudna ebben erősíteni, és inkább váltsak valami modernebb debuggerre? Vagy máshol van a hiba?
Tudom, hogy a CubeIDE kézenfekvő lenne, de inkább egy tüdőgyulladás.

Megoldódott?

Próbáltad a -gdwarf-4 compiler optionnel fordítani?

A strip ki van kapcsolva?

Sajnos nem oldódott meg, próbáltam a -gdwarf-4 kapcsolót is, semmi változás. A strip nálam sosincs bekapcsolva.
Az EBlink gyors és stabil, ezért szeretem, de már rég gondolkodom valami VSCode-os váltásban a vizuális élmény miatt. Ez most egy kis lökést adott.

Az EBlink fontos neked vagy az EmBitz IDE? Melyik szolgáltaltások azok, amik hiányoznak máshonnan?
Évekkel ezelőtt munkához is használtuk. Támogató előfizetéssel. De rettenetes lassan jöttek a frissítések, így váltottunk.
A CubeIDE legrosszabb tulajdonsága, hogy Eclipse. Azon kívül mindent támogat, amit az STM32 MCUk tudnak. RTOS debugtól kezdve az elő memóriaképen át mindent.
Kollégáim egy része CLion-t használ. Maga az IDE szuper. Beágyazott fejlesztéshez nekem nem jött be, mert nem teljeskörű az embedded debug támogatása. Legutóbb még nem volt live memory write, amit én intenzíven használok tesztelésre. Persze használhatsz mellette mást. EBLinket is vagy OpenOCD-t parancssorból. Idén nyártól non commercial esetben free a CLion.
Más részük VSCode-ot használ Cortex debug meg ST Cube pluginekkel. Szintén nem rossz, de ott sincs meg ugyanaz a szolgáltatási szint, mint a CubeIDE esetén. Memory Write szintén nem volt, mikor néztem. Ráadásul valami érthetetlen módon néha képtelen megtalálni a használt libeket. A fordítás működik, mert azt intézi a CMake, csak a VSCode mindent aláhúz pirossal, és nem lehet control klikkel követni egy adott szimbólumot. Már többen nekiugrottak nálunk a javításnak. Linuxon és Windowson is. Nem sikerült.
Nekem a legjobban a Visual Studio + VisualGDB plugin jön be. Maga az IDE szuper. A plugint aktívan fejlesztik. Itt a legjobb az IDE-n belüli támogatása a különféle embedded debug szolgáltaltásoknak. Attach to running target, live memory read/write, feltételes breakpointok, RTT view, live graph, többféle RTOS ismerete és monitorozása, statikus memóriahasználat analízis, stb. Amik persze mind elérhetőek parancssorból is. Csak így egy helyen látszik minden, frissül automatikusan, stb.
Szerencsére most már a legtöbb IDE-ben elég jó a CMake támogatás, így egy az egyben megeszik az általunk használt CMake projektet. Vagyis tökmindegy, hogy melyik fejlesztőnk melyik IDE-t használja. Pontosan ugyanaz a build mindenkinél a és a build szervereken is. Mikor legutóbb néztem az EmBitz még nem tudott ilyet.

Az EBLinket eddig csak Embitzben használtam, így erre nem tudok pontosan válaszolni. Az EBlink+Embitz páros mindig stabil és gyors: 3 másodperc, mire feláll a debug, van Live watch. A CubeIDE 15 másodperc, mire elér a használható debug nézetig és néha nem is akar csatlakozni. A program feltöltése sem valami gyors. Van egyáltalán Live watch? Egy projekt összerakása Embitzben kb fél óra, és simán múködik, vihető másik gépre. A CubeIDE-ben órákig tartott mire rájöttem, hogy az egyik gépen felépített CubeIDE projektet hogyan lehet átvinni Open/Importtal egy másik gépre, és ráadásul hibásan! Utólag kézzel kellett javítanom. Az indulási idő vetekszik a Windows boottal. Igaz, az indexelgetések után már begyorsul. Volt, hogy a program fordítás gomb nem működött. Ami Embitzben egy két menüpont mélyen van, az itt 5-6 menü mélységben; és rohadt sok menüpont van, aminek a fele szerintem logikátlan és értelmetlen (Eclipse). Még nem is említettem az MCSDK-ban generált projekt import rémálomról. A dark nézet neon-zöld betűi hosszú távon kiégetik a szemem, és a fene tudja, hogy egyáltalán lehet-e változtatni. A Projekt Explorerben nem könyvtári struktúra szerint látod a file-okat, hanem valami külön kitalált struktúra szerint. E miatt áttenni a projektet egy másik IDE-be baromi energiaigényes. A jobb klikk -> Go to definition gyakran nem működik. Ezek csak azok, amik most hirtelen eszembe jutottak.
Lehet, hogy a CubeIDE sokat tud, de ennyi kínlódás után már nincs energiám felfedezni. Inkább VSCode + valami extension (de nem az STM -féle), és legalább kipróbálok olyanokat, mint pl. Black Magic Probe (hardver), vagy a probe-rs (szoftver). Mert ugye a CubeIDE annyira zárt, hogy nem enged semmi ilyesmit.
Az Embitz kompakt, minden ott van, ahol kell, de elavult, nem jönnek rá frissítések. Ezért váltani kell.
A VSCode-ban egy használható IDE-t felépíteni, json-okat szerkesztgetni idő- és energiaigényes, de utána stabil. Sok lehetőség van: Cortex Debug, probe-rs (még alfa állapotban), BMP.
A VisualGDB-t próbáltam (fizetős). Tényleg szuper, de a Visual Studio bloatware baromságait nem bírtam megszokni.

Van esetleg build log ahol látszódnak a kapcsolók? A GCC és GDB verziók már megvannak .

Úgy emlékszem, hogy ha van debug infó az objectben, akkor a hexdumpnak az elején látszódik a fájl patha. Ezt érdemes lehet megnézni. Ha van az objectben debug info, akkor érdemes lehet tovább menni az .elf-re. Igazából azt szeretném kideríteni, hogy toolchain/options vagy GDB az issue.

Személy szerint nagy CMake fan vagyok. Az egyik korábbi munkahelyen volt szerencsém egy több millió soros, több architektúrás, több CPU-s, és több Linuxra építő projektet átírni makefileról CMake-re. Jó részt egyedül csináltam. Azon túl hogy végre absztrakt szinten lehet kezelni mindent (source, header, shared/static lib, objectek, optionök stb.) végre lehet használni C/C++ projekteken a clangd alapú LSP-t (Bővebben: Link), ami egy óriási előrelépés.

Ha már IDE kérdés, akkor emacs párti vagyok.