[elektro] Nuvoton

[Bali Zoltan]

A KIT-hez adott letörhetőt használom. Ilyen
hibás égetés még nem volt nálam, de
én csak pár darabot használok, de azt
sokat égettem.

A TIMER-re rémlik vmi. regiszterrel
lehet állítani a debug alatti viselkedést.
De még nem próbáltam.

Üdv.  Zoli

2015.01.03. 14:52 keltezéssel, hg12345 írta:
> Ja elfelejtettem kérdezni milyen debuggert használsz.
> KIT, vagy Nu-LINK esetleg Nu-LinkPro-t?
>
> Még egy hiba jelenséget találtam, égetésnél nem mindig sikerül az égetés, főleg sorozat gyártásnál (1000<).
> Sokszor produkálta hogy beégethetetlen az uC (teljesen új) aztán a következő.... és a programot újra kellett indítani, hogy rendbe jöjjön. Aztán a "beteges" darabokat többé-kevésbé sikerült helyesen beégetni, de volt olyan, amit automata üzemmódban nem lehetett, csak egyedi törléssel lehetett vissza állítani az égethető állapotot.
>
> Arra nem emlékszem, de a Cortex magoknál a perifériáknál állítható, hogy Debug alatt megálljanak vagy fussanak tovább. A nem megfelelő beállítás okozhat meglepetést.
>
>
>
> Bali Zoltan <eltexto at freemail.hu> írta:
>> Szia Gábor!
>>
>> Hát, elég nagy a káosz a revizíókban.
>> Használtam A, B és most D rev.-et.
>> Ismerem a különbségeket, nagyjából.
>> Még az elején töltögettem adatlapokat,
>> amit most már nem találni meg a honlapon
>>   A, B rev.-ről. Mindig az aktuális adatlapot
>> nézem. Remélem :) .
>>
>>
>>> A nálam a tápfeszültség csökkenés okozott debug problémát. Főleg
>> akkor, ha a debuggerből kapta a tápot.
>>
>> Ezt kifejtenéd bővebben? A panel, jó ha fogyaszt 30mA-et.
>> Minek izmosabb táp?  A dinamikus rángatásra
>> meg elég megfejelni a 100nF kondért 1-22uF-al.
>> Nem?
>>
>> Én most rá applikáltam a debugger panelre
>> az USB -ről  schottky helyére egy
>> MC78PC25NTRG 2.5V LP stabot,
>> a csatira menő diófát meg kikötöttem.
>> A cucc 2.5V-ról jár, így nem bolondítja
>> meg az AD-t, ugyanis az a tápról referál.
>> De 5V-os cuccnál is vacakolt a debugger.
>>
>> Köszi
>>
>> Üdv.  Zoli
>>
>> 2015.01.02. 19:36 keltezéssel, hg12345 írta:
>>> Hi
>>>
>>> Nézted melyik altípust/verziót  használod, sajnos vannak közöttük eltérések, és nem igen találsz infót róla. A honlapon nekem nem sikerült.
>>> AN,(BN,CN elvileg nem került forgalmazásra), de amit most forgalmaznak a DN.
>>> A (B,C) tudta pl. bitbandinget, de az (A,D) nem. Szóval van különbség ezek nem okozhatják a problémát?
>>> Minél újabb annál több kiegészítő funkció van benn, vissza felé biztos nem kompatibilis!
>>> Sok helyen van apró különbség, bővítés, TMR, USART....stb.
>>>
>>> A nálam a tápfeszültség csökkenés okozott debug problémát. Főleg akkor, ha a debuggerből kapta a tápot.
>>> Egy izmosabb 1117-3.3V SOT89 tokot építettem rá, innen adok tápot egy schottky diódán keresztül, azóta nem volt problémám a debuggal.
>>>
>>>
>>> Bali Zoltan <eltexto at freemail.hu> írta:
>>>> Hali!
>>>>
>>>> Eddig el voltam vele. De most már nagyon
>>>> unom. Egy saját USB kezelést írtam rá pár
>>>> éve (NUC120LC1BN) siker0lt probléma mentesre
>>>> csinálni. Ha gond volt, mindig és hibáztam.
>>>> Ezt most átraktam NUC120LE3DN-re. Ami működött
>>>> az előzőnél a max. sebesség kipréselése miatt,
>>>> a double, buffer (váltogattam a buffer szegmens
>>>> címet a regiszterben) ennél nem működik.
>>>> Tudomást sem vesz róla hogy átírtam és az előzőt
>>>> küldi el. Nem gond, most nem kell speed, vissza
>>>> írtam egy pufferre.
>>>>
>>>> Közben nyüstölöm az M051-et. A TIMER-el vacakolok.
>>>> Lehet én vagyok béna 3 napja, de nagyon gáz érzésem
>>>> van. Az egy dolog hogy elejétől szarul működik a debug,
>>>> gondoltam majd javítják, de nem. Még mindig keveri a
>>>> töréspontokat hol működik ha leteszek egyet, hol nem.
>>>> Ha bent hagyom a töréspontot és újraindítom a debugot,
>>>> akkor működik. Néha elveszti a fonalat. Szóval bizonytalan.
>>>> Így nem lehet debuggolni, hogy nem tudom most azért nem áll
>>>> le a töréspontnál, mert ez a valóság, vagy mert épp úgy gondolja.
>>>> Most jutott eszembe, van másik is, majd azzal is megpróbálom.
>>>> Hátha HW gond van(A FW új drivernél már jó néhányszor
>>>> frissítette).
>>>> Vissza a TIMER-re, ahol valaki debounce lehetőséget lát,
>>>> és anomáliák vannak, kapcsolja ki. Ha nem, nálam a
>>>> Capture módban, a TEX bemenet magas esetén, ha resteltem CEN = 1
>>>> estén a CRST-vel a TIMERT, generált egy TEXIF-et. Debounce
>>>> kikapcsolásra megszűnt. Most vettem észre. hogy inicializálásnál
>>>> a TIMER0 mexakítás engedélyezésekor lefut egy TIMER0 IT
>>>> (betettem egy töréspontott és oda lép mindjárt az engedélyezés
>>>> uton. AZ IT lefut üresen mivel shared és az IF bitek szelektálnak.
>>>> DE nincs egy IF bit bebillenve. 3 napja szórakozom vele.
>>>> De még mindig lehet én vagyok a béna.
>>>>
>>>> ez a kritikus pont configurálás után:
>>>>
>>>>     /* Step 5. Enable Timer0 module */
>>>>     TIMER0->TCSR.CEN  = 0;          // már ezt sem engedem
>>>>     TIMER0->TCSR.CRST = 0;          // már ezt sem resetelem
>>>>     TIMER0->TCSR.WAKE_EN = 0;       // már ezt sem engedem
>>>>
>>>>     NVIC_EnableIRQ(TMR0_IRQn);      // Enable Timer0 Interrupt
>>>>     /* A követkeő sorra lépve már lefut az TIMER0 IT /*
>>>>     /* pedig még nincs semmi engedélyezve /*
>>>>     TIMER0->TISR.TIF = 1;           // Write 1 to clear for safety
>>>>     TIMER0->TCSR.IE  = 1
>>>>
>>>>     TIMER0->TEXISR.TEXIF    = 1;
>>>>     TIMER0->TEXCON.TEXIEN   = 1;
>>>>
>>>> Hozzáteszem ez az init IDLE előtt van nem indulásnál,
>>>> tehát előtte jó néhány clock kikapcsolásra kerül,
>>>> portok beállítása, periféria reset, stb.
>>>> A fentit többféle sorrendben, variációban kipróbáltam,
>>>> semmi.
>>>>
>>>>
>>>> Bocsi, hosszú lett és érthetetlen :).
>>>>
>>>> Üdv.  Zoli
>>>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
> -----------------------------------------
>            elektro[-flame|-etc]