[elektro] STM32L15 random reset

[hg12345]

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]