[elektro] STM32F100 Reset probléma. Programblokk törlődik.

hg12345 hg12345 at freemail.hu
Tue Sep 22 16:45:05 CEST 2015 

Használtam a F4 disc.... nekem nem zavart de csak demónak, alkalmazása válogatja, szerintem egyszerűbb a hőlégfúvót bekapcsolni és levenni.
Hát a discovery és nucleo elég nehezen védhető meg zavar ellen, erősen hiányoznak róla védő ellenállások, stb.... persze árban verhetetlen.... föleg a tokozás váltása....





elight <elight at gmail.hu> írta:
>csak gondoltad :-)
>
>
>Egyébként minden ilyesmi már el van követve,
>amit felsoroltál, vagyis valami hasonló féle.
>Ezért is nyúltam az osc, és debug lábakhoz is..
>A kiosztást még az is bonyolítja ,
>hogy több helyen figyelni kell melyik 5V tolerant láb,
>azok inputok, és melyik nem , azok a perifériák
>és az outputok..
>   Persze azért van némi védelem is idegen ménkű ellen..
>
>
>De már megterveztem és összeraktam a 2.0 verziót is,
>de arra nem tudom a meglévőt 1 az 1 ben átportolni,
>meg még a programozását is tanulnom kell..
>De az F4 -essel előre érzem ilyen lábszám, meg erőforrás
>  gondom legalább nem lesz.
>
>
>Plusz kérdésem,  hogy az F4 discoverit panelkét használnám,
>a bekötött giro meg egyéb csoda (audio)  chipeket le kell e vennem
>( vagy jumperrel ki kell kötnöm ) majd ,  vagy nem zavarhatnak be
>a lábak működésébe ha nem SPI-ként állítom és programozom?
>
>Üdv István
>
>
>
>2015-09-22 16:13 keltezéssel, hg12345 írta:
>> Nem írtam,hogy használj nagyobb lábszámút :-)
>>
>> Amúgy mindig van olyan hogy kimenetnek használt lábat átmenetileg bemenetnek lehessen használni, pl. ha van SPI portod, akkor amikor nem használod akkor az CLK és MOSI lábakat bemenetnek lehet használni, csak egy soros ellenállás kell. :-) Pl nyomógombokat így lehet használni minden különösebb akadály nélkül.
>> Jelfogók meghajtása szintén néhány us időre felfüggeszthető, ha fetet használsz tr helyett akkor máris átfordítható bemenetnek, így kiolvasható, majd vissza az eredeti funkcióra.
>>
>> Nem minden lábat érdemes közvetlenül a uC-ből meghajtani, 74HCT595A egy CE és SPI kiegészítéseként korlátlanul lehet a bőviteni a lábakat $0.15/8 áron. Ugyan ez van bemenetként is.
>> A nagy lábszámú  áramköröknél >100 felet már 2 rétegen gond lehet az értelmes vezetékezéssel.
>> Ilyenkor sokkal kényelmesebbek a portbővítők.
>> Ha nem akarsz CMOS vagy LSI-tghasználni manapság már ebben az árban kaphatsz uC a legtöbb megy pl.: ATMEL, ST  1 vezetékes USART-tal ezek $0.30 (20láb) $1 között kaphatóak, egy kis program ami lekezeli mindkét oldalt azUSART-t és kész az akármilyen intelligens funkciójú portbővítő.
>>
>>
>> elight <elight at gmail.hu> írta:
>>> Nincs szabad láb :'(
>>> már így is majdnem láb = láb - 1.
>>>
>>> Ja egy azért van,
>>> csak az meg  a  battery   - azt meg nem szeretnék egyenlőre rakni.
>>>
>>> Tudom , át kell térni nagyobb lábszámúra...
>>> De amit már kipróbáltak,
>>> és   el is visznek azoknak is működni kell még egy darabig.
>>>
>>> Üdv István
>>>
>>>
>>> 2015-09-22 14:37 keltezéssel, hg12345 írta:
>>>> Ilyen megoldásra jobban jársz egy akármilyen 1W, I2C, SPI buszos kis EEPROM-mal.
>>>>
>>>> elight <elight at gmail.hu> írta:
>>>>> Szia,
>>>>>
>>>>> kezdessz közeliteni, és köszönöm az infót...
>>>>> Máris kicsivel jobban igazolni látom
>>>>> a feltevésem.. Az írásvédelem a végén lesz üzembehelyezéskor,
>>>>> ( a tényleges , nem debug , futó programnál már használtam eddig is ).
>>>>> Itt, fejlesztés közben lepett meg, hogy egy módosítás után
>>>>> mindig eltűnt második futtatásra a program  első blokkja..
>>>>> Ezért nem idnult a program a megnyomott reset után.
>>>>>
>>>>> A debug kikapcsolást azért probléma az legelejére hozni,
>>>>>    mert akkor sokáig sötét a kijelző..
>>>>> Egyéb ( LCD, TFT ) esetben simán megvillantgatom
>>>>> egyszer kétszer a háttérvilágítást,  hogy a kezelő lássa ,
>>>>> nem azért nincs semmi, mert lefagyott, hanem mert bootol..
>>>>> és majd bejön 2 sec múlva a kép is neki.
>>>>> Ha nincs a két sec kivárás, nem tudok legközelebb rákapcsolódi.
>>>>> Most FT800 -at használok, és eztetet Initelni kell és paranccsal
>>>>> vezérelni a háttérvilágítás módosításához is.
>>>>> Szóval jelenleg  a 2 sec alatt van a nyitókép, és utána tiltom a debuggot.
>>>>>
>>>>> Valahogy így van , de éppen barkácsolgatom.. Lehet hogy teszek egy plusz
>>>>> ledet és az fog villogni a boot alatt, hogy lehessen látni hogy tölt, (
>>>>> perzse ez a debug on )
>>>>> és utána lezár ( ez meg a debug off )
>>>>>
>>>>> Így mehetne az elejére a letiltás, egyenlőre , ha nem lesz  jobb ötlet.
>>>>> Egyébként a Flash-t is csak a legelső körben ( első futás ) írom most,
>>>>> és a következőekben már csak olvasom. Ezzel oldottam meg ,
>>>>> ha valami paramétert , időzítést etc. változtatnom kell
>>>>> beszabályozáskor , akkor egy konkrét , izolált helyen lehessen azt
>>>>> megtenni.
>>>>> Ne kelljen az egész progit végigturkáni
>>>>>         ( hát tul. ez flash blokk az a Init adatok tára :)
>>>>>
>>>>>
>>>>> Üdv István
>>>>>
>>>>>
>>>>> 2015-09-22 12:46 keltezéssel, hg12345 írta:
>>>>>> Szia,
>>>>>>
>>>>>> - a legegyszerűbb megoldás, ha blokkolod írásra azt FLASH szegmenst ( 1K lépésekben lehet állítani az írásvédelmet!) Ha magad is írod a flash-t akkor célszerű azokat szegmenseket védetté tenni amit nem fogsz használni, sok kellemetlenségtől szabadíthatod meg magad!   Ha írod a flash írás után ellenőrződ az írást?
>>>>>>
>>>>>> Ha kiakarod kapcsolni debug-t azt a legelején célszerű tenni, még a C_INIT után vagy elött.
>>>>>>
>>>>>> Reset után induláskor lehet más probléma, a két BOOT (RB1:-) láb felhasználásával, főleg ha sikerül RAM-ból vagy BOOTROM-ból indítani az eszközt, akkor kicsit más lesz a memória kiosztás, Ezt is érdemes ellenőrizni.
>>>>>>
>>>>>>
>>>>>> elight <elight at gmail.hu> írta:
>>>>>>> Sziasztok.
>>>>>>>
>>>>>>>
>>>>>>> ARM C programozásnál akadt egy olyan
>>>>>>> kellemetlen  jelenség  amit jelenleg  nézegetek..
>>>>>>>
>>>>>>>
>>>>>>> Maga a program Main része szokásos..
>>>>>>>
>>>>>>> Van egy Init és egy Int_Init rész , uart  , systick interrupt-al.
>>>>>>> Flash  területről 12 word  init változó olvasás,
>>>>>>> és ha nincs ott még adat akkor
>>>>>>> létrehozza , letárolja , ismét olvassa.
>>>>>>> Grafika initelés , nyitóképernyő
>>>>>>> SWD debug kikapcsolás. ( kellene a plusz lábak )
>>>>>>> Main képernyő
>>>>>>> while(1)  {  működö rész }
>>>>>>>
>>>>>>>
>>>>>>> Bele javítottam egy már tesztel működő program
>>>>>>> bizonyos részeibe..  és nem jövök rá hogy a javított ,
>>>>>>> vagy esetleg egy régóta bennemaradó hiba szívat?
>>>>>>>
>>>>>>> A jelenség az , ha beégetem a programot
>>>>>>> akkor minden hibátlanu fut , jól kommunikál
>>>>>>> jók az adatok a képernyőn, a kimenetek megfelelőek stb..
>>>>>>> Ha először le-resetelem már akkor SWD visszakapcsolódása
>>>>>>> és a program visszaolvasása után azt látom hogy a
>>>>>>> 0x8000000 - 0x800003FF  program terület kitörlődött
>>>>>>> és 0xFFFFFFFF  az értéke.
>>>>>>> Hatására az ismételt RESET-ek hatástalanok...  !!!
>>>>>>> Ismételten felülírom a programterületet , akkor a
>>>>>>> következő reset-ig megint jól működik.
>>>>>>>
>>>>>>> Maga a program már eléggé meghízott hogy egy az egyben
>>>>>>> végigdebugolhassam..   Szétszedegetni lassú.
>>>>>>> Valami gyorsabb tesztelési ötlet lenne jó előtte.
>>>>>>> Mit is bontsak ki, és nézegessek.
>>>>>>>
>>>>>>> Először  arra gondoltam hogy talán a FLASH init okozná. Megtéved.
>>>>>>> Ha tologatok a Main_Init  részben egy while(1); Stopp gyanánt:
>>>>>>> - Nyitóképernyőig is  jól fut le és vár... Bárhányszor resetelhető.
>>>>>>> Utána arra  gondoltam hogy az SWD  debug kikapcsolás okozza,
>>>>>>> de ha kiveszem ( ennek hatására 3-4 port inputban marad ,
>>>>>>> nem lesz Alternatív IO, de ez nem gond  )
>>>>>>>        a RESET probléma akkor is fennáll.
>>>>>>>
>>>>>>> Egyenlőre a hozzáírt részekben még nem igen találtam meg az igazi okát.
>>>>>>>
>>>>>>> Üdv István
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------
>>>>>>>             elektro[-flame|-etc]
>>>>>>>
>>>>>> -----------------------------------------
>>>>>>              elektro[-flame|-etc]
>>>>> -----------------------------------------
>>>>>            elektro[-flame|-etc]
>>>> -----------------------------------------
>>>>             elektro[-flame|-etc]
>>> -----------------------------------------
>>>           elektro[-flame|-etc]
>> -----------------------------------------
>>            elektro[-flame|-etc]
>
>-----------------------------------------
>          elektro[-flame|-etc]

More information about the Elektro mailing list