Sajnos ezt a műveletet nem hiszem, hogy lehet debuggolni, hiszen nem programfutási hiba.
Az LVD működik, hiszen az LVDIF bitet beállítja, de egyszerűen nem indítja el a megszakitási rutint, pedig az adatlap szerinti beállításokat elvégeztem.

Valamilyen módon írasd ki az LCD-re az LVDIE, LVDIP bitek állapotát, valamint az LVDCON teljes tartalmát, hogy biztosak legyünk benne, hogy nem beállítási hiba.

Elvileg le lehetne debuggolni ICD2-vel is a dolgot, de kb. olyan szinten, mint a fenti kiíratással, tehát nem sok haszon lenne itt az ICD2-ből.

Valamint azt is írd le, hogy melyik 18F-ről van szó, és esetleg melyik revízió.

A revíziót - ha nincs ICD2-d, Pickit2-d - ki tudod íratni szintén LCD-re úgy, hogy a 3FFFFE programmemória tartalmát kiíratod.

Csak este tudom megnézni, mert a fejlesztő rendszerem otthon van, Pickit2.
Amúgy 18F452 I/P

Végignéztem az összes revízió errata lapjait, de nem említik egyikben sem, hogy az LVD-vel valami probléma lenne. Szóval vagy a konkrét pic a hibás, vagy a programoddal nem stimmel valami. Tedd fel azt a programot, amiben megszakítást kellene, hogy okozzon, hátha látunk benne valami problémát. Prioritásos megszakítást nem használsz, igaz?

A topic 2. oldalán rajta van, de PicBasic-ben.

Az LVD kezelésben van a beállítás, a program a főprogram ami fut, és ha a tápot leszabályozom 4,7 V alá, megszakítást kellene generálni, az INTERRUPT szerint, és az LVD_PONT rutinban végtelen ciklusba teszi a procit.

Ha a főprogramba teszem be a PIR2.2 (LVDIF) figyelést, akkor ugyan nem megszakítást generál, de érzékeli, és a leállító rutinba kerül.

;========PROGRAM
FPRG: LCDOUT $FE,$80,"ROADMASTER-G"
IF PIR2.2=1 THEN LVD_PONT
GOTO FPRG

LVD_PONT: LCDOUT $FE,$80,"TAP ALACSONY"
IDE: GOTO IDE

Tedd fel a lefordított hex fájlt is, belenéznék, hogy abban mi van. Ha a programod jó, akkor lehet, hogy a fordító csinál valami problémát (ez a hátránya a kevesek által használt fordítóknak, nincs róluk tapasztalat).

Megemlítem, hogy Bootloadert használok, de nem tudom, ez mennyire befolyásolja a témát.
Mint korábban írtam, a SIO kezelés megszakítását azonban tökélestesen kezeli.

Azért azt bem értem, ha van pickit2-d, akkor minek a bootloader?

Szia !
PicKit-et csak a bootloader betöltéshez használok, ugyanis nem egy kütyüről van szó, FW és adtaállomány frissítését így a felhasználó is el tudja végezni az USB-n keresztül, nem kell begyüjteni a küyüket.

Sokszor lehet hallani, hogy a PIC-ben lévő EEPROM-okat nem lehet végtelenszer írni/törölni... ez teljesen érthető is számomra. Mindig fel van hívva az ember figyelme EEPROM használatakor arra, hogy lehetőleg "írás-mennyiség-kímélő" programot írjon, azaz ne legyen mp-enként több százszor irkálva, módosítva az EEPROM tartalma. (Nyilvánvaló, hiszen akkor hamar kimerül az irkálási lehetőség...kb. 10000-100000 írásciklus.)

Szóval a kérdésem az, hogy ezt a csúnya helyzetet valaki valaha az életében tapasztalta már, hogy "megnyekkent" a PIC belső EEPROM-területe túl sokszori írás/módosítás miatt?