Szia!

Elsőre CubeMx a kiinduló pontom, utána pedig a további fejlesztésben az CubeIde programot használom.
Most is megpróbáltam a CubeIde-ből "javítgatni" a generált kódot, menteni a menthetőt, de nem jártam sikerrel.

Többször is ellenőriztem, ki van kapcsolva minden software packs. Ennek ellenére beteszi a a drivers/cmsis könyvtárba az dsp, rtos2 stb. könyvtárakat.

Ki fogom próbálni mindjárt az ötleted, hogy a teljes új projektet a CubeIde alól indítom. De félek, ezzel nem oldódik meg a problémám...

Szia!

Semmi titkos nincs benne. Leginkább gyakorlásnak szánom (vagyis szánnám) , és szeretném elemezni a DMA - i2c megszakítások működését.

Mx verzió 6.8.0
Ide verzió 1.12.0

Én a külön programot úgy értem, hogy a felhasználónak külön kell az oprendszerből indítania. A CubeIDE ugyan tényleg tartalmaz a plugins mappájában egy STM32CubeMX.jar fájlt, de azt már nem a felhasználó indítja el el, hanem a CubeIDE. Én azért szeretem elkülöníteni, mert félreértéseket okoz az, hogy az önálló CubeMX-ről, vagy az IDE-be beintegrált MX-ről van szó. Az önálló CubeMX ugyan tényleg tud a CubeIDE részére is projectet generálni, de ezt használni szerintem csak akkor van értelme, ha más fejlesztőeszközzel (is) szeretnénk dolgozni, nem csak a CubeIDE-vel.

Nem tudom mi lehet nálad a probléma, nálam hibátlanul működik az általad felrakott "redony_i2c.ioc". Semmi felesleges dolgot nem tett bele és nem is hiányol semmit.
Ahogy csináltam:
- CubeIDE / File / New / Stm32project from existing CubeMX ......
- kitallóztam a letöltési mappámból az ioc-t
- hagytam, hogy létrehozza az alapértelmezett project mappában a projectet
- fogaskerék ikon
- fordítás

S mi a CubeIde verziószámod?

Version: 1.12.0
Build: 14980_20230301_1550 (UTC)
Még egy ötlet: nincs a projected útvonalában ékezetes betű, szóköz vagy hasonló (sok program által nem szeretett) karakter?

Jár a sör neked!

Megcsináltam amit javasoltál, .... s jött a csoda! CMCIS nélkül generálta a kódot a teljesen új projekt, amit a CubeIde-ból indítottam!

(Zárójelben:
Csináltam egy teljesen új és egyszerű ioc fájlt a CubeMx-ben, s abból generáltam egy kódot.
A Mx beteszi abba is azt az átkozott RTOS2 könyvtárat. Ebből arra gondolok, hogy az Mx résszel van baj.
Csak tanulságképpen írtam le.)

Szóval köszönöm az ötletet és a fáradságod!
A sör jár, szólj mikor jársz a Budapest XIII kerületében!

Üdv!
Z.

Kíváncsiságból kipróbáltam az önálló CubeMX-et is, nálam azzal is hibátlan. Az MX verzióm eredetileg régebbi volt, de a próba előtt frissítettem így a próba a v6.8.0-val volt.

Igen, két független eszköz küld egy F103C8T6-nak adatokat soros vonalon. A két eszköz adat küldése véletlenszerű.

Mekkora sebességgel jönnek azok az adatok?

UART1 115200
UART2 9600

Ezzel a sebességgel még megszakításban is simán megbirkózik, bár a DMA-t sem nagy dolog beállítani hozzá. Ha folyamatos az adatáramlás, akkor az UART1-nél van kb 100usec időd arra, hogy a beérkezett adatot kiolvasd, ezt a proci röhögve meg tudja csinálni.

Sziasztok!
Remélem jó helyen járok.
Van egy GD32F130C6T6-al szerelt hoverboard vezérlőm.(igazából több is, de nem mertem a többivel kísérletezni még).
Amikor programot szerettem volna rá tölteni, akkor az alábbi hibát dobta.
Próbáltam több programmal, de ugyanaz az eredmény.
Mi lehet a probléma?
A program
A segítséget Köszönöm!
Szerk.: ST-link V2-m van, azzal próbálkoztam. ( kis USB pendrive méretű)

A most benne lévő programot ki tudod olvasni? Ha nem, akkor nincs véletlenül aktiválva a flash védelem?
Próbáltad törölni a flasht? Ha nem, próbálj meg egy chip eraset!
Lehet, hogy low power módban van az MCU? Akkor connect under reset a megoldás. De ehhez olyan programozó kell, aminek van reset kimenete, és azt rá kell kötni a cél MCU reset bemenetére. A pendrive alakú, hamis ST-Linken nincs SWD reset kimenet. Vagy veszel rendes ST-Linket, vagy erre barkácsolsz reset kimenetet.
Aztán az is simán lehet, hogy az STM, mint cég nem támogatja, hogy klónokat programozz az eszközeivel.

