PROBLEM programiranje sa Willeprom prog/16F628/Mpasm...

Imam problem da upucam najjednostavniji program u 16F628, koristim Mpasm za kompajliranje, ICprog za programiranje i Willeprom kao hardver...
RAdio sam sa 12F628 i 16F84a, rade bez problema...
Kod 16F628 kompajler pokaze da je sve ok, medjutim ICprog ne prepoznaje Fuses (__config naredbu, sta god da stavim radi po njegovom)
I naravno pic radi potpuno bez veze, radi se o programu koji setuje recimo PORTB on/off..nista specijalno.
Nekad se desi da setuje sve portB-ove i tu se zaglavi....iskljucio sam komparator, uradio softverski sve ali
Ne radi ni u jednom slucaju:
__config 0x3D18
__config _INTRC_OSC_NOCLKOUT & _LVP_OFF & _WDT_OFF & _PWRTE_ON & _BODEN_ON

Da li ima neko iskustva sa ovim slucajem?


(18510) A file register operand which is greater than the absolute max ram
address oes not generate a message of any kind. For example,

LIST P=18F452
MOVWF 0x1000
END

will assemble without warning.

(18762) When generating a .O file for the PIC18XXXX(X), if the __CONFIG or
__IDLOCS directives are specified in descending order of address, then
then specified bytes are not written to the .O file. For instance,

__CONFIG _CONFIG2L, 0xAA
__CONFIG _CONFIG1L, 0xBB

will generate a .O file without the specified configuration data.
The workaround is to order the __CONFIG or __IDLOC directives in
ascending order of address.

Nasao sam ovo u readme fajlu ali ne kapiram sta je .O fajl?

Pravi, pravi, ali ima malo primera na netu o tome.

Ima programatora koji ne ucitavaju konfiguracione bitove iz generisanih .hex fajlova, vec postupaju po sopstvenim setovanjima. Da bi ovo resili za IC-prog, izaberite ih rucno u configuration delu (sa gornje slike) neposredno pre programiranja.

Objektni (.o) fajlovi su objektni fajlovi koji se generisu uvek kada se koristi Microchipovi C kompajleri (samo za PIC18 i vece serije), kao i relokativni asemblerski mod (za sve serije pocev od PIC10).

Kako proveriti da li se radi o tom slucaju? Jednostavno, proveriti da li je u projektu pored .asm i .inc fajlova ubacen linker (.lkr fajl). Ukoliko jeste, morace se generisati .o fajl.

Relokativni asemblerski mod omogucava rad sa vise asemblerskih programa ili potprograma (znaci vise od jednog .asm fajla), i njihovo kasnije povezivanje u celinu (.hex fajl) linkerom, pri cemu se kao medjukorak generisu objektni fajlovi. Linkeru je prepusten problem rasporeda delova programa u programskoj memoriji, kao i rasporeda registara opste namene (Gerneral Purpose Registers). Vise o objektnim fajlovima mozete procitati (na engleskom) u uputstvima za PIC sa linkova mog sajta.

Buduci da najverovatnije (cim niste culi za .o fajlove) koristite apsolutni asemblerski mod, napomena koju ste postovali ne moze se odnositi na Vas.
Licno smatram potrebnim podesavanje svakog konfiguracionog bita, kako ne bi doslo do kasnije zabune. Pretpostavljam da je to uzrok vaseg problema.

U konfiguracionim bitovima niste specificirali _MCLRE konfiguracioni bit (_MCLRE_ON ili _MCLRE_OFF). Ukoliko je ukljucen, morate spolja povezati pull-up otpornik kako ne bi dolazilo do nehoticnog reseta mikrokontrolera. Naime, moguce je da na njegovom RA5/MCLR/THV pinu nije dovedena logicka 1, pa se mikrokontroler neprestano nalazi u reset stanju. Stavise, moguce je da je stanje ovog pina nedefinisano (floating), pa da mikrokontroler sam povremeno "upadne" u reset.

Klasican test ispravnosti mikrokontrolera podrazumeva treperenje LED na jednom od pinova. Na taj nacin proveravate da li je program pravilno snimljen, da li se dobija dovoljan napon napajanja kao i da li je ispravan oscilator (nebitno u vasem slucaju).

A , dali si ovo upisao prilikom inicijalizacije portova dabi dobio da ti isključi komparator i omogući O/I funkciju:

........
movlw 0x07
movwf CMCON
...........

@mnn:

@Stojan Trifunovic: hvala za objasnjenje, _MCLRE sam morao rucno da shtikliram pa ga nema na "spisku", bez njega ICprog
ne moze da uradi ni verifikaciju upisa *.hex u uC...

@Sepa011: znam za rucno konfigurisanje, jedino tako i mogu nesto da "konfigurisem"...

..sve ovo stoji ali ja i dalje ne kapiram sto ne mogu da isprogramiram doticni kako treba...da lki je moguce da je ta serija uC koju
sam kupio neispravna mada i dalje mislim da nesto nije u redu sa softwerom koji koristim...ako se neko sluzi istim programima i ima 16F628 pri ruci,
moze li da proba? Skidao sam i jednostavne *.asm/*.hex sa neta da bih probao ni to ne radi.... :-(

@Sepa011:
...mogu i ovde da ga okacim, nije problem jer je dostupan i na netu, jer bilo koji *.hex mi izbaci gresku "verify failed at address 0002f (ili 0003f)"
Ako ga tutnem i ovakvog sa greskom, setuje sve portove i to je sve...
...
A sto se tice samog hardware-a, pa, sramota me da priznam, ali probao sam i sa 16F84a i utvrdio da ne valja kristal 20Mhz na probnom pcb-u :-(
Manifestuje se tako sto radi 10-tak sekundi kako treba i onda se zaglavi (sa 16F628 nije ni to radio)...
PCB sam ranije koristio i bilo je sve OK, medjutim nesto se pokarabasilo u medjuvremenu - izgubih par dana vrteci se u krug...stavio sam 4Mhz za probu i radi.
Inace koristio sam 16F84a-20 a i 16F628 moze do 20Mhz...
ICprog (koristim V1.05D) i prepoznavanje config bitova sam resio reinstalacijom ICprog-a, ali pojavio se prvi navedeni problem...

Uglavno tri problema odjednom - malo li je? :)
Hvala za pomoc.


Pogledao sam i tvoj sajt. Moja podrska za posao koji obavljash!

@Sepa011:

Znam, taj problem sam resio reinstalacijom ICprog-a, napisao sam u proslom postu - ali je ostao problem upisa u 16F628.
Ne koristim pull-up zato sto mi je MCLRE_OFF, u prvom postu to nisam naveo jer sam isao copy-paste iz random ASM-a.
Hvala na trudu do sad.

Znam, moja greska, izvinjavam se. Uvek iskljucim reset kad radim sa 16F628, makar i rucno. Sad nema potrebe jer radi i sofwerski.



Setovan je jumperima na 12.5V, stvarni je 12.72V ali nije konstantan (napon je ili 12.72V ili 0V) u toku programiranja - verovatno u skladu same procedure upisa predvidjene za PIC...

Napominjem da sa 12F628 i 16F84A upisivanje radi OK.