[elektro] STM32L15 random reset

[hg12345]

A zavarérzékenység nem a fogyasztással van kapcsolatban és nem is azzal, hogy milyen sebességgel fut a uC, ezt írtam előzőleg.

Ha úgy érzed nincs külső zavarás akkor egy HAZARD jelenséget kapsz el. Ez esetben a tápfelépítésben lehet a bajod és ez is okozhat RAM hibát, ugyan emlékeim szerint STM32L sorozat 1.5V-ig megtartja a tárolt adatokat a RAM-ben (ha ennyire egy pillanatra is lecsökken 20us szükséges a resethez, ott már komoly tervezési hiba van) 
Erre gyanakodsz?, akkor kapcsold be a BOR (nem tudom minek hívják) tápfeszültség figyelést ezt lehet konfigurálni, resetre vagy IT-re fusson, válaszd a resetet, és újra induláskor írasd ki a reset forrás regisztert , valahol PWR és RCC halmazban találod, itt erre az újra indulásra van jelzés. Amennyiben ez okozza a problémát, akkor a tápfeszültség felépülést kell alaposan megvizsgálni.

Nem tudom mivel mérted az áramfelvételt, de amit átlag mérsz, az pillanatokra akár nagyságrendi értékkel is megugorhat. Nem megfelelő telep esetén ez komoly problémát okozhat pl.. CR2032 3mA folyamatos max. terhelést ajánlanak, ha ezt jelentősen túllépet akkor a belső ellenállásán észrevehetően megnövekszik feszültség vagyis kapocs feszültség erősen csökken.... Ezenkivűl a kisüléssel párhuzamosan növekszik a belső ellenállás.