Aktiválva volt a védelem azt disable-ra állítottam, ezután ki tudta olvasni az üres MCU t. ( teli van F- el).
Kipróbáltam a chip erase-t is, de feltöltéskor ugyanaz a probléma.
Honnan tudom, hogy az MCU "low power" módban van?
Az SWD reset doldognak utánanézek jól hangzik.
(Ha jól emlékszem régebben "programoztam" ezzel gd32 es MCUt).
Kösz a segítséget!

st link v2 reset.
Itt úgy látom van rajta reset láb, vagy ez a klónon nem működik?

Ez a klón. Az eredeti ST-Link nem így néz ki.
A rajta lévő reset kimenet az STM8 sorozat SWIM interfészéhez van. STM32 programozásakor másik lábon adja ki a resetet a programozóba épített STM32F103 (vagy 101), de az itt nincs kivezetve. Megteheted, hogy szétszeded, és kivezeted a resetet.

Például itt van hozzá leírás: Bővebben: Link

Ja értem, köszönöm.
Akkor ezt az SWO kimenet kell majd az MCU reset bemenetére kötnöm? Jól értem?
Szerk.: közben látom amit linkeltél ott plusz egy pin lett bekötve (18-as láb) az viszont már reset láb, akkor azt kell majd.
Az swo ahogy nézem az más.

Nem, a SWO az egy plusz láb debuggoláshoz.

Nos ma este volt egy kis időm, megcsináltam a módosítást, de továbbra is ugyanaz a probléma.
Viszont mókoltam egy Keil nevezetű programmal, ott beállítottam a programozót (reset lábat nem kötöttem be), majd ezen keresztül sikerült felprogramoznom az MCU-t.
Így kipróbálva ismét az ST link programmal ismételten hibát dob rá.
Ezek után feltelepítettem egy másik gépre is az ST szoftvert, de ugyanaz a probléma.

Üdv

Szerintetek lehet egy nokia lcd-t ami spi-komunikál és egy hagyományos 16x2-es lcd-t ami i2c-n kommunikál egyszerre meghajtani? Mindezt egy nucleo 64 R302-n arduino ide-vel csinálnám. Van erre mintakód valahol?

"Egyszerre" nyilván nem, de egymás után külön külön nyilván megy , ha két különböző perifériának "minősül" , nincs átfedés a portok kiosztása között. Szerintem ha ha találsz 1-1 mintaprogit, simán összefésülöd és kész.

Amikor csak 2 I2C kijelző volt azt aránylag könnyű meghajtani egyszerre de egy i2C és egy spi már más tészta

Nem értem miért? lesz 2 kiíró függvénycsoportod, az egyik az i2c kijelzőhöz, a másik az SPI-hez.
Teljesen függetlenek egymástól.

Sziasztok! ARM flash kérdésem lenne. Tapasztalt már valaki olyat, hogy túl sokszor írta a flasht és amiatt lehalt a mikrokontroller?

Mit jelent a sokszor? A mai mikrovezérlők ritkán mennek le 1000 ciklusig, inkább 10k szokott lenni a többség.
De az adatlapban ezt jellemzően meg szokás adni, hány ciklust garantálnak....
És még akkor is csak csekély valószínűséggel lesz belőle gond, ha elérted a gyári értéket....(nagy a tartalék hétköznapi körülmények között)

Igen. A program memória utolsó lapját használtam adattárolásra, és évek alatt tönkre írta a program. Nem cseréltem procit, hanem módosítottam a programot, hogy az utolsó előtti lapot használja, és kevesebbet írjon.

Van egy kínai HMI készülékünk. 2-3 hónap használatig nincs vele gond. De mivel áramszünet esetére meg kell őrízni a gépészeti adatokat, célszerűnek tűnt egy egyszerű "ON" -al bekapcsolni, hogy ő tárolja el ezeket. A gyártó azt írja 100.000 ciklust bír. Kicsit nehezen tudom elhinni, hogy 3 hóna alatt összejött volna, de ez az egy magyarázat van arra, ami tényleg elfogadható, hogy miért cseréljük a harmadikat... Lehet, hogy olcsóbb lesz egy szünetmentes megoldás.

Durván, ahhoz, hogy 3 hónap alatt elérjük a 100k ciklust, nagyjából percenként kellene eseménynek történnie! Ez elég valószínűtlennek tűnik, áramszünethez kötve mindenképpen...
Inkább azt feltételezem, hogy teljesen feleslegesen van írva a mentési terület, vagy sokkal gyakrabban keletkező kiváltó ok miatt, vagy valami timer alapú időzítés okánál fogva.
Ott valami nagyon nem úgy működik, mint ahogy feltételezitek, az a gyanúm....