Záhadné poškodenie procesora PICKIT programovaním istého ASM

Dobry den prajem. Nevedel som ako konkretizovat predmet tejto spravy. Mam nasledovny problem. Napisal som si program (som viac menej skuseny programator) v ass. a po jeho naflashovani do procesoru sa procesor akosi poskodi. Sam by som tomu neveril, ale uz si neviem rady. Mam tu na stole uz 6 kusov pokazenych uPC. Mam podozrenie na programator (mam postaveny klon PICKIT 2), ale ozaj neviem co si mysliet. Ked som skusal siesty procesor - novy tak mi ho programator v pohode nasiel - dokonca som do neho bez problemov naflashoval iny program. Ked som vsak skusil nahodit do neho program, ktory potrebujem, opat sa opakoval blby scenar. uPC sa jeden krat napalil, ale potom uz nekomunikuje. Niektore mi nenajde programator vobec (sprava o neznamom zariadeni) a dva mi ja rozpozna, ale pri pokuse o citanie, mazanie, alebo zapis vyhadzuje chybu o zlom ID zariadenia. Neviem si to vysvetlit. Rozmyslam o kupe PICKIT3, len by som rad vyriesil tuto zahadu. Upnem sem aj program v asm - ak by niekto riskol poskodenie uPC tak nech to skusi flashnut a da vediet ako pochodil. Program je pomerne jednoduchy, este uplne neodladeny, ale tazko sa ladi ked kazdy procesor sa tvari ako verzia “C”. Je pre 16F628A - skusal som aj 627 aj 648.

:arrow_right: administrator: přejmenováno z "Zahadne poskodenie procesora programovanim"
problemovyprogram.asm (5.93 KB)

v poistkach mas povolene LPV … zabezpecil si na RB4 pozadovanu uroven… nemas zaskrtnute pouzitie LPV mode v programatore pic kit 2 .
Skus pouzit klasicke programovanie s 13V na MCLR

Ospravedlnujem sa. LVP som mal OFF - dal som to na ON ako poslednu moznost programovania. LVP teda v problematickom subore je OFF.

16F628A bezi, jde smazat/pracist/opet nahrat, neni mrtva :slight_smile: ,programovano PICKIT2 original HVP, pripojil sem ledku na RB5 a blika/ sviti ma snahu, program bezi, v simulatoru my ale pretek Stack ! co ma delat to to ?? movlw 1 movwf PCLATH movfw jednotkym addwf PCL retlw b'00000001' . .

Milo PS3 - dakujem za odpoved. Pretiekol stack? Kde sa to da prosim pozriet? tenkod znamena LED dekoder. Dal som to ulozit na adresu od 100h , kvoli manipulacii s PCL (preto tam je zmena PCLATH). Mne po naprogramovani uz nefunguju PICka - idemobjednat PICKIT3 a uvidim co jevo veci… Programma generovatrozmietanu frekvenciu okolo 1khz zobrazovat multiplex na 2 LED 7 segmentoch a stopovat cas. Ten stack ma zaujima pls okrem spomenuteho.

EDIT: ospravedlnujem sa - dako sa mi poplietli subory. toto je spravny subor
problemovy.asm (6.44 KB)

za to preteceni muze instrukce movlw 1 movwf PCLATH movfw jednotkym addwf PCL retlw b'00000001' . .
**EDIT: **tento druhej kod uz funguje . jak ma
v cem to pises ? prekladas ?? mas tam porad spatnou pojistku Error[113] I:\PIC\ZKOUSKA\SAGIT.ASM 8 : Symbol not previously defined (_DATA_CP_OFF)

Preto som mal dotaz, ze ako sa da zistit pretecenie stack. Ja som sem dal druhy suvor, ktory som mal dat hned - ale sa mi poplietli. Ten prvy uvedeny je starsi a este tam je kopu nedorobeneho. Tento aktualny ma ulozeny dekoder od adresy 100h , takze tam by nemal nastatproblem - jetopraveze umyselne - aby mi ten dekoder nevysiel blbo medzi dve stranky pamate. Skus prosim ta naflashovat tento druhy (vedomie rizika poskodenia procesora). Ohladom programu - hovorim - nie je ste v reali odladeny, ale budu to uz len detaily. Dakujem za reakcie v kazdom pade - kazda rada dobra…

