"Target not auto-detected", fast det just fungerat
Jag har alltid kopplat in den vita kabeln från wisp628 till LVP (pin10). Har i efterhand läst att det i vissa fall är onödigt, men då jag inte sett att det kan innebära någon skada att göra det så har jag fortsatt att koppla in alla kablar...
Hela projektet finns nu på http://marcus.ax/filer/SerialServoDriverTx.zip. OBS! Eftersom en av filerna (rs232.asm) inte låg i projektmappen var jag tvungen att ta bort den från projektet, kopiera filen till projektmappen och sedan lägga till den nya rs232.asm i projektet. Hex-filen ändrades då på några ställen, men det finns med en fil kallad 'Kopia av SerialServoDriverTx.hex'. Den filen är en kopia av den hex-fil som fördes över till picarna.
Jag får lov att återkomma imorgon, klockan är 02.30 här...
Hela projektet finns nu på http://marcus.ax/filer/SerialServoDriverTx.zip. OBS! Eftersom en av filerna (rs232.asm) inte låg i projektmappen var jag tvungen att ta bort den från projektet, kopiera filen till projektmappen och sedan lägga till den nya rs232.asm i projektet. Hex-filen ändrades då på några ställen, men det finns med en fil kallad 'Kopia av SerialServoDriverTx.hex'. Den filen är en kopia av den hex-fil som fördes över till picarna.
Jag får lov att återkomma imorgon, klockan är 02.30 här...
OK.
Jag ska test-flasha din HEX fil senar i dag så får vi se vad som händer.
Sen tycker jag att du ska lägga till CONFIG2 också.
Annars var det väl inget speciellt, några småsaker som inte har med
flashnings problemet att göra (som att testen av TXSTA, TRMT och laddningen
av TXREG skulle kunna vara i annan ordning för att inte vänta i onödan)...
EDIT:
Det fungerar *oftast* utan den vita LVP kabalen, men om man ansluter den
så sköter Wisp628 om pinnen när det behövs...
Jag ska test-flasha din HEX fil senar i dag så får vi se vad som händer.
Sen tycker jag att du ska lägga till CONFIG2 också.
Annars var det väl inget speciellt, några småsaker som inte har med
flashnings problemet att göra (som att testen av TXSTA, TRMT och laddningen
av TXREG skulle kunna vara i annan ordning för att inte vänta i onödan)...
EDIT:
Det fungerar *oftast* utan den vita LVP kabalen, men om man ansluter den
så sköter Wisp628 om pinnen när det behövs...

Programmet är som sagt ett snabbt hopkok, en tredje gradens omskrivning av ett gammal test - taskigt skrivet och ännu sämre kommenterat! Tanken var (är) att snabbt testa om mina idéer fungerade (de externa komponenter och kopplingar jag använde, etc). Om det fungerade så skulle jag börja och skriva ett nytt program helt från början, och t.ex. läsa in mig ordentligt på A/D. Nu var målet bara att få det att fungera för detta test 
Tack så mycket för att du (och många andra) tar sig tid att hjälpa till!

