Szia!

Köszi, most már tudom, hogy így hívják a programozót
Mi a különbség az általad linkelt és EZ a programozó között? Nekem nem tűnik fel semmi!
Attól függetlenül, hogy nem látom a support listában, támogatja az Atollic-et is mindkettő vagy nem?
Ha megerősíted,akkor megy a rendelés.

Szerintem is egyformák.
Igen!

Bővebben: Hozzávalók

Köszönöm a segítséget mindkettőtöknek!
Ment megrendelés.
Majd jelentkezek,ha megjött a cucc és elakadtam, amiben sajnos biztos vagyok.

Tudna valaki linkelni egy működő READ protection kódot? Kb 1 teljes napom ment eddig el vele már nagyon ki van a ***** a fordítóval mindenért nyafog. Linkelem a gyári FLASH.h könyvtárt és már abban is hibákat talál az agyamat eldobom.

Köszönöm.

Melyik IDE?
Melyik UC?

Nálam semmi hiba: Keil5 és STM32 F 103 C8T6

Leszedtem a gyári 1.5 ös könytárat az F030 procihoz. Azépen bemásoltam a stm32f0xx_flash.h az inc mappámba a stm32f0xx_flash.c meg az src-be.

Keil5 tök üres program 1db led villogtatás.
Berakom a #include "stm32f0xx_flash.h" és kezdődik a sírás.