dryhy kod po uprave pojistky prelozen , nahran a :imp: ! nekomunikuje …, resim az zejtra, pro dnesek padla

Milo dakujem a mrzi ma ze som zmrzacil aj tvoj uPC - dostal som avsak odpoved ze v hardveri to nie je. Otazne je ale co sa stane a preco sa to stane, myslim ze zistenim dovodu nepomozem len sebe ale aj inym. Ja si to vysvetlit neviem.

Takze pricina zmrzacenia je uplne jasna.
Mas v konfiguracnych bitoch zvoleny interny oscilator, zakazany MCLR a tvoj program si hned po starte prepne RB6 a RB7 do funkcie digitalneho vystupu. Je zrejme, ze PicKit2 nema ani najmensiu sancu uviest MCU do programovacieho modu.
Je treba pozriet si v programovacich specifikaciach, ako to prebieha, nechce sa mi to tu popisovat.
Takze touto kombinaciou konfiguracnych bitov a programu si si PICko zamkol voci klasickemu ICSP programovaniu. Na rozdiel od zamknutych AVRiek sa to da vyriesit (1) a da sa tomu predist (2).

1, Vyriesit sa to da, ale nebude to v ramci ICSP. Ak nemas, musis si vyrobit maly programovaci adapter, kde budu signaly z PicKit2 privedene priamo na PICko, teda neda sa to urobit ak pouzivas ICSP. Hlavne je, aby malo PICko volny MCLR pin a aby PicKit2 mohol dodavat VDD. Trebars kusok plosneho spoja, jedna patica na PICko. Dalej k tomu pripojit jeden 100nF keramicky kondik medzi Vss a Vdd PICka, co najblizsie k PIC, co najkratsie vyvody a odpor cca 22kOhm medzi MCLR a Vdd.
V ovladacom SW k PicKitu si zvolis Tools->Use VPP first program entry a potom by uz PICko malo ist zmazat a preprogramovat. Ak ho budes mat, tak:
2, Nikdy, ale nikdy si nedavaj tuto nestastnu kombinaciu konfiguracnych bitov. Najjednoduchsie je povolit MCLR/RA5 ako MCLR a nie ako vstupny pin. Tym padom ma PicKit2 uplnu kontrolu nad PICkom a moze ho preprogramovat. Ak ten jeden vstupny pin nevyhnutne potrebujes, pouzi vacsie PICko a nekomplikuj si zivot vstupom pod MCLR. Alebo sa zmier s tym, ze po kazdom programovani musis robit proceduru ktoru som opisal hore.

A toto sa potvrdilo aj tym, ze ten prvy program, ktory PICka nemrzaci (a aj Milo to potvrdil) ma MCLR povolene, ten ktory mrzaci PICka, ma MCLR zakazane.
No, je to jasne. Vzdy a vsade to opakujem, pokial clovek presne nevie co robi, nech nezakazuje MCLR.

tusim ze uz jsi to tu jednou nekde psal , my to mohlo trknout,
“Use VPP first program entry” sem mel zaskrtly , pokud ale zmenis typ v “Device family” tak se to zase odskrtne , po opetovnem nastaveni soucastky na Midrange musis opet aktovovat…, tot byl muj problem, 628 zase komunikuje ,Dekuju

Jaromirovi aj ostatnym velmi dakujem. Nie osm sice momentalne doma, ale ked pridem hned sa na to pozriem. Ozaj nestastne som to dal. Prakticky som este neriesil tlacitka, mam to NOPovane a defaultnu konfiguraciu TRIS som nenastavil - vobec ma nenapadlo ze to moze mat taketo dosledky. Poskusam to a dam vediet kolke som spasil. Este raz pekne dakujem.
PS: pisane to bolo v linuxovom nastroji PIKLAB - je mozne ze pouziva mierne iny inc subor pre priradenie symbolickych nazvov. (vzdy si to pozriem v dotknutom inc a podla toho nastavim)

