PicKit2 (clone) foutjes met schrijven/erasen - how come?

Ik heb een pickit2 clone aangeschaft (sure electronics), deze voorzien van de nieuwste firmware via de software van Microchip, maar krijg het helaas niet echt aan het werk.

De pickit2 software herkent het type pic correct (16f628a), en gaat desgevraagd druk aan de slag met programmen of erasen. Als ik het resultaat teruglees zitten en echter altijd een paar foutjes in.

Opvallend is dit: Als ik de chip erase dan zou hij hem moeten volschrijven met 3FFF waardes, maar als ik teruglees zit er zo nu en dan een 3FFD tussen. De plaats verschilt, maar er zitten er altijd een paar, en nooit iets anders dan 3FFD.

Ik heb het geprobeerd zowel met de pic gevoed uit de programmer als met een eigen schone 5 volt voeding, ontkoppelcondensatortjes aangebracht, RB4 laag getrokken, etc etc, maar het lijkt niets te helpen. Ook heb ik het met een andere 16F628A geprobeerd met hetzelfde probleem.

Iemand enig idee wat hier aan de hand kan zijn?

Geen idee. Maar wel weer voor mij de bevestiging dat goedkope klonen lang niet altijd werken. Helaas hoor ik teveel van dit soort signalen.

Probeer eens een oudere versie van de firmware.

Zou het aan de clone liggen denk je?

Voor zover ik begrepen heb is de hardware identiek aan het origineel, en is het ook wel een veelgebruikt ding. Googelen heeft me weinig verder geholpen, terwijl ik toch zou verwachten dat meer gebruikers dit probleem hebben met iets dat zoveel verkocht wordt.

Heb je het al eens met een nieuwe PIC geprobeerd ?

[MMSoft denkt: Jammer dat er mensen zijn die een Clone kopen, en niet een beetje meer uitgeven voor een echte PICkit2, die perfect werkt]
[Bericht gewijzigd door MMSoft op 4 september 2008 07:24:48]

Even voor de zekerheid, heb je een 47uF en een 100nF zo dicht mogelijk bij de pic?

quote:

Heb je het al eens met een nieuwe PIC geprobeerd ?

Dat wel, maar dat is ook een 16f628a, een ander type heb ik helaas niet bij de hand.

quote:

Even voor de zekerheid, heb je een 47uF en een 100nF zo dicht mogelijk bij de pic?

Hoe kritisch komt dat? Er staat een 15u en een 2n2 over de voeding, in een breadboard een paar cm van de pic. Ik kan anders wel even een ceramic of multilayer pal over het ic erin prikken...

Maakte de Pickit2 gebruik van 'Vpp before Vdd' programmering ?
In dat geval voorzichtig zijn met grote elco's parallel met de PIC op een breadbord.

De 100nF is er om de oscillatie tegen te gaan, als je die te ver weg zet dan heb je er bijna niks meer aan.

De 47uF is om spanningsvallen even op te vangen.

Zonder de 100nF heb ik altijd programmeer fouten, de max afstand die ik kan hebben is 6cm. Zonder de 47uF had ik een keer een lcdtje die raar doet.

Wat ik altijd bij kleine picjes doe (1Vcc). De 100nF onder of boven de pic met een 47uF er overheen (pas met lange poten makkelijk) dan met zo kort mogelijke draadjes naar de Vcc van de pic en de massa op me breadbord.

Bij een pic met 2 Vcc's zitten de Vcc en Vss altijd boven elkaar, dan stop ik aan beide kanten een 100nF en aan een kant een 47uF

Ik gebruik dezelfde programmer maar ik nog nooit programmeer fouten ontdekt bij het programmeren. Gebruik makend van breadboard en draadjes van plusminus 15cm zonder condensatoren etc, geen probleem. Het lijkt me toch wel bijzonder dat het aan de voeding zal liggen...

Zoals D2PCC schrijft gaat het om Vpp before Vdd bij de 628. In de datasheets staat dat de stijgsnelheden van de Vpp en Vdd niet te laag mogen zijn. Elco's kunnen dat verzieken. Ik programmeer altijd zonder ontkoppel-Cs (en natuurlijk wel tijdens normaal gebruik), zonder enig probleem.
Zijn de lijnen van PICKIT naar je bordje met de PIC niet te lang?

De draden zijn niet te lang, gewoon het bijgeleverde bandsnoertje van ca 20 centimeter, en dan nog maximaal 5 op het breadboard. Overigens heb/had ik hetzelfde probleem met de bijgeleverde 'box' met ZIF-sockets.

Wat me nu echter is opgevallen: De fout lijkt niet in het schrijven, maar in het teruglezen te zitten. In eerste instantie viel het me niet op, maar als ik na erasen een een paar keer een 'read' doe, dan wisselen de plaasten van de 3FFD-ipv-3FFF fouten.

Het lijkt verder niet veel met ontkoppeling van doen te hebben, of ik nou alle c'tjes eruit trek of niet, maakt geen enkel verschil.

Het is me gelukt er werkend een simpel stuk je 'blink a led' code in te schrijven (dank voti!), maar andere software lukt (schijnbaar) niet...

Kan dat liggen aan de software, of kun je in principe alles wat je wil (zeg random data) naar het program memory van een PIC schrijven en weer terughalen?

Behalve sommige vormen van configuratie (bv codeprotection) kan je willekeurige informatie in je PIC zetten, zonder enige invloed op lezen of schrijven.

Wat gebeurt er als je een hexfile programmeert? Weigert de PICKIT wegens fouten in de blankcheck of geeft hij programmeerfouten?

Weigeren doet het niet, het begint gewoon te programmeren. Soms geeft het een foutmelding op de verificatie, maar dat zou even goed een lees- als een schrijffout kunnen zijn.

Als ik er een stukje eigen code in probeer te plaatsen werkt het in ieder geval niet, maar dat zou natuurlijk ook best aan de code kunnen liggen... is er een of andere manier om een hexfile te valideren?

Als de programmer niet goed programmeert heeft het weinig zin de PIC op zijn verdere werking te testen.
De enige controle op de hexfile zijn de checksums op elke regel, maar daar kijkt de programmer al naar. Het is erg onwaarschijnlijk dat daar de fout zit. Een niet werkend programma heeft meestal een programmafout of een verkeerd gebouwde schakeling. Heb je wel eens een simulatie geprobeerd (MATLAB-SIM)?

Alles bij elkaar genomen lijkt het erop dat je PICKIT niet goed werkt. Om dat nader te bepalen moet je toch denken aan het programmeren met een andere programmer om zeker te zijn dat je PIC's wel goed zijn of een ander type PIC proberen om te kijken of het probleem PIC-gevoelig is.

Overigens, werk je wel netjes: goed beveiligd tegen opbouw van statische elektriciteit (mat+polsband)? De PICjes zijn nogal gevoelig voor doorslag. Het kan een oorzaak zijn van een serie PICjes die gelijk maar toch fout gedrag vertonen.