asm: Stack overflow/underflow error...

[JimmyAndersson]

Det var mycket intressant läsning!

Upptäckte just en liten grejj med några av CONFIG-registren:
Jag har datablad 39605D (PIC18F1220/1320) och på bl.a CP0, CP1 osv så hade jag satt dem som ON eftersom det står:

CP0: Code Protection bit (PIC18F1320)
1 = Block 0 (00200-000FFFh) not code-protected.
0 = Block 0 (00200-000FFFh) code-protected.

Men i MPLAB's meny Configure -> Configuration Bits stod det då att 00200-000FFFh var code-protected. Står det fel i databladet?

Anledningen till att jag kollade i den menyn var att XWisp gav fel vid Verifying Fuses Memory när jag skulle testköra koden på PICen. Såg även att CP0, CP1, WRTC, osv var OFF i ett tidigare kodexempel jag fick.

Eller har jag helt enkelt missuppfattat något? Jag tolkade dessa protection bits som att man inte kan skriva till t.ex EEPROMet om CPD är code-protected.

[sodjan]

Du sätter väll CONFIG med t.ex : "CONFIG CP0 = OFF" (o.s.v för de andra.)
Vad som är "1" eller "0" är inte så intressant...

> XWisp gav fel vid Verifying Fuses Memory

Jo, med code protect "ON" så kan ju Wisp628 inte läsa minnet...

> Jag tolkade dessa protection bits som att man inte kan skriva till t.ex
> EEPROMet om CPD är code-protected.

Ja, Om "CPD = ON". Sett det "ON" eller "OFF" beroende på hur du vill ha det.

Sen, språkpolisen, CPD kan inte vara "code-protected".
Det är en flagga/bit som styr om *något annat* ska vara code-protected.
CPD kan vara *write-protected* om "WRTC = ON"...

[JimmyAndersson]

"Du sätter väll CONFIG med t.ex : "CONFIG CP0 = OFF" (o.s.v för de andra.)
Vad som är "1" eller "0" är inte så intressant..."

Med risk för att vara tjatig: Aha!

"Jo, med code protect "ON" så kan ju Wisp628 inte läsa minnet..."

Precis, det var därför jag blev misstänksam mot hur jag hade "ställt in" registren som styr detta.


Sedan har ju språkpolisen helt rätt. Det vore jobbigt om CPD kunde vara code-protected. Då skulle det behöva finnas något som styr CPD's code-protection, osv i all oändlighet....

[sodjan]

> Då skulle det behöva finnas något som styr CPD's code-protection,

Vilket det naturligtsvis gör...
(Förrutom att "code-protection" inte var riktigt rätt ord, men i princip...)

En "Bulk Erase" (som Wisp628 alltid gör först) nollar alla CONFIG register.
Notera att programminnet dock raderas *först*, sedan CONFIG bitarna.
Så man kan inte lura "Bulk Erase" att "öppna" koden...