[elektro] STM32F100 Reset probléma. Programblokk törlődik.
Pataki István
pataki.istvan at freemail.hu
Tue Sep 22 18:55:04 CEST 2015
Használj olyan táp IC-t, aminek van powergood kimenete!
pi
----- Original Message -----
From: "elight" <elight at gmail.hu>
To: <elektro at tesla.hu>
Sent: Tuesday, September 22, 2015 5:44 PM
Subject: Re: [elektro] STM32F100 Reset probléma. Programblokk törlődik.
> Akkor lesz ilyen chipem eladó,
> vagy előbb utóbb egy hexacoptert is muszály építenem?
>
> Egyébként raktam minden bemenetnek
> 3,3V-os tranziens védőt meg ellenállás osztót.
>
> Nekem az okozott problémát , hogy akksis készülék esetén
> ha ráteszem az ák-ra a 12V -os tápot , a modul nem resetel
> elsőre ( nem lenne elég a tápjel meredeksége? ) , picit lekell
> venni és ujra rárakni a drótot, és akkor másodikra jól indul.
> Utána már nincs problem míg ki nem kapcsolom.
> Magától újraindulást eddig még nem tapasztaltam.
> A következő tervekbe majd már rakok inkább a modulon kívüli
> tápfigyelő és reset chipet.
>
> A sűrű lábkiosztás arányítva a modul árához tart vissza
> hogy magát a chipet tervezzem be.
> És mert amíg kapni modult, addig nincs gond,
> könnyebb a szemnek az élet, és az bőven elfér minden
> cullangjával...
>
> Üdv István
>
>
>
>
>
> 2015-09-22 16:45 keltezéssel, hg12345 írta:
>> 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]
>> -----------------------------------------
>> elektro[-flame|-etc]
>
> -----------------------------------------
> elektro[-flame|-etc]
More information about the Elektro
mailing list