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

elight elight at gmail.hu
Wed Sep 23 09:53:54 CEST 2015 

Köszi.
Majd az lesz..

Üdv Isván

2015-09-22 18:55 keltezéssel, Pataki István írta:
> 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]
> -----------------------------------------
>            elektro[-flame|-etc]

More information about the Elektro mailing list