Sida 2 av 2

Postat: 7 maj 2007, 14:20:51
av Icecap
Med lässkydd på är kretsen skyddad från att läsas men inte från att omprogrammeras.

Postat: 7 maj 2007, 14:32:48
av joel_joel88
tusse skrev:Är man rädd om innerhållet så slår man på lässkyddet. Kontakta sodjan han kan säker ta fram en ny krets till rätt pris.
Förstår inte varför vi ska göra det? Vi har ju källkoden på min dator! problemet är ju bara att det inte går att föra över den.

Postat: 7 maj 2007, 14:36:08
av Icecap
Ni har alltså källkod och kan kompilera den. Har ni testat att läsa till ett ANNAT filnamn än resultatet av kompileringen?

För mig låter det som att ni har problem med programmeringsenheten.

Postat: 7 maj 2007, 15:02:12
av sodjan
> När vi klickar på knappen "verifera" så blir det fel! Men när vi programerar kretsen så fungerar det.

Lite förvirrat här... :-)

*Normalt* så inkluderar en "programmering" av en PIC också en "verifiering" automatiskt.
Jag har väldigt svårt att se att man skulle köra *enbart* själva programmeringen *utan* en
automatiskt verifiering, det verkar väldigt osäkert...

> Vi har ju källkoden på min dator! problemet är ju bara att det inte går att föra över den.

Det är *HEX* filen som ska föras över, inte källkoden!

Sen så frågar jag igen, vad säger AD Teknik som har sålt programmeraren ??

Och självklart går det att programmera om kretsen oavsett om läskyddet
är på eller inte, dock går den inte att verifiera (eftersom den inte går
att läsa). Om ni har fått en färdig HEX fil från en firma, så är sannolikheten
ganska stor att den har lässkyddet "på".

Men om ni även har källkoden så är det bara att bygga om den i MPLAB
och se till att stänga av lässkyddet, då ska verify fungerar OK.

Postat: 7 maj 2007, 15:52:33
av joel_joel88
sodjan skrev:> När vi klickar på knappen "verifera" så blir det fel! Men när vi programerar kretsen så fungerar det.

Lite förvirrat här... :-)

*Normalt* så inkluderar en "programmering" av en PIC också en "verifiering" automatiskt.
Jag har väldigt svårt att se att man skulle köra *enbart* själva programmeringen *utan* en
automatiskt verifiering, det verkar väldigt osäkert...

> Vi har ju källkoden på min dator! problemet är ju bara att det inte går att föra över den.

Det är *HEX* filen som ska föras över, inte källkoden!

Sen så frågar jag igen, vad säger AD Teknik som har sålt programmeraren ??

Och självklart går det att programmera om kretsen oavsett om läskyddet
är på eller inte, dock går den inte att verifiera (eftersom den inte går
att läsa). Om ni har fått en färdig HEX fil från en firma, så är sannolikheten
ganska stor att den har lässkyddet "på".

Men om ni även har källkoden så är det bara att bygga om den i MPLAB
och se till att stänga av lässkyddet, då ska verify fungerar OK.
Det finns tre olika knappar i programet. Läs, Programmera, och Verifera.

Förlåt, jag menade HEX filen. :)

Har inte pratat med AD-teknik.

Någon som brukar använda MPLAB från MicroChips? I så fall vet någon hur man stänger av låsskydet på ett projekt?

Postat: 7 maj 2007, 16:08:03
av sodjan
> I så fall vet någon hur man stänger av låsskydet på ett projekt?

En en assembler källkod gör man det med __CONFIG direktivet...

Finns det något __CONFIG i källkoden i dag ?

Postat: 7 maj 2007, 16:19:06
av joel_joel88
sodjan skrev:> I så fall vet någon hur man stänger av låsskydet på ett projekt?

En en assembler källkod gör man det med __CONFIG direktivet...

Finns det något __CONFIG i källkoden i dag ?
Jepp det finns det. Ska hela den raden bort? :)

Så här ser den ut...
"__config _CP_ALL & _PWRTE_ON & _WDT_ON & _XT_OSC & _BODEN_ON & _MCLRE_ON & _LVP_OFF"

Postat: 7 maj 2007, 16:50:30
av v-g
CP_ALL betyder att CodeProtect är påslaget dvs inget går att läsa från kretsen. Dock borde verifieringen fungera.

Postat: 7 maj 2007, 17:32:07
av sodjan
> Dock borde verifieringen fungera.

Hur då ?
*Ingen* kan läsa från kretsen, inte heller programmeraren,
så vad ska den "verifiera" ??


__CONFIG ska vara kvar, byt bara "_CP_ALL" till "_CP_OFF".

Men notera, detta behövs naturligtvs *bara* för att verify ska
fungera. Om programmeringen fungerar i alla fall, så spelar
det ingen roll för *funktionen* !!

Postat: 7 maj 2007, 17:43:59
av v-g
Såklart funkar det inte då :wall:

Postat: 7 maj 2007, 19:47:34
av joel_joel88
Tusen tack för alla hjälp! Ska testa detta imorgon när jag är i skolan. Hoppas att det ger framsteg. :wink: ¨

EN TILL FRÅGA BARA....kan jag använda 628A i stället med samma källkod? Källkoden är ju för 628 dock, men tänkte om det fungerar ändå.

Tänkte bara säga att det här verkar vara ett toppen forum. Otroligt snabba och bra svar. Tack! :)

Postat: 7 maj 2007, 20:14:59
av bos
joel_joel88 skrev:EN TILL FRÅGA BARA....kan jag använda 628A i stället med samma källkod? Källkoden är ju för 628 dock, men tänkte om det fungerar ändå.
Läs databladet (DS40044B) appendix C.1 (sid 156), där står vad som skiljer dem åt.

Postat: 7 maj 2007, 21:02:56
av sodjan
Notera att många programmerare verifierar *programminnet* innan
CONFIG bitarna bränns in (d.v.s medan det fortfarande går att läsa
från programminnet). Men i detta fall verkade det vara två olika
knappar för "Program" och "Verify" om jag fäörstog rätt, och då
blir det sannolikt problem...

Sen 628 -> 628A.
Det finns ett par små skillnader, som nog gör att man bör bygga om
källkoden och kanske göra en liten justering i källkoden. Men som sagt,
det är väldigt lite och det finns i Appendix-C i databladet (för 628A !).