Impossible d'effacer un PIC 16F628A

[Montd'est]

Bonjour à tous,

Je ne débute pas avec les PIC de manière générale, mais je débute avec la référence 16F628A:

J'ai fait des essais de programme pour voir si j'arrivais à m'en servir, mais je n'arrive plus à effacer la mémoire flash ou à réécrire un nouveau programme par dessus. Mon PIC est tout neuf.

J'ai essayé avec mes 2 programmateurs différents: un PIC PG3 et un Velleman K8076, en utilisant respectivement les logiciels IC-PROG pour le premier programmateur et PICprog2009 pour l'autre, rien y fait.

J'espère que j'ai pas bloqué définitivement mon composant avec un "code protection" involontairement ou quelque chose comme ça.

J'arrive à lire la mémoire avec les 2 programmateurs.


Quelqu'un aurait une idée ? merci.
-----

[F1FNW]

Si tu as mis le "Code protect", tu peu pas le lire, mais tu peux l'effacer, donc c'est pas le problème. je pense que c'est ton composant qui a un problème car il n'y a rein de particulier dans le fonctionnement du PIC16F628. Essai avec un autre PIC!

[invite03481543]

Bonsoir,
Aucun message d'erreur?

[invite03481543]

La carte est celle avec laquelle tu as programme pour la premiere fois ton PIC?
Je verifierai la patte Vpp/MCLR pour voir si quelque chose ne l'empeche pas de monter a Vpp

Car si pas de message d'erreur c'est que pour le programmateur tout s'est bien deroule, or si tu ne peux effacer avec un code encore dedans c'est que la verification a du echouer (si le code a rentrer est nouveau evidemment).
Si le code est le meme il ne verra pas d'erreur a la relecture.
Donc pour moi c'est a l'effacement donc au niveau du Vpp.
@+

[A voir en vidéo sur Futura]

[Montd'est]

Les 2 cartes avec lesquels j'ai fait mes essais de programmations sont les seules à avoir été utilisé pour tenter de programmer depuis le début.

J'ai parfois un message d'erreur quand j'essais d'écrire avec la K8076 sous PICprog 2009. "error writing to pic" qui apparaît dans la demi-seconde après avoir demandé d'écrire.
Pas de message de la part d'IC PROG, quand je tente avec l'autre carte.

J'ai mesuré la tension entre MCLR et la masse pendant une tentative d'écriture: je trouve autour de 12,8 V avec la carte PIC PG3.

Une tension apparaît de manière brève avec la carte K8076 de vois j'afficher de 6.5 à 8.5 V environ, pendant une fraction de seconde ( le temps que le message d'erreur apparaisse. ) Je pense que ça monte bien à 12.8 V en fait mais que le voltmètre n'a pas le temps de le voir.

Pendant les tentatives d'effacement: même phénomène: une tension de 6.5 à 8.5 V environ apparaît brièvement. après une lecture, la mémoire est toujours chargé avec l'ancien programme.
J'ai essayé d'en écrire des nouveaux de taille très différente pour éviter de les confondre mais rien y fait, l'ancien ne veut pas s'effacer.

[elektrax]

vos programateurs ont-ils une alim externe dédiée ?

[Montd'est]

J'utilise un adaptateur régulé 15 Vcc je peux le régler jusqu' à 18 Vcc ( régulateur linéaire ) mais même sous 18 V ça ne change rien.

[freepicbasic]

si la pin MCLR est programmé en I/O
La tension VPP doit arrivée avant Le VCC pour le programmer.
Si le programmateur ne le fait pas, il faut ajouter un transistor qui alimente le pic avec comme commande le VPP.

[invite03481543]

J'utilise un adaptateur régulé 15 Vcc je peux le régler jusqu' à 18 Vcc ( régulateur linéaire ) mais même sous 18 V ça ne change rien.

Ce que elektrax vous demande c'est si votre micro est alimenté par la carte au moment de la programmation ou si c'est le programmateur qui assure l'alimentation de la cible.
Le plus sûr est que le micro soit alimenté par son environnement (la carte dans lequel il évolue), ainsi le programmateur n'a rien d'autre à alimenter et les niveaux Vpp, clock et data restent corrects.

[Montd'est]

Mon application et ma carte de programmation n'ont aucun point de raccordement électrique en commun, je ne fait pas d'ICSP, j'extrais toujours le composant de mon application pour ensuite l'insérer dans le programmateur.

[Montd'est]

Est-il possible de griller partiellement un PIC par une manipulation malencontreuse ? C'est dire que la mémoire soit lisible mais plus ré-inscriptible ?

Car je viens de me rappeler que j'ai fait des essais au début: or j'ai l'habitude avec les PIC16F84A, de brochage ressemblant au 16F628A, de raccorder la broche MCLR directement au 5V sans résistance de tirage.

Ayant oublié que dans le 16F628A la broche MCLR peut être configuré en sortie, je l'ai aussi raccordé directement au 5V comme pour le 16F84A, il est possible de penser que si cette broche a été programmé à un moment en sortie, il y ait eu un court-circuit à la rencontre du 5V.

Un tel court-citcuit pourrait-il endommager partiellement le PIC et faire qu'une partie de la circuiterie interne liée à la fonction MCLR, soit inopérante et rende toute programmation définitivement impossible ?

[invite03481543]

Mon application et ma carte de programmation n'ont aucun point de raccordement électrique en commun, je ne fait pas d'ICSP, j'extrais toujours le composant de mon application pour ensuite l'insérer dans le programmateur.

Il va falloir changer vos habitudes, on ne travaille plus comme ca depuis des lustres.
Le simple fait d'enlever le µC lui fait prendre un risque de chocs électrostatiques mortel.

[invite03481543]

Est-il possible de griller partiellement un PIC par une manipulation malencontreuse ? C'est dire que la mémoire soit lisible mais plus ré-inscriptible ?

Car je viens de me rappeler que j'ai fait des essais au début: or j'ai l'habitude avec les PIC16F84A, de brochage ressemblant au 16F628A, de raccorder la broche MCLR directement au 5V sans résistance de tirage.

Ayant oublié que dans le 16F628A la broche MCLR peut être configuré en sortie, je l'ai aussi raccordé directement au 5V comme pour le 16F84A, il est possible de penser que si cette broche a été programmé à un moment en sortie, il y ait eu un court-circuit à la rencontre du 5V.

Un tel court-citcuit pourrait-il endommager partiellement le PIC et faire qu'une partie de la circuiterie interne liée à la fonction MCLR, soit inopérante et rende toute programmation définitivement impossible ?

Réponse: OUI

[Forhorse]

Je dirais plutôt NON
RA5 est uniquement une entrée, il n'est pas possible physiquement de le configurer en sortie.

[invite03481543]

En effet, merci d'avoir corrigé

A vérifier ce qui se passe dans la doc si l'entrée RA5 est mise en entrée (donc tirage au Vcc en interne) et sur laquelle ont appliquerait Vpp...

[Montd'est]

Effectivement, je viens de vérifier sur la documentation: impossible de configurer A5 en sortie, donc l'hypothèse du court-circuit est impensable.

J'ai toujours programmé de cette manière (avec une carte externe, depuis presque 5 ans) je n'ai pas le souvenir d'avoir grillé un PIC par électricité statique.
Mais je préfère avoir le programmateur et l'application séparée électriquement pour éviter de réinjecter accidentellement du courant de l'appli vers l'ordinateur.

Merci de vous être penché sur mon pb, même si il n'est pas résolu.

[freepicbasic]

Le plus sûr est que le micro soit alimenté par son environnement (la carte dans lequel il évolue), ainsi le programmateur n'a rien d'autre à alimenter et les niveaux Vpp, clock et data restent corrects.

Désolé de te contre dire, mais si le pic a un MCLR programmable en i/O, et qu'il est en I/O la reprogrammation sera impossible in situe.
Car le MCLR devra-t-être alimenté avant !
2 ièm et dernier rappel, faite en ce que vous en voulez ...

[PA5CAL]

Bonsoir

Désolé de te contre dire, mais si le pic a un MCLR programmable en i/O, et qu'il est en I/O la reprogrammation sera impossible in situe.
Car le MCLR devra-t-être alimenté avant !
2 ièm et dernier rappel, faite en ce que vous en voulez ...

Pas d'accord.

J'ai eu le même problème persistant que Montd'est, avec un PIC 12F675 et un kit K8076 (qui est une véritable bouse, soit dit en passant !). J'avais configuré la broche MCLR en sortie, et mes tentatives pour modifier le programme existant (qui fonctionnait parfaitement) se soldaient systématiquement par un échec.

Mais après une demi-journée d'efforts sur différents logiciels et ordinateurs (Mac et PC), je suis quand même parvenu à effacer mon PIC et à le reprogrammer différemment.

La programmation de la broche MCLR en sortie était probablement à l'origine de mon problème, mais au bout du compte la reprogrammation s'est tout de même avérée possible.

Pour info, c'est le logiciel de programmation fourni avec le kit K8076, exécuté sur un vieux PC sous Windows 2000, qui a finalement eu raison du blocage. J'ai noté qu'à cette occasion, la reprogrammation du PIC s'est avérée beaucoup plus longue que sur mes autres plateformes.

En cherchant une explication à mon problème, j'ai relevé dans les specs de programmation de mon PIC que, comparée à la plupart des autres PICs de la gamme, la procédure de mise sous tension était quelque peu différente (Vpp avant Vdd). J'ai soupçonné cette particularité et la trop grande simplicité du kit K8076 d'en être en partie la cause.

Or, je constate que la procédure de programmation du PIC 16F628 présente la même caractéristique. Il est donc possible que Montd'est soit victime du même problème que moi.


Pour en revenir à ton affirmation, la reprogrammation du PIC doit être possible avec une broche Vpp/MCLR configurée en sortie du fait que Vpp est (ou devrait être) portée à la tension de programmation avant que le PIC soit mis sous tension via Vdd.

[invite03481543]

Désolé de te contre dire, mais si le pic a un MCLR programmable en i/O, et qu'il est en I/O la reprogrammation sera impossible in situe.
Car le MCLR devra-t-être alimenté avant !
2 ièm et dernier rappel, faite en ce que vous en voulez ...

Un PIC version flash est destiné à être reprogrammé in situ par ICSP, la doc indique un bloc sur cette entrée appelé Overvoltage Detection qui donc détecte Vpp et force le mode de programmation avant toutes autres considérations.
Le fait que cette entrée puisse être configurée en entrée par programme est autre chose, ce sera l'usage une fois que le PIC aura été programmé.
D'ailleurs la fonction MCLR est toujours présente même lorsque ce port est en entrée, elle est juste câblée différemment par le PIC et donc inaccessible de l'extérieur.
Sinon ça veut dire qu'avant de reprogrammer ce câblage changerait tout seul?
Pour ma part je ne programme jamais autrement un PIC que sur sa carte et je n'ai jamais rencontré un tel problème en programmation y compris avec un 16F628A.
J'utilise ICD2 et ICD3 uniquement.
Je partage donc l'avis de PA5CAL que le soucis vient du programmateur (ou du PIC peut-être défectueux), mais certainement pas du fait que le port soit déclaré en entrée au lieu de MCLR.

[freepicbasic]

ci joint
extrait de la doc de programmation des pics 16F62x
et photo de la bidouille pour les programmateurs du genre JDM.

Il faudra aussi m'expliquer comment vous mettez le VCC après le VPP "in situe" surtout si le 5V comprend des chimiques de filtrage qui vont retarder la montée d'autant, et cela sans pouvoir spécifier au logiciel de prog combien de temps, il faut attendre avant de mettre sous tension le VCC.

Paramètre que je n'ai vu dans aucun logiciel ...
Et d'autre part , à condition que le hard du programmateur soit équipé d'un VCC que l'on peut commander...
ça fait beaucoup de si ...

[freepicbasic]

Nota Bene:

Cette particularité n'existe pas sur la série PIC16F8x, PIC16F87x qui ont un MCLR dédié.
Et la remarque de Hulk28 est alors justifié !

Mais pas pour les 16F62x et les PIC12F675 qui m'ont fait perdre assez de temps avant de comprendre ça.

Pour la programmation 'in situe" j'utilise aussi des fils blindés si la distance dépasse 5 cm.
Quant à la prise sur la carte elle devra t être le plus près possible du pic.

[PA5CAL]

Il faudra aussi m'expliquer comment vous mettez le VCC après le VPP "in situe" surtout si le 5V comprend des chimiques de filtrage qui vont retarder la montée d'autant, et cela sans pouvoir spécifier au logiciel de prog combien de temps, il faut attendre avant de mettre sous tension le VCC.

Paramètre que je n'ai vu dans aucun logiciel ...
Et d'autre part , à condition que le hard du programmateur soit équipé d'un VCC que l'on peut commander...
ça fait beaucoup de si ...

En ce qui concerne le kit K8076, les tensions Vpp et Vdd sont fournies à la socket du programmateur au travers de connecteurs indépendants. Vdd peut encore être branchée manuellement après que Vpp ai été activée.

Il n'empêche que ce kit est a priori inadapté à ce cas de figure, et il n'arrive à fonctionner sans manipulation que si MCLR n'est pas configuré en sortie. Et c'est le cas de la majorité des programmateurs bon marché que j'ai pu voir, qui ne proposent aucun contrôle de Vdd, ni logiciel ni électrique.


Compte tenu de cette particularité, j'en viens à me demander si des petits malins ne pousseraient pas à la consommation des modèles concernés en proposant sur le net des exemples de programmes où la seule broche configurée en sortie parmi toutes celles disponible est justement MCLR...

[Forhorse]

Avec un pickit on ne se casse pas autant la tête.
C'est pourtant pas faute de répéter sans arrêt que le JDM et ses clones sont des bouses.

[invite03481543]

Oui je suis bien d'accord, c'est comme vouloir souder avec un fer à repasser, autant prendre directement un fer à souder non ?
Il y a des outils dont on ne peut se passer, il y a déjà bien assez de soucis comme ça pour s'en créer d'autres inutilement.

[freepicbasic]

bof.
ça ne résoud pas le problème de l'alime "in situe" pour ce genre de pic.
et si on alimente la carte avec le port USB , espérons de ne jamais faire de fausse manip en faisant sauter le 5V du port...
Perso j'aime mieux cramer une alime daube à 2 balles plutôt que le PC.

Et les logiciels comme IcProg qui programme toute l eeprom même si le prog fait quelques octets ça la e don de m'exaspérer.

Enfin chacun fera à son idée...

[Forhorse]

Une simple diode entre le VDD du pic et le reste du montage suffit à résoudre le problème si vraiment problème il y a (j'ai déjà appliqué cette méthode avec succès)

[dome45]

Bonjour,

Désolé de te contre dire, mais si le pic a un MCLR programmable en i/O, et qu'il est en I/O la reprogrammation sera impossible in situe.
Car le MCLR devra-t-être alimenté avant !

Sur le forum microchip, meme probleme avec un pickit 2 et un 16F88 : Unable to reprogram device
http://support2.microchip.com/KBSear...=SQ6UJ9A003LD0
http://www.microchip.com/forums/tm.a...mpage=1#242122

Soit Quartz et MCLR interne
Soit oscillateur interne et MCLR externe ( Condo +resistance)
A eviter avec JDM ou autre: oscillateur interne et MCLR interne

Extrait:
The other internal MCLR issue. This is actually similar to the internal MCLR pull-up issue. These issues only happen with badly designed programmer (i.e. cheap and nasty ), including Microchip's own ICD2. The reasons are the MCLR and Vcc controls are badly implemented.

Other than not using the internal MCLR and internal oscillator or internal MCLR pull-up in your fuse settings, putting a big delay at the start of your program will also help. Just put the delay right after the .org and it should be fine.

For the chips that had already been programmed, I found that holding MCLR low manually (I used a piece of grounded wire and a 100 ohm resistor in series) and then taking it off right after pressing the program button does wonder. You might have to try this a few time to get the timing right. The idea is to keep the PIC from starting right before the programming sequence activate itself.

Another way is to buy a robust professional programmer, which could be expensive just to salvage a few chips.

@++