Non so se si tratta di un errore comune o meno, fatto sta che questa cosa mi ha fatto impazzire non poco e ho pensato quindi di condividerla con i miei lettori nella speranza che possa essere utile a qualcuno, prima che decida di buttare il pic apparentemente difettoso nell’immondizia. In pratica mi è accaduto quanto segue:
Ho scritto un programmino per un PIC16F819 che prevedeva nei fuses di configurazione, il pin MCLR utilizzato come I/O. Appena collegato il PIC tutto ok, avvio la programmazione e la verifica fallisce, tutti i tentativi successivi di andare ad effettuare la lettura oppure di cancellarlo, erano vani e mi si presentava questo minaccioso messaggio di avvertimento che mi ha portato a pensare che il PIC in qualche modo fosse andato perso. La cosa che mi puzzava, però, era il fatto che il PIC, messo nel circuito di utilizzo, eseguiva correttamente il programma.
In un primo istante ho pensato a qualche errore nella word di configurazione, del tipo che inavvertitamente potevo aver inserito le protezioni sull’eeprom o sulla memoria programma, ma non era così. Mi sono quindi detto che il pic in questione era difettoso, ne prendo così un altro uguale.
Stessa, identica cosa! Arrivati a questo punto incominicio ad andare nel pallone. Ricontrollo il circuito di programmazione, smonto il PICKit e verifico le tensioni… Niente da fare… è tutto ok. Mi convinco che sono i due pic ad essere difettosi, tanto più che portano stampato lo stesso numero di lotto. Si trattava quindi di un lotto di produzione difettoso?
Non mi perdo d’animo e riscrivo lo stesso programma per un PIC16F628A, la programmazione parte ma…. arriva alla fine, la verifica fallisce, il pic non può più essere cancellato nè letto ma intanto il programma caricato funziona. Lo stesso problema! A questo punto non poteva più trattarsi di un PIC difettoso. Altri PIC mi funzionavano correttamente e l’unico indagato come causa del problema poteva soltanto essere quel MCLRDIS nella word di configurazione, dal momento che, facendo la prova con altri PIC non dotati di tale funzionalità, non avevo problemi.
Ho quindi pensato che, impostando MCLR come normale linea di I/O, la sua funzionalità andasse in qualche modo “persa” o alterata in fase di programmazione. Il PIC, difatti, come specificato più volte, per essere programmato nella modalità standard (per poter cioè entrare in modalità programmazione, e quindi anche lettura e cancellazione) ha bisogno dei famosi 13.5V sul pin MCLR. Impostando MCLR come I/O, quindi, la funzione di programmazione di tale pin veniva ad essere inficiata. Ma il programma comunque veniva eseguito!
Per controprova mi era rimasto un PIC16F628 (senza A) che pure ha la possibilità di impostare MCLR come I/O. Lo programmo una prima volta mettendo nella word di configurazione il flag MCLRE (per far funzionare MCLR in maniera standard), tutto ok: verifica ok e il pic può essere letto/cancellato. Modifico lo stesso programma cambiando soltanto MCLRE in MCLRDIS: ecco che accade il fattaccio! Ok, mi dico, allora il problema sta proprio qui!
Mi leggo il Midrange, i datasheet dei pic in questione, nessuna informazione a riguardo o qualche appunto che possa farmi capire dove sia il problema. Mi rileggo quindi il manuale del PICKit, deve per forza essermi sfuggito qualcosa da qualche parte! D’altronde nessuno è perfetto. Ecco che al capitolo 1, paragrafo 4 mi salta all’occhio una nota parecchio interessante:
In pratica recita:
“Quando selezionato, permette al PICKit2 di connettersi e programmare i dispositivi nei quali la configurazione e/o il codice possono interferire con i pin che portano i segnali dell’ ICSP impedendone il riconoscimento. L’utilizzo di tale caratteristica prevede che la VDD sia fornita al dispositivo dallo stesso PICKit”
… La configurazione e/o il codice possono interferire con i pin che portano i segnali dell’ ICSP !!
MCLR nella fattispecie rientra proprio in tale categoria. Non continuo nemmeno a leggere, il problema sta qui, me lo sento. Faccio la semplice operazione di selezionare tale opzione nel menù Tools -> Use Vpp First Program Entry:

Mi appare il messaggio che indica che tale funzione è abilitata e quindi la VDD deve essere fornita dal PICKit2 (ok tanto non l’ho mai fornita dall’esterno!)
![]()
Provo soltanto ad effettuare la cancellazione premendo Erase e incrocio le dita…

Il pic viene finalmente cancellato e riconosciuto! Posso tirare fuori quei due poveri, innocenti, 16F819 dalla spazzatura! Da quanto ho potuto capire tale funzione porta la tensione di programmazione (Vpp) sempre al livello richiesto per la prima programmazione. Evidentemente tale tensione viene abbassata per le successive e non risulta sufficiente nel caso che MCLR sia stato “sollevato” dal suo incarico principale, impedendo quindi il riconoscimento del pic collegato. Tale problema non dovrebbe verificarsi nel caso si stesse utilizzando un programmatore su Parallela.
Articoli che potrebbero interessarti
Se desiderate che settorezero continui a rimanere gratuito e fruibile da tutti, non copiate il nostro materiale e segnalateci se qualcuno lo fa

Questo sito e tutto il suo contenuto sono distribuiti sotto la licenza









