Svenska ElektronikForumet

Nu har jag felsökt hela dan och äntligen löste det sig.

Problemet är ingen nyhet och går att läsa i Errata.

Den Pic jag använder är Pic18F4520 men jag gissar att det inte är den enda som lider av det här.

Det hela går ut på att man inte kan använda movff för att lagra WREG,STATUS,BSR vid lågprio-interrupt om man samtidigt använder högprio-interrupt.
Det här är kopierat från en template, så här får man alltså inte göra.
För er som vill ha en mer detaljerad beskrivning så läs i Errata.

Jag har haft olösbara problem tidigare vilket har resulterat i nerlagda projekt.
Nu vet jag att det här har orsakat minst ett nerlagt projekt.

Microchip suger!

Trist problem så klart, speciellt när du har suttit med det själv, men...

> Problemet är ingen nyhet och går att läsa i Errata.

Då så. Och en enkel lösning finns det dessutom.

> Microchip suger!

Hm, för att du "glömde" att kolla Erratan ?
Jag ser inget jättestort problem, det *är* dokumenterat
och det finns en enkel lösning på det.

Microchip kan väl knappast göra mer än att *publicera*
sina Errata Sheets, sen kan de bara hoppas att de *läses* också.

Problemet fanns inte beskrivet när jag hade det första gången för länge sen.
Jag lyckades inte hitta felet då.

Bara nyfiken, hur länge sedan ?

Jag kommer inte ihåg (ja, jag har otroligt dålig tidsuppfattning).

OK

Interrupt felet publicerades i Errata Sheet Rev.B Nov-2004.
Så "länge sedan" bör väl vara tidigare än så, då.

Rev.A av *databladet* kom Jun-2004, så du måste ha varit igång
väldigt tidgt med denna processor. Själv hade jag gissat att
serien kom någongång under 2005 men, tja, tiden går fort...

Som sagt har jag dålig tidsuppfattning (1-4 år är lika länge för mig).
Det jag dock kommer ihåg är att jag beställde direkt från Microchip för jag inte hittade dom någon annan stans.

Jag skummade genom alla errata och följande Picar lider av interruptproblemet (listan kan innehålla fel).


PIC18F2420
PIC18F2520
PIC18F4420
PIC18F4520
PIC18F2455
PIC18F2550
PIC18F4455
PIC18F4550
PIC18F2480
PIC18F2580
PIC18F4480
PIC18F4580
PIC18F2515
PIC18F2610
PIC18F4515
PIC18F4610
PIC18F2525
PIC18F2620
PIC18F4525
PIC18F4620
PIC18F2585
PIC18F2680
PIC18F4585
PIC18F4680
PIC18F6310
PIC18F6410
PIC18F8310
PIC18F8410
PIC18F6390
PIC18F6490
PIC18F8390
PIC18F8490
PIC18F6627
PIC18F6722
PIC18F8627
PIC18F8722

Mycket möjligt, de är i stort av samma "generation" och har säkert
liknande buggar i definitionerna (alltså de högnivå beskrivningar som
genererar maskerna för chip produktionen...) De flesta kisel-buggar
brukar beröra en hel serie av kretsar.

Om just *denna* bugg kan man säga att det dels finns en fungerande
"fix", dels så är det inte så vanligt att man kör med båda interrupt
prioriteterna och då "syns" det ju inte...

Från en del håll har jag hört att "nollorna" (d.v.s 2420/4520/2520/4520)
inte är riktigt stabila än för kritiska applikationer. 242/452/252/452
är däremot "rock-solid"...

Hur som helst, var och en får bedömma om man kan "leva" med
de aktuella buggarna.

Japp, bara att arkivera i det runda och beställa en STK-500 nu grabbar!
* duckar och kastar sig handlöst ut i korridoren *

Lite buggar får man leva med. Trist när man drabbas, men kör man alltid "mainstream" så stöter man sällan på sånt...

Min AVR-ISP ligger där och glänser (dammar).
Nästa gång Picarna inte gör som jag vill så.....