Svenska ElektronikForumet

Hej,
Fick just några samples av PIC16F630 från microchip, när jag lött in dem och slog på spänningen så verkar det som de redan var programmerade. Läste av dem: 0x3ff, dvs oprogrammerade. Trots det så pulsar de ut den interna oscillatorn på RA4 och vägrar att ställa pinnarna till Input då jag håller ner RA3(reset)
Kan inte programmera den heller via min ICD2.

Nämnas bör kanske att jag har ett antal projekt med PIC16F876 och 886 där hårdvaran funkar utan problem.

Någon som stött på något liknande med 16F630?

Hälsningar,
/Henrik

OM de är programmerat och har CodeProtection aktiverat läser du just 0x3FF så den biten kan du knappast lita på.

De verkar i så fall ha intern reset (om det finns på den krets) vilket gör att du måste köra med "VPP-före-VDD"

Kretsarna kommer ju från uChip provlager i Taiwan så de skall väl inte vara programmerade tycker jag.

Skulle kunna vara något med den interna resetten som den har, men jag använder ju uChips egen programmerare ICD2 så den borde ju hantera detta. Jag ska kolla för säkerhets skull så att det inte finns ytterligare någon flagga att sätta i ICDn:s menyer.

Hur menar du med "lött in" ?
Har du ingen testuppkoppling för att verifiera att allt
fungerar med en ny krets? Eller har du använt 16F630 tidigare ?
Det blir ju väldigt struligt att felsöka om allt är fastlött...

Jag menar just "lött in" Eftersom detta är en ytad krets så är det svårt att ansluta den annars.

Sedan kan man ju alltid vara efterklok och börjat med hålade varianter på en prototypbräda men jag och konsulten som ritade ihop kortet var övertygade om att eftersom vi hade använt så många andra varianter i PIC16F-serien, (som ju skall vara väldgt lika inbördes), så kunde vi chansa på ett prototypkort direkt.
Nu visar det sig då att PIC16 midrange inte är kompatibel med sig själv så jag ska beställa hålade komponenter idag och labba lite mera.

Har du någon praktisk erfarenhet av just denna processor så är jag tacksam om du delar med dig av din visdom, annars tycker jag att det räcker med tykna kommentarer.

/Henrik

> annars tycker jag att det räcker med tykna kommentarer.

OK, övriga som eventuellt är intresserade kan läsa vidare...

> jag har ett antal projekt med PIC16F876 och 886 där hårdvaran funkar utan problem.

Det är rellativt annorlunda modeller (båda interna skillnader och helt annat
antal pinnar) så jag vet inte hur mycket den jämförelsen ger igentligen.
Har ni använt någon PIC16 som är mer lik 16F630 ?

> Nu visar det sig då att PIC16 midrange inte är kompatibel med sig själv

Beror på definitionen av "kompatibel"... Skillnader finns alltid.

> Trots det så pulsar de ut den interna oscillatorn på RA4...

Notera att RCOSC och CLKOUT på RA4 är default för en o-programmerad
krets (eller efter en erase-all). Så beroende på vad som sitter på CLKIN
så kan den interna RCOSC gå igång och ge en signal på RA4, även med
en helt ny/blank krets.

Fenomenet med MCLR är svårare att förklare. Kanske fel på erat kretskort ?

Jag har kollat lite snabbt på databladet, men det ger inte så mycket utan att
veta mer om CONFIG och vissa rellevanta delar av applikationen.

Ursäkta Sodjan, jag hade nog alla taggar ut igår.

Jag har inte använt 16F6xx serien tidigare, det är nog där problemen finns. Tack för informationen om RA4, jag får väl koppla bort den pinnen tills jag hittat en lösning.
jag kör följande initiering
__CONFIG(0x3ff4);
// Set config register INT_RC_NO_CLK, WDT OFF, POW_UP OFF, MCLR EXT, BOD ON, CODE PROT OFF, EE PROT OFF

....
// Initiera I/O
// TRIS register har 1 för ingång och 0 för utgång
PORTA=0x00;
porta=0; // mirror in RAM
WPUA=0;
IOCA=0;
TRISA=0x3C; // 0,1 Ut 2,3,4,5 In

PORTC=0x00;
portc=0;
TRISC=0x1F; // 5 Ut 0,1,2,3,4 In

// Init watchdog
OPTION=0xff; // Porta no pullup, WDT prescaler max

// Init timer 1 as internal clock generator
T1OSCEN=1; // LP Oscillator Enable Control bit
TMR1CS=0; // use Fosc/4 as clock (1MHz)
TMR1H=0xDC; // preset to 56536 => 10 000 up to overflow => 10 mS
TMR1L=0xD8;
TMR1ON=1; // activate timer
TMR1IE=1; // enable interrupt