(error in include chain ("stm32f0xx_flash.h):" expected '}'

Mindegy futtatom a fordítást hibák sora:

1. Az előző beírásomban ajánlott bootloadert az STMFlashLoader letöltő program segítségével lehet letölteni (kell hozzá egy USB-UART átalakító), a gyárilag beépített UART bootloader felhasználásával. Ugyanezt az utat kell járni az ST-Link firmware letöltésnél is, ha az egyik modult ST-Link programozóként akarod használni. Én nem ezt az utat jártam, mert volt kéznél egy ST-Link programozó is.

2. A Keil-t és az Atollic-ot is érdemes megnézni. Előbbi az univerzálisabb, de korlátos...


3. A legtöbb ARM Cortex-M mikrovezérlő gyárilag tartalmaz bootloadert. Ha jól tudom, az általad beszerzett típus csak az UART módú betöltést támogatja. Arduino IDE-hez kényelmesebb a Maple mini USB-s bootloader használata (amit ajánlottam előző beírásomban), de ez a felhasználói területen van, így könnyen felülíródik, ha nem vigyáz rá az ember. A gyári bootloader ebből a szempontból stabilabb, az külön, védett területen van.


4. Nem, ugyanolyan ST-Link programozó és hibavadász lesz belőle, mint amilyen például az STM32F0 Discovery kártya ráépített programozója.


5. Csak az STM32 programozható vele SWD módban (pont úgy, mint az STM32F0 Discovery kártya ráépített programozója). A 8 bites STM8 nem programozható vele (kellene még néhány ellenállás és összekötés, akkor menne az is).

Én még nem használtam: STM32F0xx_HAL_Driver-t

De ha már beraktad a projectbe a : stm32f0xx_hal_flash.h-t
Akkor ne akard használni a: stm32f0xx_flash.h-t
Mert ugyanazt csinálják, csak kicsit másképpen, és összevesznek!

Vagy építsd újra a projectet STM32F0xx_HAL_Driver nélkül.

Megcsináltam HAL nélkül, ugyan úgy nem fogadja be a kódot. Amikor lement hiba nélkül akkor pedig ugyan úgy olvasható maradt.

Pointeresen hogy nézne ki a kód ha a 0x1FFF F800 címre kellene írnom az adatot?
Pointerhez egyáltalán nem értek.

Van ez a sor ezt hogy kellene használni?



Akár hogy írom bele a címet meg az adatot nem fogadja el. Egyszerűen az interneten annyira nincsen semmilyen példa angolul semmilyen nyelven. Mindenhol csak a könyvtár. Egyszerűen nincs kitől segítséget kérjek.

njhhhh

Megpróbálhatod így is, implicit mutatóval:

Ilyen formában próbáltam én is és a 3. sorra hibát ír. Azt írja hogy:

error: expected identifier or '('
error expected ')'
error expected ')'

Aki ír nekem egy működő read protection kódot annak felajánlok 5eFt-ot.

There is a good example within Keil, and probably IAR too
C:\Keil\ARM\Examples\ST\STM32F10xFWLib\Examples\FLASH\Program\main.c

Ma még csak adatlapokat bújtam!

De nem sikerült rájönnöm mi a különbség az: STM32F103x6 vagy STM32F103x8 között?
Esetleg tudja valaki a választ?

FLASH és RAM méret. És még néhány periféria mennyiség.
ST MCU

STM32F103x6 és STM32F103x4 szerényebb kiépítésű, mint az STM32F103x8.
Kevesebb Flash, kevesebb RAM, kevesebb timer, kevesebb UART, kevesebb SPI...

Adatlapok: stm32f103c6.pdf, stm32f103cb.pdf

Hosszas keresgélés után, rájöttem a Flash Read Protection Setup, hogyanjára!!!

Programozás után beállítod a ST-LINK Utility-ben:
Target > Option Bites > Read Out Protection = Enable > Flash swctors protection: pipák Select all > APPLY !!!

Utána olvashatatlan lesz a Flash!

Következő programozásnál rákérdez, hogy törölje a Flasht és újra írja?
De ha nincs meg az eredeti Hex fájl???

Még kiegészíteném annyival, hogy utána a programozó jumpert lekel húzni, utána resetelni.
(Teszt panelokon szokott ilyen lenni. De csak soros botloadernál van szerepe, ST-LINK-nél nincsen)

Üdv!

Szerintetek lehet 2 Keilt telepíteni 1 gépre?
Ez OK: MDK515 + Ezt tesztelném: MDK521a?
Vagy az előzőt előbb lekel szedni?

Köszi!

Találkozott e már valamelyikőtök olyannal, hogy valamelyik port nem működött?

Tegnap felprogramoztam kb 80db STM32F030-ast és 2db nál ugyan az a port egyszerűen nem működött.
Az egyikben kínából származó IC volt (nem volt eddig velük baj) a másikat a Mouser-től vettem.

Nem tudom szimpla véletlennek betudni a dolgot mert mind a 2 panelen furcsa mód ugyan az a port nem működik. A többi 78 jól megy. Még azt sem mondhatnám hogy a rákapcsolt áramkört tehetett benne valami kárt mert csak egy 7 szegmenses kijelző egyik szegmense van rákötve.

Járt már valaki így?

Hasonló helyzet volt az egyik ADC bemenettel is. Egyszerűen nem működött összekötöttem a szomszédos lábra a jelet ott már vette a mintát.

Elsőre a helyes / helytelen tárolás és az ültetés módját mondanám komoly meghatározó dolognak.

1. Már volt példa nálunk arra, hogy páratartalomra érzékeny IC-t kinyitottunk, elhúzodott a gépi ültetés (fejhiba, pár nap pihi), ezt követően folytattuk és a nyitva maradt csomagolásban az IC időközben magába szívta a párát, majd vélhetően amikor ültetés után áttoltuk a reflow-n, akkor a pára - víz tágulása szétrepesztette belül az IC-t. Zselés LED-del is volt már ilyen. A leállás előtti panelek működtek, a leállás utániakban az IC-t cserélni, rework-ölni kellett...
Tehát első gyanú: Helytelen tárolás, helytelen hőprofil és belső "repedés"

2. Az STM32-d valójában koppincs GD32 (bár ahogy tudom nekik még nincs F0-juk), ráadásul az eddigi felbukkanások azt mutatják, hogy a GD32 nem rosszabb, hanem kifejezetten jobb is mint az ST az F1-es kategóriában.

3. Szegmens "túláram" kinyírta a pint.

Az a baj, hogy a leírásod alapján ez mindenképp belső sérülés (gyanúsan ültetéskori). Amennyiben code verify-t és flash ellenőrzést csináltál.
Kis sztoriként az ATmega128-ban például a helytelen tárolás / túlhevítés a PORTG 2-t nyírja ki kb. mindig

Nem hinném hogy túlhevült volna mivel nem reflow a forrasztás hanem sima pákás. A tárolás tudom hogy nem megfelelő. Statikus töltésre gondoltam de hogy ugyan azt a lábat tegye tönkre azt kizártnak tartom.

A szegmens áram nem túl magas csupán 15mA.

Igen, az ESD problémát azért nem is írtam, mert nagyon-nagyon kicsi az esélye, hogy ugyan azt a lábat üsse ki.

Melyik lábról van szó?
Mert van olyan I/O ami csak 3mA-t bír.

PA9 lábról van szó.

Nem megfelelő boot mode select bekötés? PA9 és PA10 bootloader USART lábak.
Egy extrém szcenárió, de induláskor tranziens állapotban belép bootloaderbe, ahonnan végül kilép de úgy, hogy a periféria USART-ra konfigolva marad, majd a user kódban nem inicializálod megfelelően a PA9-et, ami így AFIO-ként ketyeg tovább. Ha ez sem, akkor a patás ördög

Tudja valaki esetleg, hogy az STM32 ADC bemenetén a gyakorlatban ha pl a leggyorsabb 1us a mintavételi idő és a bemenetén van elegendő kondi pl 100nF hogy stabil maradjon a mintavételnél akkor mennyi szokott lenni vett minta ingadozása bitekben?