Fórum témák
» Több friss téma |
Úgy tűnik, tévedtem. Nem elvből nem gyártják, hanem gyakorlatilag...
 Kevés helyen van maradék arany áron, a nagyoknál nincs, és éven túli határidőket adnak meg. Farnell, Digikey, LCSC. A Mouser 52 hetet jelez.
Ez hónapok óta tartó probléma. Globális chiphiány. Több autógyár is leállt 1-2 hétre már emiatt. Topinak van is egy cikke ezzel kapcsolatban itt a fórumon.
Egyik STM32 mikrokontrollert sem kapni. Ahogy szinte semmit sem. Gyártják folyamatosan, de az előrendelőket szolgálják ki, akikkel szerződésben állnak, a boltokba nem jut.
Sziasztok, STM32F446RE, CubeIDE, HAL környezetben próbálom megoldani, hogy ADC-vel 4096 mintát vegyek másodpercenként, DMA-val bepakoljam egy bufferbe cirkulárisan és ha a buffer félig,teljesen megtelt, akkor kapjak róla megszakítást. Addig eljutottam, hogy megy a timer ami előidéz 4096 megszakítást másodpercenként, de az ADC vagy a DMA már nem megy és nem látom miért. Előre is köszönöm a segítséget.
Szerintem keres rá példát a neten!
Pl.: Bővebben: Link
Csak kis szösszenet, hátha valaki belefut szintén:
GD32f130, adc konverzió, simán potméterrel. Óriási offset volt, földre kötve a bemenetet is 70 körül mutatott. A neten kutakodva kiderült, hogy a debugolásra használt UART egy ftdi232-n keresztül kapcsolódott a pc-hez, aminek a tx lába ugye 5V-on dolgozott. Ez valami plusz feszt vitt be. Az átalakítót megcsináltam jumperelhetőre, ha a VccIO 3.3-on megy, minden tökéletes.
Jó link, egy beállítás nem volt jó, pedig az ST példaprogramokon indultam el. Most már működik szépen ahogy vártam. Köszönöm.
Sziasztok,
Bootloader, start application problemaba utkoztem. MCU STM32H7A /B. Kulon kulon a sajat bootloader es az alkalmazas is mukodik. CubeIDE-bol futtatva a bootloadert elinditja az alkalmazast, mukodik. IDE nelkul inditva a bootloader sem indul el, csak akkor ha kikommentelem a Jump() hivast es ujraprogramozom a mcu-t.. Ha a bootloadert inditom IDE-bol a Jump() hivassal egyutt es az IDE-bol rst-elem a mcu-t akkor a hardfault handlerre ugrik. Mi lehet a problema ? Udv. ps: Ha CubeProgrammer-bol ujraprogramozom mindket binarissal, es a BL feltoltesenel beallitom hogy inditson a feltoltes utan, akkor mukodik, egyszer. A hozzászólás módosítva: Márc 22, 2022
Hali..
STM32 procin játszom és sajnos PWM kimenetnél van egy kis problémám. Komplementer kimenetem van és játszom a kimenetek kikapcsolásával ezt a TIM1 capture/compare enable register (TIM1_CCER) regiszterben próbálom megoldani. Vane gy ilyen regiszter hogy: CC1NE: Capture/Compare 1 complementary output enable CC1PNE: Capture/Compare 1 complementary output enable Elvileg ezekkel lehet a kimeneteket direktbe ki-be kacsolni. A problémám az hogy ha bekapcsolom minden oké megy a PWM a kimeneten 0-3,3V logikai jellel. Viszont ha nullára állítom akkor nem aktív 0V ot vesz fel hanem valamiféle High-Z kb 1,6V-ot amibe belezavarodik a mosfet driverem és simán bepacsolva hagyja a fetet. Akárhogyan böngészem az adatlapot nem értem miért nem aktív 0-ra teszi a kimenetet. Gondoltam rá hogy hagyom ezt a regiszter kapcsolgatását és simán átnyomom a két proci láb típusát alternate-ből logikai kimenetbe és ott 0-ra állítom utána meg vissza AF1 PWM mode ba de az olyan eeeee megoldás. Nem igaz hogy nem lehet valahogyan megoldani. Valami ötlet esetleg valakinek?
A hozzászólás módosítva: Márc 31, 2022
Szia. Nem tudom pont melyik STM ről van szó, de pl. az STM32 F10x referencia lapon a 355. oldalon van egy táblázat ami a kimenet állapotát írja le attól függően hogy mely regiszterek hogyan állnak. Próbáltad a MOE bit -el a BDTR regiszterben kikapcsolni? Nézz rá az OSSR és OSSI bitek -re is.
A MOE bitet nem próbáltam de igen pont azt a táblázatot nézegettem. Nem épp 103-as proci hanem 030-as de kb ugyan az a kettő. Szóval próbálgattam állítani a OSSR ISSI biteket de látszólag semmi nem változott. Én viszont külön is szeretném pket ki be kacsolni. PL h az neminvertáltat akarom kikapcsolni akkor arra számítanék hogy az a kimenet PWM helyett pl aktív nullára áll. Ehelyett mintha teljesen leválasztaná azt a lábat mindenről és csak lebeg.
Lehet hogy butaságot mondtam, most olvasom hogy Alternate módban
Idézet: habár úgy rémlett hogy a Cube pull-up + alternate ra állította be az UART perifériát (lehet csak az RX?). (én is csak ismerkedem az STM32 világgal) „The weak pull-up and pull-down resistors are disabled. ”  Esetleg nézd meg hogy open drain vagy push-pull e a kimenet, az utóbbiban nem szabadna hogy lebegjen. Lehet hogy előkotrom a Nucleo kártyám, érdekel a megoldás. A hozzászólás módosítva: Ápr 6, 2022
Lehúztam, de határeset. Az a helyzet az csak egy 30-0k ellenállás és nem eléggé stabil. Működött úgy de megmérve szkóppal a 1,6V középérték lehúzóval kb 0,8V ig megy le. Szóval nem teljesen megnyugtató de am jó ötlet lenne. Jelenleg beraktam plusz pár sor kódot amivel átnyomom normál kimenetbe és ott 0-ra van állítva alapban. Ha PWM kell akkor meg visszkapcsolom AF módba a lábat. Nem túl elegáns de egyenlőre ezt tudom.
A hozzászólás módosítva: Ápr 7, 2022
Szerintem a CCMR1 regiszter OCM1 regisztercsoporttal kéne állítanod. Ezzel tudod fix értékre állítani a kimenetet függetlenül a számlálótól. De maradhat alternatív io módban.
Üdv!
Azt a jelenséget vettem észre, hogy minden újraprogramozás után, mikor elindul a program, nem a megfelelő frekvencián működik a proci! Ha ezek után nyomok egy reset gombot a panelen, akkor beáll a megfelelőre. Ezt először egy 407-es ST procinál láttam, de most egy 303-as is hasonlót produkál. A programozás ST-Link segítségével történik. 4 vezeték van csak bekötve(mint a blue-pill nél). Mi az oka ennek? Ha szoftveres resetet kap, akkor nem pont ugyanúgy indul, mintha hardverest kapna?! (nyilván most nem egyes ezzel kapcsolatos flag-ekre gondolok)
Ha a reset is be lenne kötve a programozóba, akkor valószínűleg jól indulna.
Kérdés, hogy az ST-Link protokoll hogy működik. Hogy a végén szoftveres resetet kér, vagy csak simán a reset handlerre ugrik. Az utóbbi esetben nem resetelődnek a perifériák. Ha jól tudom, a protokoll nem nyilvános, de javítsatok ki, ha tévedek!
A nem megfelelőt kifejted bővebben?
Nem megfelelő clock source (pl. Belső RC-n fut, külső kristály helyett)? Külső kristály, de rossz PLL konfiggal indul? Vagy helytelen PLL lock van?
Csak azt láttam, hogy a külső láb frekvenciája megváltozott olyankor! Ezen keresztül mértem a végrehajtási időket, innen tudom, hogy megváltozott az órajel... De hogy mire, vagy miért..., azt nem értem!
Szerintem biztosan nem helytelen lock van, mert ez rendesen le van kezelve, és minden utána következő újraindulásnál korrekt minden! Közben kiderítettem mi okozza ezt. Van a beállításoknál olyan pipálható lehetőség, hogy resetelje programozás előtt és után is... Ha azt pipálom be, hogy utána is legyen reset, akkor van ez a jelenség! Ha kiveszem innét a pipát, akkor úgy tűnik jók a frekvenciák programozás után is azonnal...
Azt nem írtad mivel fejlesztesz, de a CubeIde a main.c-ben létrehoz egy SystemClock_Config nevű függvényt, amit a main függvényből meg is hív. Ennek a dolga az órajelek beállítása, mert reset után a proci a belső "HSI RC" oszcillátorról indul.
Minden órajelet a main függvényen belül állítok be, regiszter szinten! Ezt nem kerülheti ki semmilyen trükkös indítás, mert akkor a program sem futhatna...
Egyébként VS alól, VisualGDB plugint használva... Idézet: „külső láb frekvenciája” MCO-n méred, vagy XTAL lábon láttál változást?
Igen, azt is kivezettem, és látható volt rajta a más érték! Ahogyan a TIM1-es jelét is kivezettem, és ezzel összhangban ott is más volt a frekvencia...
Akkor, hogy egyértelműsítsük
Az XTAL-on rendesen a névlegeset mérted (a kristály névleges frekvenciáját), de az MCO-n más freki jött ki? Igaz?
Nyilván! A kvarc nem fog más frekvencián rezegni, az biztos...
Sajnos volt már rá példa, egy egész gyártási sorozatból kellett kiszedni 24MHz-es kristályt, mert hiába a parallel 1M-s ellenállással segített visszacsatolás, 100 panelből 2-3-on 22M körül állt be. Egyértelmű gyártási hiba, szóval sosem szabad 100%-ig biztosnak lenni ebben
CSS közbe szólhat. Nézd meg a Clock Security System regisztereit, vagy dobj egy kódrészletet a NMI_Handler-be. Lehet hogy clock-safe módba lép a proci és HSI-ről indul el. (+ RCC_CIR reg.)
Az oszci hibát kizárnám, lásd kézi reset után jól működik mindig! )
Arra viszont már én is gyanakodtam, hogy talán a konfiguráló kód ellenére olyankor átkapcsolódik a belső órajelre... Bár, ha ebből eredne, akko alig kellene lássak különbséget, hisz 8MHz-es mindkettő, csak a belső kicsit pontatlanabb... De ezt a kis különbséget nem vettem volna észre szemmel... Itt 1,2...1,5 szörös eltérésről van szó kb... Mivel a jelenség 2 (teljesen)különböző procinál is fennállt, és a pipa kivétele után legalábbis az aktuálisan használtnál egyértelműen megszűnt a jelenség, így nem foglalkoztam vele tovább, hogy aprólékosabban kivizsgáljam azt...
Újabb érdekes jelenségbe futottam bele...
STM32, TIM3... Felkonfigurálom elementárisan, előosztót, periódust állítok mindössze, majd engedélyezem, és egy végtelen hurokban figyelem a túlcsordulást jelző flag-et, amikor is negálom az egyik portláb állapotát. Azt vettem észre, a legelső túlcsordulás nem akkor következik be, amikor kellene, hanem jóval korábban. A továbbiak már rendben a megfelelő időben jönnek. De az első, az mindig határozott időben, de teljesen rosszul jön. Mi okozza ezt? Idézet: „a legelső túlcsordulás nem akkor következik be, amikor kellene, hanem jóval korábban” Időben korábban? Ez mindig ugyanannyi? Számláló értéke rendben? |
Bejelentkezés
Hirdetés |