Men, problemet är ju att processorn inte vill ta programmeringen.
Jag tycker att om jag kan läsa processorns typ och version, för det returneras korrekt via ICD2 när jag trycker connect, så ska väl förbindelsen på kretskortet vara rätt. Men man vet ju aldrig... Prototyp platta nästa!

Applikationen är att övervaka en annan processor. Jag har en LPX2138 som skall göra jobbet men för att säkra vissa kritiska IO-signaler så övervakar jag dessa och tillhörande ingångar och om inte LPC:n gör jobbet så kopplar PIC:en bort utgången.

> Men, problemet är ju att processorn inte vill ta programmeringen.

Ja, så var det ja, ja då spelar det kanske mindre roll hur koden ser ut...

Vad får du för fel från ICD2 ? Och är det bara under verifieringen du får fel ?

Bara ett par småsaker. De har sannolikt inte med det aktuella problemet
att göra, men kan vara intressnta i alla fall...

> __CONFIG(0x3ff4);

Måste man ange det så där ? D.v.s så att man tvingas sitta och räkna
bit-positioner i databladet om man vill kolla det ? Din kommentar på
nästa rad är inget värd om man faktiskt vill *verifiera* vad som sätts.

> TRISA=0x3C; // 0,1 Ut 2,3,4,5 In

Varför inte skriva "TRISA = 0b00111100" så blir kommenteraren överflödig.
Det är ju väldigt lätt gjort att man ändrar 0x3C och glömmer att ändra kommentaren.
Det blir en jäkligt svår bugg att hitta...

Samma sak gäller generellt för alla register där man *inte* sätter ett värde,
utan där varje bit har en egen funktion, t.ex OPTION. OK, nu så råkar
just 0xFF vara ganska enkelt att översätta till binärt...

Sen, eftersom de olika bitarna för kontroll av Timer1 har egna bitdefinitioner,
så bårde väl även WPU och WDT ha det också ? Blir mer konsekvent.

Jag kör Hitech C och de har definierade konstanter man kan (=bör)använda. Det är väl en ren slöhet att kopiera från mplabs configuration bits dialog och att använda HEX-koder rakt av. Jag skall bättra mig.

Inga problem att ansluta mot processorn, ICD2 hittar den och visar den korrekt.
ICD2 är ju lite korkad sedan så den programmerar först och verifierar sedan. Jag får :
Programming Target...
...Validating configuration fields
...Programming Program Memory (0x0 - 0x3FE)
...Programming User IDs
Verifying...
...Program Memory
ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val = 0x183, Val Read = 0x3FFF)
ICD0275: Programming failed.

Raden "...Validating configuration fields" gör att det verkar ju som om ICD2 har kontakt och kan skriva in config-ordet. Nu ändrade jag till att inte hämta det från koden utan från mplab dialogen istället, men det blir ingen skillnad.

Frågan är alltså: har du aktiverat Code Protect? (se CONFIG, jag ids inte leta upp det) för i så fall blir det ju fel.

> har kontakt och kan skriva in config-ordet.

Jag vet inte vad "validating configuration fields" betyder i detta sammanhang,
men normalt är config-bitarna det sista som programmeras (efter flash och
eeprom). Det är då man t.ex "lägger locket på" med read-protect, om man
använder det. Så normal så ska det gå att verifiera programminnet även om
man har sagt att man vill ha read-protect. Jag vet dock inte om ICD2 hanterar
det annorlunda, men det verkar osannolikt.

Nej, den är inte aktiverad.

Har ingen erfarenhet av 16F630, men de felmeddelanden du får med ICD2 känner jag igen från när jag skulle till att använda en 16F628.

Jag gör den långa historien kort: För att använda en 16F628 ihop med en ICD2 behöver man en "header"-modul från Microchip. Minns inte exakta namnet / produktnumret, men du kan ju kolla upp lite extra i databladet för 630 om det krävs nåt liknande.

Nu hittade jag i pdf:en "PIC product selector" detta för 16F630 (sid 41):

** Requires ICD specific device with header module – refer to Development Tools.

Så det är med stor sannolikhet det som felar för dig, som det gjorde med mig. En 886 och 876 kräver ingen modul, vilket är anledningen till att de funkar för dig (vilket de gjorde för mig också).

Headern nämns men inte om det gäller både vanlig programmering och debug.
Men är det så så är det i alla fall en förklaring.

Konstigt att inte det upptäcktes när den nya kretsen valdes.
Jag antog att man i alla fall kör med en supportad konfiguration.

En fråga : Har ni läst allt som har med 16F630 att göra i IDC2 "User Guide"
och "Header Board Specification" ??