Tack så mycket för att du (och många andra) tar sig tid att hjälpa till!
- Christopher
- Inlägg: 25
- Blev medlem: 7 februari 2007, 00:00:34
- Ort: Malmö
Satte ihop adaptern jag köpt för att kunna programmera kretsar med Internal-MCLR. Har just testat att programmera en av de strulande PICarna med adaptern inkopplad, men med samma dystra resultat som tidigare.
Använder din 1A@5V för labbplatta, sodjan - när jag använder kretsen för Internal-MCLR (som alltså kortslutet strömförsörjningen en kort stund), skall detta märkas på något sätt? T.ex. att LEDen på 1A@5V blinkar, eller så? Jag märkte ingen skillnad mellan att använda Internal-MCLR-adaptern eller ej - LEDen lyste hela tiden, och varken 7805an eller TIP120an blir ens lite varma. Kan ju hända att adaptern inte fungerar (felkoppling, defekt el. dyl.), så jag skulle vilja veta hur jag kan vara säker på att den fungerar.
Använder din 1A@5V för labbplatta, sodjan - när jag använder kretsen för Internal-MCLR (som alltså kortslutet strömförsörjningen en kort stund), skall detta märkas på något sätt? T.ex. att LEDen på 1A@5V blinkar, eller så? Jag märkte ingen skillnad mellan att använda Internal-MCLR-adaptern eller ej - LEDen lyste hela tiden, och varken 7805an eller TIP120an blir ens lite varma. Kan ju hända att adaptern inte fungerar (felkoppling, defekt el. dyl.), så jag skulle vilja veta hur jag kan vara säker på att den fungerar.
Jag vet inte exakt hur *länge* den kortsluter spänningen, men Wouter's hemsida
säger "a few milliseconds", så man kanske inte hinner se det...
Det är bara (eller ska bara vara) under tiden som Vpp hinner
upp till 13V. Sen, eftersom trissan i den lilla adaptern ju kortsluter
spänningen, så fårt det inte sitta *allt* för mycket capacitans på
5V'en. Det sitter 100uF på den lilla 5V-PSU'n, och jag vet inte på
rak arm om detta är för mycket för trissan eller inte...
Vi fortsätter tisdag...
EDIT:
Det vore också bra att få allt annat verifierat, d.v.s Wisp628 med en
annan PIC och ett annat program. Har du kollat Wisp628'an så att
det inte har hänt något där ? Glapp i en lödning eller något.
säger "a few milliseconds", så man kanske inte hinner se det...
Det är bara (eller ska bara vara) under tiden som Vpp hinner
upp till 13V. Sen, eftersom trissan i den lilla adaptern ju kortsluter
spänningen, så fårt det inte sitta *allt* för mycket capacitans på
5V'en. Det sitter 100uF på den lilla 5V-PSU'n, och jag vet inte på
rak arm om detta är för mycket för trissan eller inte...
Vi fortsätter tisdag...
EDIT:
Det vore också bra att få allt annat verifierat, d.v.s Wisp628 med en
annan PIC och ett annat program. Har du kollat Wisp628'an så att
det inte har hänt något där ? Glapp i en lödning eller något.
Wispen fungerar såvitt jag förstår utmärkt. Suttit och testat lite i helgen med två 16F688, och det har inte varit några som helst problem. T.o.m. 'xwisp2w PASS AUXI [...]' fungerar.
Skulle kanske vara värt ett försök att ta bort 100uF från 5V-PSUn? Eller ta en 16F683 och slå på Internal-MCLR - så man ser om adaptern fungerar som den ska...
Skulle kanske vara värt ett försök att ta bort 100uF från 5V-PSUn? Eller ta en 16F683 och slå på Internal-MCLR - så man ser om adaptern fungerar som den ska...
Har nu provat lite saker. TIP120an på adaptern fungerar, så själva adaptern bör fungera. Lyckades en gång få datorn att känna igen en av de strulande PICarna, men då får jag samma fel som när jag skriver 'target 16F88':
Transferring program memory...OK!
Verifying program memory.......failed at 000000, expected: '0000', found: '3FFF'.
Testade även med ett motstånd mellan 5V och PICen. Gav inget resultat (hade dock motståndet där när PICen kändes igen den där enda gången).
Transferring program memory...OK!
Verifying program memory.......failed at 000000, expected: '0000', found: '3FFF'.
Testade även med ett motstånd mellan 5V och PICen. Gav inget resultat (hade dock motståndet där när PICen kändes igen den där enda gången).
CONFIG-raden på PICen är givetvis den som jag nämnt i början på detta träd... Programmet som jag nu försöker föra över ser ut så här:
Testade med target en gång förut på dessa två PICar, och kunde då konstatera att PICen förblev oförändrad - PICen körde exakt samma program som innan jag försök med target...
Kod: Markera allt
LIST p=16f88
include "p16f88.inc"
__config _CONFIG1, _CP_OFF & _CCP1_RB0 & _DEBUG_OFF & _WRT_PROTECT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _MCLR_ON & _PWRTE_ON & _WDT_OFF & _INTRC_IO
__config _CONFIG2, _IESO_OFF & _FCMEN_OFF
nop
Loop
nop
goto Loop
end
Fantastiskt! Lyckades programmera om båda PICarna nu! Är inte helt säker på hur det gick till, men jag har en gissning.
Kopplade ihop på nytt för att ta en bild, som ni kan se nedan. Fick det plötsligt att fungera en gång, men sen vägrade det igen. Kände numera igen processorn, men programmeringen falerade. Kopplade då bort motståndet mellan MCLR och 5V (invid Vdd för PICen), och då fungerade det utmärkt igen. Kopplade bort Internal-MCLR-adaptern, och konstaterade att det nu fungerade även utan den. Lade i den andra PICen, men då krävdes åter igen adaptern för den första omprogrammeringen. Därefter kunde även den programmeras utan adaptern.
Jag har testat utan det motståndet förut, men så vitt jag minns har jag inte testat utan det sedan jag stoppade ett 47?-motstånd mellan 5V-Vdd. Hade först ett 27?, men det måste ha varit för litet. Jag antar dessutom att motståndet mellan MCLR och Vdd (10k) gjorde så att PICen iaf fick ström via den spänning Wispen lade på MCLR.
Kan detta vara en möjlig förklaring? Kan fortfarande inte förstå varför det skulle vara Internal-MCLR på de där PICarna, dock.

Kopplade ihop på nytt för att ta en bild, som ni kan se nedan. Fick det plötsligt att fungera en gång, men sen vägrade det igen. Kände numera igen processorn, men programmeringen falerade. Kopplade då bort motståndet mellan MCLR och 5V (invid Vdd för PICen), och då fungerade det utmärkt igen. Kopplade bort Internal-MCLR-adaptern, och konstaterade att det nu fungerade även utan den. Lade i den andra PICen, men då krävdes åter igen adaptern för den första omprogrammeringen. Därefter kunde även den programmeras utan adaptern.
Jag har testat utan det motståndet förut, men så vitt jag minns har jag inte testat utan det sedan jag stoppade ett 47?-motstånd mellan 5V-Vdd. Hade först ett 27?, men det måste ha varit för litet. Jag antar dessutom att motståndet mellan MCLR och Vdd (10k) gjorde så att PICen iaf fick ström via den spänning Wispen lade på MCLR.
Kan detta vara en möjlig förklaring? Kan fortfarande inte förstå varför det skulle vara Internal-MCLR på de där PICarna, dock.