Pani tak som sa do toho dal. Podarilo sa mi zmazat pomocou softu k pickit 2 vsetky procesory. Horsie to vsak bolo s odstranenim problemu. Nakoniec som chybu nasiel v registri T1CON. Musel som nulovat bit T1OSCEN - akonahle bol enabled - problem s neuspesnou komunikaciou pretrvaval. Mozte vyskusat (nakoniec aj pri nastaveni RB6 a 7 na vystupy bez problemov komunikacia bezala). Az po nulovani bitu T1OSCEN mi bez problemovbezala komunikacia ako mala. V simulatori mi bezi aj prerusenie od TMR1 - tak verim ze aj v reali bude bezat - zajtra zistim. Len somnesvoj z toho bitu - co to je a preco sa to takto sprava…

Som rad, ze si problem vyriesil.

Len pre zaujimavost - ako si v Linuxe a PikLab-e uplatnil nabeh do prgramovacieho rezimu s privedenim Vpp ako prveho napatia? Je tam takato explicitna moznost, alebo to treba riesit inak?
To, co som popisoval platilo pre Win verziu PicKit2 SW, neviem ci existuje aj linuxovy derivat.

No prakticky simulacia a odladovanie prebieha uz v MPLABe - na to su doterajsie linuxove nastroje slabe (verim v zlepsenie casom). Ale dalsi problem z rise zaujimavych sa mi vyskytol. Jedna sa o rovnaky subor ako je tu uplnuty. V jednom casovaci generujem vystupnu frekvenciu, v druhom pocitam relany cas a v tretom obsluhujem multiplex. Tu nastava problem. Pokial vystupnu frekvenciu negenerujem, multiplex ide krasne. Akonahle ale zapnem aj generovanie frekvencie,multiplex nepekne nepravidelne blika. Zo zaciatku som myslel ze to procesor nezvlada, ale vypoctom je zatazeny tak na 10 percent. Multiplex zblbne akonahle dochadza k pravdielnemu striedaniu logickych stavov na vystupe. (Po nahradeni bsf a bcf out instrukciou nop ide multiplex krasne). Takze vypoctovym vykonom to nie je. Akekolvek napady uvitam.

EDIT: Tak dalsia zahada odstranena. program bezal korektne, problembolv HW. Po zapojeni vystupu s frekvenciou bol zrejme PIC prudovo pretazeny. Osciloskop ukazal, ako sa prislusna anoda zapla, ale hned na to vypla (program bezal korektne). zrejme maju PIC HW ochranu proti pretazeniu portu a vypinaju vystup. V kazdom pripade po pridani vhodneho rezistora uz vsetjko bezi ako ma. Dakujem vsetkym a nech sa dari…

sagit:
Microchip planuje v tomto polroku vydat oficialnu prvu verziu multiplatformneho nastroja MBPLAB X, ktory by mal bezat na Win/Linux/Mac, vratane plnej podpory kompilatorov, simulatora, debuggerov. Momentalne je vonku beta verzia forum.microchip.com , aj s nejakymi rieseniami.
Skusal som to nainstalovat aj na Linuxe (Ubuntu) ale kedze linux realne vidim prvy krat, nebol som uspesny, navyse mi emulacia pod VirtualBox-om bezala dost pomaly, tak som to pre teraz nechal tak.
Ak si v Linuxe viac doma, pozri sa na to, pripadne si to skus nainstalovat a potom uvitam zas ja tvoje rady ako na to :slight_smile:

Dakujem jaromir za info. Samozrejme ze to vyskusam. Dam vediet ako to dopadlo.

OK - mohol by si potom zalozit nove diskusne vlakno. V tomto sme uz dost divergovali od temy, tak nech tu nerobime neporiadok :slight_smile:

Není to tak docela pravda. pro tebe ta záhada ještě odstraněna není. PIC pochopitelně žádné takové ochrany nemá. Ta tvoje záhada má nejspíš označení R-M-W a zrovna nedávno se tu o ní hovořilo.