"uprogc ." <uprogc at gmail.com> írta:
>Szia,
>
>Az egesz proci 1 mA -t sem vesz fel. Van rajta egy radio modul, ez nehany
>10 mA -t vesz fel amikor adatot tovabbit.
>Ez is sleep modban van, ahogy a proci is [ amugy a proci sleep modjaval nem
>fugg ossze a jelenseg ]
>Tehat olyan tul nagy aramot nem vesz fel az egesz.
>Viszont az elhalas a radion valo kuldes elott tortenik [ valamikor ], de
>pontosan nem kaptam el hogy melyik fazisban.
>Annyit tudok hogy amikor ki akarja hozni a radio modult sleep modbol, abban
>az idoszakban tortenik. [ tortent ; pl. ma nem tortent meg ... ]
>Szinte biztos hogy nem szoft hiba, mert periodikusan ugyanazt a muveletet
>vegzi, amig ki nem fagy ;)
>Sem a kuldendo adatok hosszaval, sem semmilyen SW-es esemennyel nem tutam
>osszefuggesbe hozni.
>
>Udv.
>
>2016-09-26 19:04 GMT+03:00 hg12345 <hg12345 at freemail.hu>:
>
>> Szia,
>>
>> ha RAM-ban is van hiba, akkor biztos nagy intenzítású "külső", "pic-pic"
>> zavar.
>> Kicsi az esélye, hogy a tápon jön be.
>>
>> Általában az hiba oka, hogy a belső föld annyira megemelkedik, hogy vagy
>> sérül a RAM tartalom (ekkor már nagyon komoly energia van fölösbe), de
>> kisebb energia esetén a fetch ciklusban hibás az olvasáskor és olyan helyre
>> ugrik ami uC tiltva van, ezért egy exception errort hajt végre ahol, egy
>> reset vagy egy végtelen ciklus találsz gyárilag + watchdog és kész a
>> reset.   Több GIGA címterület és bármely cím bit sérülhet.....
>> A fetch hibás olvasás, minél nagyobb  uC gyári maximális sebessége annál
>> érzékenyebb. A L15x emlékeim szerint 32MHz ez már kezd erre érzékeny lenni.
>>
>> Ennek a hibának az elkapása, debuggolása nem egyszerű, de lehetséges.
>> 1, van egy regiszter ami megmondja honnan történt a reset, 99% hogy nem
>> értelmes adatot találsz benne.
>> 2, fogod az összes belső 0x13 alatti létező vektort magadra irányítod,
>> majd ez közös rutinra ugrasz megadva a IT sorszámát egy regiszterbe, ha már
>> ez megvan ekkor az elsődleges  listázó kimenet újra húzod, majd szépen
>> sorban minden olyan regisztert, periféria konfigurációt, és belső változót
>> kiküldesz, egy másik gépre, közben némi fohászt rebegsz, hogy az se
>> szálljon el. Az eredményt kiértékelve megállapítód, hogy ötleted sincs mi
>> történt, PC és SP  meg  LINK regiszter össze-vissza fog mutatni. :-((
>>
>> Arra ne számíts, hogy esélyed lesz a ez elszállás címét kinyomozni és
>> vissza ugrani végre hajtandó kódba!
>>
>> Erre egyetlen megoldás van, a nyák áttervezése (már egyszer leírtam mit
>> kell csinálni itt a listán), és a megfelelő alkatrészekkel bővítve :-),
>> vagy a zavar generátor közvetlen szűrése. Az utóbbi sokszor egyszerűbbnek
>> tűnik, de egy kis változás vagy egy új szűretlen eszköz, és megint
>> találkozhatsz a megrendelőddel.
>>
>> Egyszer végig csináltam, a probléma után a 2. próba nyák lett jó, de ha
>> már végig csináltad többé nem hagyod ki. :-)))
>>
>> Sok sikert.
>>
>> Üdv
>>
>>
>>
>>
>> "uprogc ." <uprogc at gmail.com> írta:
>> >ui:
>> >
>> >Elofordult olyan is, hogy nem tortent reset, viszont a RAMba elmentett
>> >adatom serult. De a rendszer tovabb mukodott utanna.
>> >
>> >Ez is a tapon erkezo zavar miatt lehet ?
>> >Emlekszem AVR-nel volt a BOR, itt nem tudom mi van helyette, vagy van-e
>> >valami hasonlo beallitva,...Meg nem ertem oda.
>> >
>> >Udv.
>> >Szabi
>> >
>> >2016-09-26 16:05 GMT+03:00 uprogc . <uprogc at gmail.com>:
>> >
>> >> Most hogy mondod, volt mar ilyen korabban es rapakoltunk nehany kondit
>> >> meg. Lehet hogy megsem eleg.
>> >> Annyira veletlenszeru a reset, hogy ma pl. nem is fordult elo.
>> >>
>> >> Kodhiba okozhat resetet ? [ en ugy tudom ez csak a HW-tol fordulhat elo
>> ]
>> >> [ eddig nem talaltam semmi osszefuggest a reset es a kod kozott ]
>> >>
>> >> Udv.
>> >> Szabi
>> >>
>> >> 2016-09-26 15:47 GMT+03:00 hg12345 <hg12345 at freemail.hu>:
>> >>
>> >>> Nincs zavaró eszköz a környezetben, minden induktív mozgó vagy kapcsoló
>> >>> eszköz alapban gyanus
>> >>>
>> >>> "uprogc ." <uprogc at gmail.com> írta:
>> >>> >Sziasztok,
>> >>> >
>> >>> >Veletlenszeru Reset van az egyik projektemben.
>> >>> >
>> >>> >A program counter a reset handlerre mutat ilyenkor.
>> >>> >
>> >>> >Ami fontos info lehet, hogy  MSI orajelet hasznalok, 2 MHz,
>> Magfeszultseg
>> >>> >at van allitva 1.2V-ra, de 1.5V eseten is elofordult a reset.
>> >>> >A cucc fogyasztasa < 1 mA , DCDC konverterrol mukodik.
>> >>> >
>> >>> >Mindig ugyanazt a feladatot vegzi ciklikusan, ugy hogy nem valoszinu
>> hogy
>> >>> >program hiba van (?)
>> >>> >
>> >>> >Mi okozhat ilyesmit ? [ csak tapfesz ingadozas ? ]
>> >>> >
>> >>> >Udv.
>> >>> >Szabi
>> >>> >-----------------------------------------
>> >>> >          elektro[-flame|-etc]
>> >>> >
>> >>>
>> >>> -----------------------------------------
>> >>>           elektro[-flame|-etc]
>> >>
>> >>
>> >>
>> >-----------------------------------------
>> >          elektro[-flame|-etc]
>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
>>
>-----------------------------------------
>          elektro[-flame|-etc]