Microcontrollori PIC che non vengono piu´ riconosciuti dal PICkit? L’errore “No Device Detected”

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.