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.