Svenska ElektronikForumet

Bosen skrev:hur gick det???

Det hjälpte att erase:a kretsen med jumpern satt. Men för att programmera den på nytt får jumpern inte vara satt (då blir det samma fel som jag skrivit här), så det blir ett himla jumprande nu för tiden.

Lyckas dock inte begripa varför PIC:en ballar ur bara för att jag använder Timer1 i koden. Det kan väl knappast vara så dåligt designat av Microchip att det är för att T1-oscillatorn sitter på samma pinnar som PGC/PGD?

Det är inte timer1 utan mclr.

OK, men jag ser ändå inte korrelationen för hur felet bara kan uppstå när jag använder Timer1 i min kod. Om jag låter T1OSCEN = 0 så får jag inte felet, och det tolkar iallafall jag som det är något med Timer1.

(Därmed inte på något sätt sagt att det är rätt tolkning)

Hm, jag har ett minne av att ha sett lite rapporter med timer1/ICSP problem.
Om det bara räckta med att starta timer1, eller om det hade med kristall-kondingar
att göra minns jag inte.

> Om jag låter T1OSCEN = 0 så får jag inte felet,

Det är alltså den enda ändringen som du gör ? Enbart denna bit ?
Jo, i så fall är det lite märkligt...

Kristallpinnarna för T1-oscillatorn är ju desamma som programpinnarna. Vill minnas jag sett något om att ifall exekveringen tillåts starta innan den ställs över i programmeringsläge så kan en av dessa pinnar låsa sig som utgång, men kan inte hitta detta det nu igen.

Problemet har alltså inte med själva T1 att göra, utan med den extra oscillatorn.

Har själv aldrig använt extra oscillator, utan kört timern från processorns ordinarie klocka. Skall den inte kunna snålköras på reservbatteri så finns det ingen anledning att ha en extra kristalll. Med rätt programvara så kan frekvensen på processorkristallen vara hur udda som helst.

Jag tror att det är så som Marta "minns".
T1-oscillatorn stör på något sätt ICSP.
Det är möjligt att med rätt input till Google så kan man får träff på detta...

sodjan skrev:T1-oscillatorn stör på något sätt ICSP.

Vilket är det jag redan skrivit flera gånger...men folk har istället gett MCLR skulden.

Jag har fortfarande problem med min 12f675, men det verkar som det inte spelar någon roll vilken kod det är.. efter några gånger går det inte att programmera om. Jag har efter att ha googlat en massa en ny fråga:
Enligt databladet så rekomenderas 1k motstånd eller högre pullup till mclr. Jag har 1.5k just nu, Vad rekomenderar ni??

OK, nu skäms jag!!
Inte bara att jag har tagit över bos tråd!!!!... jag har upptagit er tid med idioti.....nästan iallafall....
när jag plockade bort pullup motståndet till MCLR så va det inga problem att programmera kretsarna.... varför har jag inte testat det tidigare??? Varför det inte går att programmera med 1.5k pullup till MCLR kan jag ändå inte förstå....


EDIT:
nu skäms jag ännu mer!
Felet att jag inte kan programmera om med pullup på mclr är att jag hadde glappkontakt på min 1000µF kondig till matningen (7805). ...eller kanske inte klappkontakt... benet var av så det gav ingen kontakt alls!!!! TRIAL AND ERROR heter det väl

Kör med 10K jag och det har alltid fungerat prima. Hittar ej rekommenderat värde i databladet till 628 heller.

Vad jag kan se till 628:an (sida 99 i databladet) så är rekomederat värde 10k - 100k (om jag nu fattar databladet rätt)

Om du menar fig. 14-5 så är det för en annan pinne. Jag har letat med mclr geom hela dokumentet så det måste stå under nåt annat.

oj... ja, det gick lite fort när jag tittade igenom databladet.... den bilden va ju inte för MCLR!

När det gäller pullup till MCLR så spelar det ju ingen som helst roll för
själva *processorn* vilket värde den har. Det ända den bryr sig om är
att pinnen ska ligga "hög" normalt och "låg" för att få en reset. Alltså
så finns det inget i databladet om det förrutom eventuellt något exempel
på en typisk koppling. Men processorn i sig struntar alltså i värdet, den
styrs av *spänningen* på MCLR.

Vilket värde man använder har mer med vad kopplar in mer till samma
pinne, t.ex resetknappar eller en programmerare. Ett värde mellan
10K och 100K får nog anses som "normalt", men även 1M kan också
fungera om det är i en "snäll" miljö utan allt för mycket störningar...

Jag har samma problem:

D:\Program\PICC\Examples>xwisp2w test676
xwisp2 version 1.9.5 for Windows (Jan 24 2008, Open Watcom C/C++ 1.70)
File test676.hex loaded and is Intel Hex format conforming
Detected programmer: Wisp648, firmware version 1.23
Target not auto-detected, please specify on commandline!
xwisp2 failed after 1.14 seconds, rc 23
Press 'Enter' to continue:

Tycker jag har provat med allt, men jag lyckas inte få igång det... har provat med D:\Program\PICC\Examples>xwisp2w TARGET 16F676 go test676, men då blir resultatet:
D:\Program\PICC\Examples>xwisp2w target 16f676 go test676
xwisp2 version 1.9.5 for Windows (Jan 24 2008, Open Watcom C/C++ 1.70)
File test676.hex loaded and is Intel Hex format conforming
Detected programmer: Wisp648, firmware version 1.23
Target not auto-detected, using specified target: 16F676
Target erased
Transferring program to 16F676 via Wisp648
Transferring program memory...100%
Verifying program memory...... 0%failed at 000000, expected: '3000', found: '3F
FF'
Write-Verify operation failed after 1.12 seconds, rc 21
xwisp2 failed after 2.69 seconds, rc 21
Press 'Enter' to continue:

Vad göra?