Error 17159

[Guest]

J'ignore si tu comprends l'allemand mais il semble que tu ne sois pas le seul qui est ce problème.
Vois sur :
http://www.elektor.de/default.aspx?tabid=29&forumid=23&postid=4044&view=topic

Voici en pièce jointe le résumé de cette longue et fructueuse discussion sur le site allemand. Faute de temps pour le traduire, je le laisse tel quel pour linstant.
Il s'agit d'abord de rassurer ceux qui pensent que leur composant est HS. Ce n'est probablement pas le cas.
En résumé : dès que l'erreur se produit, il faut couper le courant et cesser toute tentative, car il semble que le problème ne fait qu'empirer. Extraire le module et l'enficher sur un morceau de mousse conductrice recouverte d'une feuille d'aluminium pour mettre les broches en court-circuit. Et attendre. Chez les uns quelques minutes ont suffi, chez d'autres il a fallu des jours !

Attention ! Si lors de la nouvelle tentative de programmation les causes de l'erreur n'ont pas été éliminées, le processeur se reverrouillera sans doute aussitôt.
Quelqu'un peut-il se charger de résumer les cinq causes possibles telles qu'elles sont clairement énumérées par Didi Lamken dans son document?

Bonne chance

Denis Meyer
www.elektor.fr'

[ymasquel]

Bonjour Denis et tous les assidus du R8C.
Il y a 6 paragraphes, j'attaque les paragraphes de 1 à 5 (ils sont assez courts).
S'il y a un autre amateur qui veut se charger du § 6.
Je compte avoir terminé pour demain matin.
Amicalement, Yves.

[Guest]

S'il y a un autre amateur qui veut se charger du § 6.

Bravo !
Eh bien pour ne pas être en reste, je viens de traduire le (très intéressant) §6 que voici. A charge pour vous de l'intégrer à votre traduction pour en faire un tout cohérent. Merci d'avance.

.dm

PS: Avis aux amateurs: je viens également de rajouter le programme COMscope.zip sur la page allemande :
http://www.elektor.de/Default.aspx?tabid=115

[r8c13master]

Bonjour à tous,

En fait ce problème est du à ce que je n'hésiterais pas à qualifier de sérieux "bug" de conception du R8C13 ou, plus exactement du mode de placement des données dans le fichier utilisé pour sa programmation.

Sous certaines conditions, dont le texte traduit par Denis Meyer depuis le forum allemand donne un très bon exemple, un "faux" ID code (en fait un ID code non désiré) peut se retrouver programmé dans le circuit.

Il est alors impossible ensuite de re-programmer directement un tel circuit.

Les "explications" founies à ce sujet par Renesas sont plus que fumeuses comme vous pouvez le constater en suivant le lien ci-dessous (en fait il s'agit de la réponse à la question de quelqu'un qui a perdu son ID Code mais cela revient au même dans la situation que nous évoquons ici).

http://eu.renesas.com/fmwk.jsp?cnt=/r8c_102506_en_GL.jsp&fp=/support/faqs/faq_results/Q102501-Q102600&site=

[bernardautran]

Merci,
j'avais l'impression de' passer pour un con, mais je me rends compte qu'il y a un véritable souci.
Comme je parle pas teuton dans le texte, je suis friand de la suite de cette histoire.
J'ai laissé un message en rosbif chez renesas, pour l'instant, no comment.

[ymasquel]

Bonsoir à chacun,
Voici la traduction de la présentation et des paragraphes 1, 2, 3, 4, 5, 7 du document de DIDI LAMKEN. En espérant ne pas avoir commis trop de contresens.
J'ai intégré la traduction de Denis Meyer du paragraphe 6 pour disposer d'un document complet.
Amicalement, Yves.

[Guest]

Merci beaucoup Yves. Je n'ai pas encore vérifié toute votre traduction, mais en passant j'ai vu un petit faux-sens :

Il faut évidemment mettre la feuille de papier alu sur la mousse avant d'y piquer le module. Le but est de court-circuiter ses broches.

Je vérifierai le reste dès que j'aurai un instant.

L'explication de Renesas n'est pas "fumeuse" à vrai dire, elle n'est qu'incomplète. Burkhard Kainka, qui connaît bien le module, m'a confirmé entretemps que le message d'erreur 16194 pouvait avoir des causes très diverses et que jusqu'ici à peu près tous ceux qui avaient eu des ennuis de ce genre s'en sont sortis.
(à suivre)

.dm

[ymasquel]

Bonjour Denis,
OK pour le contresens mais comme la mousse conductrice est "par essence" conductrice j'ai mentalement placé la feuille d'alu par dessus le module pour que toutes les parties métalliques soient équipotentielles avec la mousse. Je pense en particulier au boîtier du quartz. Le coup de la feuille d'alu je l'utilise lorsque je n'ai pas de mousse conductrice sous la main, je remplace par un bloc de polystyrène lui-même emballé dans une feuille d'alu.
Amicalement, Yves.

[Guest]

Yves,
si j'ai relevé ce détail, ce n'était pas pour critiquer, mais parce qu'en lisant in extenso le fil de discussion allemand j'avais été frappé par le fait que certaines mousses s'étaient révélées insuffisamment conductrices pour obtenir rapidement un résultat probant. D'où l'intérêt de la précision au sujet du papier alu ***en plus*** de la mousse.

(à suivre)

.dm

[r8c13master]

L'explication de Renesas n'est pas "fumeuse" à vrai dire, elle n'est qu'incomplète.
.dm

Bonjour,

J'avais voulu rester "gentil" en écrivant "fumeuse". En fait, l'explication de Renesas n'en est pas une car, manifestement, le fabricant est mal à l'aise sur ce problème !

En vingt-cinq ans d'experience sur les microcontrôleurs c'est en effet la première fois que je vois un circuit se protéger quasiment seul et, qui plus est, interdire ensuite son effacement avec les propres outils de son concepteur.

Burkhard Kainka, qui connaît bien le module, m'a confirmé entretemps que le message d'erreur 16194 pouvait avoir des causes très diverses et que jusqu'ici à peu près tous ceux qui avaient eu des ennuis de ce genre s'en sont sortis.
(à suivre)

.dm

C'est tout de même la moindre des choses que l'on puisse souhaiter car, dans le cas contraire, à quoi servirait-il d'avoir un circuit pourvu de mémoire de programme de type EEPROM ?