Fórum témák

» Több friss téma
Fórum » PIC EEPROM írás nem megy
Lapozás: OK   1 / 4
(#) ldani hozzászólása Jan 13, 2009 /
 
Sziasztok!

PIC18F4550 belső EEPROM-ját szertném írni, de nem sikerül ;(

Akódom, melyet a PIC datasheet-je alapján írtam:

  1. void eewritebyte(unsigned char addr, unsigned char value)
  2. {      
  3.         EEADR                   =addr;          //cím rögzítése
  4.         EEDATA                  =value;         //érték rögzítése 
  5.         EECON1bits.EEPGD=0;                     //adatmemoriaba irunk
  6.         EECON1bits.CFGS =0;                     //nem konfigot, hanem adatot akarunk irni
  7.         EECON1bits.WREN =1;                     //írás engedélyezése       
  8.         char gie = INTCONbits.GIE;      //globális interrupt mentése
  9.         INTCONbits.GIE  =0;                     //globális interrupt tiltása az írás idejére
  10.         EECON2                  =0x55;          //inicializáljuk az írást (doksi szerint kell)
  11.         EECON2                  =0x0AA;         //inicializáljuk az írást (doksi szerint kell)      
  12.         EECON1bits.WR   =1;                     //elindítjuk a kiírást
  13.         while (EECON1bits.WR);          //várunk, amíg befejeződik az írás
  14.         PIR2bits.EEIF   =0;                     //töröljük az írásvége jelet
  15.         EECON1bits.WREN =0;                     //írás engedély visszavonása
  16.         INTCONbits.GIE  =gie;           //globális interrupt visszaállítása
  17. }
  18. void main(void) {
  19. eewritebyte(1,10);
  20. }


Sajnos az eepromban nem jelenik meg a kívánt érték!
Debuggolva a függvényt a while után WRERR értékeWREN értéke 1, atöbbi bit 0 EECON1-ben.
A dokumentáció számomra kétértelmű:
Idézet:
„Note: During normal operation, the WRERR is read as 1”
-> ezek szerint sikerült az írás, bár esetemben nem...
Idézet:
„Reegister EECON1: WRERR 0:the write operation completed, 1: write operation is prematurely terminated”
-> sajnos szerintem ez a helyzet.
Még egy kis bonylítás:
Idézet:
„Note1: When WRERR occurs, the EEPGD and CFGS bits are not cleared”
-> pedig nálam 0 mindegyik

Nagyon nem értem, hogy mi a fene lehet!
Van esetleg ötletetek? Mi lehet a baj a kóddal, esetleg kimaradt vmi? Ugye az EEPROM első bájta a 0-nál van?
(#) ldani válasza ldani hozzászólására (») Jan 13, 2009 /
 
Nehezen olvasható a kód és már nem tudom kivenni, szóval ide csatolom (bocsi):
(#) potyo válasza ldani hozzászólására (») Jan 13, 2009 /
 
EECON2=0x0AA, itt van egy felesleges nulla. Nembiztos, hogy ez a hiba, de ha emiatt esetleg plusz kódot tesz be a fordító, akkor emiatt nem megy az EEPROM írás.
(#) npetya válasza ldani hozzászólására (») Jan 13, 2009 /
 
Szerintem nem figyeled a PIR2.EEIF flegget!
Ez árulja el neked, hogy mikor is van vége az írásnak.

Ez nálam így néz ki asm-ban!

CHKWRT: btfss PIR2,EEIF ;wait until bit 4 of PIR2 is set
goto CHKWRT
bcf PIR2,EEIF ;clear bit 4 of PIR2
return
(#) potyo válasza potyo hozzászólására (») Jan 13, 2009 /
 
A GIE tiltását én így csinálnám:

if (INTCONbits.GIE) gie=1;
INTCONbits.GIE=0;
...
if (gie) INTCONbits.GIE=1;
(#) npetya válasza potyo hozzászólására (») Jan 13, 2009 /
 
Az teljesen független, hogy használod-e a GIE regisztert!!

Ha meg van a dokumentációd akkor olvasd el a PIR2
regiszter használatát!

(#) ldani válasza npetya hozzászólására (») Jan 13, 2009 /
 
0x0AA-t javítottam, GIE-t átírtam sajnos nincs változás.

Az EEIF figyelése egy előző verziómban már szerepelt, most beleírtam így:

  1. while (EECON1bits.WR);
  1. while (!PIR2bits.EEIF);


Ekkor a program a EEIF-es whilenál várakozik...

A PIR2 doksiolvasást még nem tettem, de mindjárt fogom! thx!
(#) npetya válasza ldani hozzászólására (») Jan 13, 2009 /
 
Az adataim alapján Te nem eepromot írtál, hanem frissítettél.

A dokuban felette található az írási rutin.
Annak a legvége foglalkozik a PIR2.EEIF -el.
Ott a EEcon1.WR-t csak állítani kell.

A rutin legvégén a PIR2.EEIF -et törölni kell!!
(#) szilva válasza ldani hozzászólására (») Jan 13, 2009 / 4
 
Már megint lehet, hogy a C okozza a gondot. Az adatlapban világosan le van írva:

Idézet:
„The write will not begin if this sequence is not exactly
followed (write 55h to EECON2, write 0AAh to
EECON2, then set WR bit) for each byte. It is strongly
recommended that interrupts be disabled during this
code segment.”


Azaz pontosan azt a szekvenciát kell használni, amit ők írnak a példában:

  1. BCF INTCON, GIE ; Disable Interrupts
  2. MOVLW 55h ;
  3. MOVWF EECON2 ; Write 55h
  4. MOVLW 0AAh ;
  5. MOVWF EECON2 ; Write 0AAh
  6. BSF EECON1, WR ; Set WR bit to begin write
  7. BSF INTCON, GIE ; Enable Interrupts


Itt a pontosság nyílván arra vonatkozik, hogy a 0x55 és a 0xAA között ha túl sok idő telik el, akkor nem történik meg az írás engedélyezése. a 4550 doksijában ugyan nem találok rá utalást, de erős a gyanúm, hogy ez egy nagyon szoros, utasításciklusszámlálóval vezérelt dolog, és ha adott számú cikluson belül nem történik meg az írás, akkor nem lesz jó (ez bizonyára az EEPROM véletlen, programhibákból történő felülírásának megakadályozására lett kitalálva). Egészen biztos vagyok benne, hogy az interruptok letiltását is pont emiatt javasolják.

A fő kérdés az, hogy a C fordító azokat az értékadásokat mire fordítja le, hány "felesleges" utasítás van köztük. Egyébként a legtöbb PIC-es C nyelvben szokott lenni könyvtári függvény az EEPROM kezelésére, valószínűleg pont a fent részletezett problémák elkerülésére.
(#) potyo válasza npetya hozzászólására (») Jan 13, 2009 /
 
Idézet:
„Az teljesen független, hogy használod-e a GIE regisztert!! Ha meg van a dokumentációd akkor olvasd el a PIR2 regiszter használatát!”


Ugyanezt javaslom neked, csak ezúttal kicsit figyelmesebben csináld!

A GIE-t azért kell tiltani, mert ha nem futnak le a
  1. MOVLW 0x55
  2. MOVWF EECON2
  3. MOVLW 0xAA
  4. MOVWF EECON2
  5. BSF EECON1, WR

utasítások pontosan ebben a sorrendben, megszakítás nélkül, akkor nincs EEPROM-ba írás. A másik, hogy az, hogy a WR vagy az EEIF bitet figyeljük, az teljesen egyenértékű. A GIE egyébként nem regiszter, csak egyetlen bit az INTCON regiszterben.
(#) ldani válasza szilva hozzászólására (») Jan 13, 2009 /
 
A sejtésem nekem is ez. Öszintén szólva próbáltam ASM kódot beilleszteni, de a drága hi-tech doksival ellentétben nem akarta elfogadni se a movlw _addr ,se a movwf _EEADR jellegű dolgokat.
Ezek szerint ezen a szálon kellene továbbballagnom...
(#) npetya válasza potyo hozzászólására (») Jan 13, 2009 /
 
Jogos amit írsz, köszönöm a javítást!

Ettől fuggetlenül a PIR2.EEIF--et kell figyelni.
Ja és a végén törölni mert nem lessz írás!
(#) potyo válasza ldani hozzászólására (») Jan 13, 2009 / 4
 
Próbáld így:
  1. _asm
  2.       MOVLW 0x55
  3.       MOVWF EECON2
  4.       MOVLW 0xAA
  5.       MOVWF EECON2
  6.       BSF EECON1, WR
  7. _endasm


Ha így sem megy, akkor csatold a fordítás után kapott .lst fájlt.
(#) szilva válasza npetya hozzászólására (») Jan 13, 2009 /
 
Szvsz az EEIF-nek az írás műveletéhez nem túl sok köze van, azzal csak akkor kell foglalkozni, ha nem megvárni akarod az írás befejeztét, hanem majd interrupttal fogsz reagálni rá. A WR bitnek viszont kutya kötelessége törlődni, ha az írásnak vége. Az EEIF-ről csak annyit így, hogy azt a felhasználónak kell majd szoftverből törölnie, ha egyáltalán használja valamire.
(#) npetya válasza szilva hozzászólására (») Jan 13, 2009 /
 
Ok! Köszi!!
(#) potyo válasza ldani hozzászólására (») Jan 13, 2009 /
 
Juteszembe, ez most Hi-Tech fordító, vagy C18 fordító? Mert az alapján, hogy INTCONbits és EECON1bits, az alapján C18, viszont akkor ne a Hi-Tech doksiját nézegesd hozzá, hanem a C18 saját doksijait.
(#) ldani válasza potyo hozzászólására (») Jan 13, 2009 /
 
Az általad írt kódra ezt kaptam:
Error [192] D:\Dokumentumok\PIC\Projects\eeeee\jolesze.c; 84.0 undefined identifier "_asm"
Error [195] D:\Dokumentumok\PIC\Projects\eeeee\jolesze.c; 84.1 expression syntax
Error [312] D:\Dokumentumok\PIC\Projects\eeeee\jolesze.c; 90.1 ";" expected

Ha a TAG-eket kijavítom #asm és #endasm -re, akkor:
Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s60s.; 789. undefined symbol "EECON2"
Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s60s.; 798. undefined symbol "EECON1"
Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s60s.; 798. undefined symbol "WR"

.lst fájl csatolva (kicsit hosszú, mert az I2C-s hőmérő dolgai is benne vannak. Ha akarod küldök egy letisztázott, csak az eeprom dolgával kapcsoltos fájlt. ?).

nos.lst
    
(#) ldani válasza potyo hozzászólására (») Jan 13, 2009 /
 
Hi-tech a fordító az fix.
De pl INTCONbits látszólag működik. Legalábbis nem kiabál a fordító és debuggolva is úgytűnik. Vagy csak tévedek?
(#) ldani válasza ldani hozzászólására (») Jan 13, 2009 /
 
Frissítés:
Ez működik:
  1. #asm
  2.  MOVLW 0x55
  3.  MOVWF _EECON2
  4.  MOVLW 0xAA
  5.  MOVWF _EECON2
  6. #endasm


Viszont a BSF _EECON1, _WR -nél az _EECON1-el és a _WR-el is baja van.
(#) potyo válasza ldani hozzászólására (») Jan 13, 2009 /
 
Itt valami nagyon nem stimmel, mert a listing fájlban az EEADR és EEDATA regiszterekkel nemis csinál semmit. Csinálj egy teljesen lecsupaszított programot, amiben csak ez az eeprom írás van, és utána egy végtelen ciklusba fut.

Illetve javasolnám, hogy 18F esetén inkább a C18 fordítót használd.
(#) ldani válasza potyo hozzászólására (») Jan 13, 2009 /
 
OK csinálok egy "tiszta" kódot.
A fordításhoz hi-tech PICC18 9.63-at használok. Erre gondoltál vagy a microchipes toolra? Számomra a hitech szimaptikusabbnak tűnt! Melyik miért jobb?
(#) ldani válasza ldani hozzászólására (») Jan 13, 2009 /
 
Csatolva:
(#) potyo válasza ldani hozzászólására (») Jan 13, 2009 /
 
Ennek a kódnak már elvileg mennie kellene. Próbáltad?

A Microchip C18 fordítójára gondoltam. Annakidején elsőre a HI-TECH PICC18 nekem is szimpatikusabb volt, de a C18-at sokkal többen használják, emiatt sokkal több mintakódot találni rá. Illetve az sem elvetendő, hogy a C18 gyári, valamint a student edition ingyenesen használható.
(#) ldani válasza potyo hozzászólására (») Jan 13, 2009 /
 
Nagyon furcsa, mert az előbb _EECON2-t elfogadta. Most már nem!

Executing: "C:\Program Files\HI-TECH Software\PICC-18\PRO\9.63\bin\picc18.exe" --pass1 D:\Dokumentumok\PIC\Projects\eeprom\main.c -q --chip=18F4550 -P --runtime=default --opt=default -g --asmlist "--errformat=Error [%n] %f; %l.%c %s" "--msgformat=Advisory[%n] %s" "--warnformat=Warning [%n] %f; %l.%c %s"
Executing: "C:\Program Files\HI-TECH Software\PICC-18\PRO\9.63\bin\picc18.exe" -oeep_project.cof -meep_project.map --summary=default --output=default main.p1 --chip=18F4550 -P --runtime=default --opt=default -g --asmlist "--errformat=Error [%n] %f; %l.%c %s" "--msgformat=Advisory[%n] %s" "--warnformat=Warning [%n] %f; %l.%c %s"
HI-TECH C PRO for the PIC18 MCU Family (Lite) V9.63PL1
Copyright (C) 1984-2008 HI-TECH SOFTWARE
(1273) Omniscient Code Generation not available in Lite mode (warning)
Advisory[1233] Employing 18F4550 errata work-arounds:
Advisory[1234] * Corrupted fast interrupt shadow registers
Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s18o.; 282. undefined symbol "_EECON2"
Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s18o.; 291. undefined symbol "_EECON1"
Error [800] C:\DOCUME~1\LDani\LOCALS~1\Temp\s18o.; 291. undefined symbol "_WR"
(#) ldani válasza potyo hozzászólására (») Jan 14, 2009 /
 
Kisebb-nagyobb keresgélés után kiderült, hogyha az ember include-olja a htc.h -t, akkor alapból definiálva lesz egy
  1. EEPROM_WRITE(addr, value);
függvény (vagy makro), ha a pic tényleg tartalmaz eepromot.
Betettem a programomba; tényleg le is fordul, viszont mivel a HW most nincs nálam kipróbálni csak holnap tudom. Remélem menni fog!

ps: egy apró kérdés: nincs vmi jó szoftver, amivel ilyen esetben szimulálni lehetne a pic-et? Pl: kiválasztanám, hogy milyen PIC-em van, betölteném a lefordított hexát, aztán lehetne vele játszadozni pl virtuális szkóppal, logikai analizátorral ránézni a lábaira,miegymás...Nem hiszem el, hogy nem létezik ilyen, a kérdésem csupán az, hogy halandó ember számára is elérhető-e és mi az?
(#) potyo válasza ldani hozzászólására (») Jan 14, 2009 /
 
Valami Proteus nevű cuccot szoktak itt a fórumon emlegetni, amivel áramkörben lehet a PIC-et szimulálni. Én még sosem láttam a programot, mert hamár áramkör, akkor inkább összelógatok egyet a teszt céljából próbanyákon, vagy már a kész áramkörön fejlesztek. Az ilyen szimulátorok kezdetben érdekesek, de nem tűnik valami elterjedtnek komolyabb fejlesztőknél.

Az MPLAB SIM nagyon jól használható, ha az ember megtanulja használni. A View->Simulator Trace és Simulator Logic Analyzer menűpontokat ajánlom figyelmedbe.

Erre az EEPROM írásra kíváncsi leszek, mert amit utoljára feltettél kódot, annak mennie kellene a listing alapján.
(#) ldani válasza potyo hozzászólására (») Jan 14, 2009 /
 
Röviden:
Hosszabban: az előző hozzászólásomban említett, gyárilag mellékelt macro szintén nem működik. A csatolt kép (Pic_eepromwr_prgmem_macro.jpg) szerinti kódot keletkeik, amely természetesen nem felel meg a specifikációnak.
A "nyers memóriacímeken" felbuzdulva gondoltam, majd jól kitolok a világgal és beleírtam ezt a saját függvényembe:
  1. #asm
  2.                 MOVLW 0x55
  3.                 MOVWF 0xFA7                             //EECON2
  4.                 MOVLW 0xAA
  5.                 MOVWF 0xFA7                             //EECON2
  6.                 BSF 0xFA6, 0x1                  //EECON1, WR           
  7.         #endasm

És láss csodát: megint nem megy!!!
A keletkezett kódot lásd a másik csatolt képen (Pic_eepromwr_prgmem_asm.jpg).
Hogy a f*szba csinál a fordító a 0xfa7 címből 0xa7-et??? Komolyan mondom megőrülök! (a kódban próbálkoztam már a kis és nagybetűk cseréjével is) Számomra tök új ez a PIC-es világ, még csak most ismerkedek vele, de nehezen fogadom, hogy ezzel ennyi baj van és nem bírnak a gyártók normálisan megcsinálni dolgokat (informatikusként c++,c#,php,stb-hez vagyok szokva)! ááááá!
(#) ldani válasza ldani hozzászólására (») Jan 14, 2009 /
 
és a képek:
(#) ldani válasza szilva hozzászólására (») Jan 14, 2009 /
 
Hogyan lehet olyan szépen kinéző, rendezett kódrészletet beszúrni a hozzászólásba? Nekem még valahogy soha nem sikerült?
(#) szilva válasza ldani hozzászólására (») Jan 14, 2009 /
 
Miért nem próbálod meg a "MOVWF 0xA7,ACCESS" formával címezni az SFR-eket? A 0xA7 helyére jobb lenne az SFR szimbolikus nevét írni, ha azt valamilyen módon támogatja a fordító.
Következő: »»   1 / 4
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem