Creative Commons BY-NC-ND 2.5Questo sito e tutto il suo contenuto sono distribuiti sotto la licenza Creative Commons Attribuzione - Non Commerciale - Non opere derivate 2.5 Italia e con le condizioni d'uso definite nel disclaimer: siete pregati di leggere entrambi questi documenti prima di usufruire dei contenuti di questo sito. Per alcuni contenuti è necessaria una registrazione gratuita: non è necessario pagare e non è necessario accumulare punteggi per accedere agli articoli e scaricare i sorgenti. Basta solo essere onesti. Se volete che questo sito continui a rimanere attivo, a contribuire ogni giorno alla diffusione della cultura libera, non copiate il materiale per ripubblicarlo in altri luoghi : chi fa questo è solo un miserabile e un perdente. Se volete partecipare su settorezero e rendere le vostre idee, i vostri progetti, fruibili da tutti senza limitazioni, come dovrebbe essere in un paese civile e acculturato, potete farlo tranquillamente.

PICMicro che non vengono più riconosciuti dal PICkit? L’errore “No Device Detected”

Autore: Giovanni Bernardo | Data pubblicazione: 2 marzo 2010
Categorie: PICmicro 10/12/16 PICmicro 18 dsPIC / PIC24

no_device_detected_pickitNon 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:

use_vpp_first_program_entryIn 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:

select_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!)

pickit2_must_supply_vdd_to_target

Provo soltanto ad effettuare la cancellazione premendo Erase e incrocio le dita…

pic16f628a_erase_complete

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

L'articolo ti è piaciuto o ti è stato utile per risolvere un problema? Supporta e mantieni in vita questo sito, ci basta soltanto un caffè o una birra.
Se desiderate che settorezero continui a rimanere gratuito e fruibile da tutti, non copiate il nostro materiale e segnalateci se qualcuno lo fa

Puoi lasciare un commento, o un trackback dal tuo sito.

  1. #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. #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.

  3. #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?

  4. #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)…

  5. #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?

  6. #9 da diodo il 24 settembre 2011

    Giovanni Bernardo :
    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.

    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.

  7. #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.

Devi essere collegato per lasciare un commento.

  1. Ancora nessun trackback
settorezero.com e il logo Zroid™ ©2007÷2012 Giovanni Bernardo - E' vietata la copia e la distribuzione anche parziale dei contenuti di questo sito web senza l'esplicito consenso dell'autore.
I contenuti di settorezero.com sono distribuiti sotto una licenza Creative Commons Attribuzione-Non Commerciale-Non Opere derivate 2.5 Italia a cui vanno aggiunte le condizioni d'uso definite nel disclaimer.
settorezero.com e tutti i suoi contenuti sono tutelati dalla legge sul diritto d'autore per cui i trasgressori sono perseguibili a norma di legge.
Creative Commons BY-NC-ND 2.5
Il tema di questo sito è basato sul tema Fusion per wordpress, realizzato originariamente da digitalnature e fa uso del plugin Wassup per il computo delle statistiche. Per contattare l'autore siete pregati di utilizzare la sezione contatti.
Per essere aggiornato con tutte le novità di settorezero.com seguici anche anche su Facebook Twitter Tumblr Blogspot Youtube.