#1 da S.D.R. il 4 marzo 2010
Buono a sapersi , a casa uso pi PICkit2 quindi se capita … invece al lavoro uso L’ICD2 e mi capita ogni tanto di programmare dei PIC16F819 con pin MCLR impostato come digital I/O ma infatti con questo programmatore non ho mai avuto problemi nellla riprogrammazione .
#2 da Squeck il 18 marzo 2010
Ho lo stesso problema coi del 18LF14K50 e dei 12F683… Però io uso un pickit 2 clone comprato su ebay e la “VPP First Program Entry” non sembra funzionare
#3 da Giovanni Bernardo il 18 marzo 2010
Beh su quelli cinesi non ti so rispondere… E’ comunque un problema causato solo dal pickit, altri programmatori, come pure l’ICD della Microchip, non ce l’hanno. Come già detto suppongo sia un sistema inventato per prolungare la vita dei componenti. Ovvio che i cinesi per farlo “uguale” a minor costo (che poi, a mio parere, non è che il pickit2 costi poi così tanto) qualche problema prima o poi deve venire fuori.
#4 da lodi12 il 11 agosto 2010
Stesso problema: il pic funziona con il suo programma ma non riesco più a programmarlo…epure mclr è impostato come tale… sencondo te il pic è da buttare?
#5 da Giovanni Bernardo il 11 agosto 2010
Hai provato lo stesso a seguire la procedura che ho indicato qui?
#6 da lodi12 il 12 agosto 2010
Niente da fare…ora fra l’altro nn va neanche più il programma e si accende solo il LED1(RD0) (ho la freedom 2)…
#7 da Haru il 14 marzo 2011
Io ho lo stesso problema (no device detected) con dei 16F777.
Strano però che questi pic non siano MAI stati usati e/o programmati. Sono così come la fabbrica li ha fatti.
ho provato l’opzione vpp first program entry, ma non cambia assolutamente nulla.
può essere una soluzione provare a cancellarli o programmarli con qualsiasi cosa su una easypic a scuola?
#8 da Giovanni Bernardo il 14 marzo 2011
Può anche dipendere da un problema di collegamento. Puoi provare pure sull’easy pic, certo
#9 da diodo il 24 settembre 2011
Ciao a tutti.
Questo non è un problema solo del pickit2 ma anche di altri programmatori (easypic5, ad esempio) ed anche altri su parallela.
Durante la programmazione “normale”, il pin mclr esiste fisicamente e può essere pilotato dalla VPP (13V) di programmazione senza problemi, anche se, questa, viene data dopo la VDD (5V) di alimentazione.
Se, invece, il pin mclr viene disabilitato, fisicamente non esiste più, perchè quel pin ora è un I/O.
Se ora diamo alimentazione al pic (VDD) e poi applichiamo la VPP di programmazione, questa la applichiamo al pin di I/O e non al pin mclr.
Nelle “programming specifications” di ogni serie o singolo PIC viene indicato con quale tempistica deve essere applicata la VPP. Nel caso del PIC16F628A (e altri), la VPP deve essere data in anticipo rispetto alla VDD di alimentazione, così il core del PIC “capisce” che si sta per iniziare la programmazione e tratta il pin “ex mclr” come vero mclr.
Alcuni programmatori, che non hanno l’applicazione delle tensioni VPP e VDD indipendenti, non potranno programmare i pic con mclr disabilitato.
Vedere le specifiche di programmazione del 628A:
http://ww1.microchip.com/downloads/en/DeviceDoc/41196g.pdf
In questa pagina ci sono tutte le altre:
http://www.microchip.com/TechDoc.aspx?type=Programming
Sperando di non aver creato ancora più confusione sull’argomento, vi saluto con un grande CIAO.
#10 da Giovanni Bernardo il 24 settembre 2011
No, anzi! Hai chiarito perfettamente il significato di quel “first program entry”, che va inteso come “prima di entrare in modalità programmazione”
#11 da Electroemme il 24 dicembre 2011
Ciao.
Queste utilissime informazioni mi capitano giusto a “fagiolo”…. Ho da poco acquistato un PIK KIT2 (originale) e lo sto utilizzando con un 16F627A. Sinora non ho mai impostato iI pin MCLR come input, ma se mi capitasse il problema in questione ora saprei cosa fare!
A proposito, ma i PIC ..627 ..628 (senza la A finale) sono compatibili con il PIC KIT 2? Dal tuo articolo e dalla tua prova sembrerebbe di sì, ma ho visto nelle impostazioni di MPLAB dal menu Configure -> Select Device, nella medesima finestra che alla sezione “Programmers” c’è il pallino rosso alla voce PICkit2.. Possiedo sia il ..627 che il 627A, (infatti i miei primi esperimenti sono partiri dal ..627, ma usavo un altro programmatore hobbystico) e vedendo poi le impostazioni sono “migrato” al ..627A, usando il PIC KIT 2. Proverò a fare una controprova.
Ad ogni modo grande Settorezero! continua così! complimenti per la chiarezza e la completezza di vari argomenti.
Buon Natle e Buon 2012.
#12 da Giovanni Bernardo il 24 dicembre 2011
Si sono tutti equivalenti. Le versioni con la A sono più recenti e hanno soltanto una differente organizzazione della memoria che li rende più veloci in fase di programmazione ma per il resto sono identici: il codice di un 627 lo puoi caricare su un 627A, su un 628, 628A e su un 648 senza cambiare niente.
#13 da Electroemme il 27 dicembre 2011
Ok! Ma dalla impostazioni di MPLAB (parlando solo di programmazione, cioè il caricamento del .HEX) sembrerebbe che i 627 e 628 (senza A) non siano compatibili con il PIC KIT2, magari è solo un errore di prgrammazione della finestra “Select device” (i pallini rossi). Faccio presente che è da poco che sto familiarizzando con MPLAB.
#14 da Giovanni Bernardo il 27 dicembre 2011
Io direi che se te lo programma non ti devi fare problemi. E’ probabilmente un bug di MPLAB.