Bug.

J'ai un bug =E9tonnant (sic) sur une com o=F9 une carte #1 (toujours la m=EAme) dialogue en RS232 avec une carte #2. En R&D tout est ok mais en prod une des cartes #2 ne recoit pas *une* des trames de la carte #1, alors que tout est ok =E0 100 % pour *toutes* les autres trames.

En remplacant la carte #2 fautive par une autre (avec le m=EAme firmware) le bug disparait.

Juste une premi=E8re piste avec un soupcon sur le chip qui translate le signal logique en signal RS232 : certains ont les capas de leur pompe =E0 diodes (100 nF) trop justes et ne supportent pas les trames trop longues car cela fait baisser la tension RS232 au-dessous du seuil standard en RS232 pour les transitions logiques 0/1.

Au point o=F9 j'en suis de mes investigations je ne sais pas encore si c'est la bonne explication, (d'autres trames passent alors qu'elles sont plus longues) mais ca m'intrigue : est-ce que vous avez d=E9ja eu ce genre de probl=E8me, et si oui, trouv=E9 la raison ?

Reply to
Jean-Christophe
Loading thread data ...

Jean-Christophe a tapoté du bout de ses petites papattes :

Sur un PC ou un truc à toi ?

--
LeLapin
Reply to
LeLapin

On 10 jan, 23:16, LeLapin

Entre deux cartes autonomes. ( d'apr=E8s les mesures faites aujourd'hui le chip 232 n'est pas en cause )

Reply to
Jean-Christophe

Jean-Christophe a tapoté du bout de ses petites papattes :

Je pensais à des conflits d'interruptions.

--
LeLapin
Reply to
LeLapin

On 11 jan, 19:52, LeLapin

| Sur un PC ou un truc =E0 toi ?

| Je pensais =E0 des conflits d'interruptions.

Oui mais non, le firmware de ces cartes est =E9crit par bibi en mode nickel-chrome. ( je sais ce qui tourne sous le coffre )

Cela dit, merci d'essayer :o) Quand on ne sait pas o=F9 chercher toute piste est bonne =E0 =E9tudier. A mon go=FBt c'est justement quand on ne comprend pas du premier coup ce qui d=E9conne, que ca rend la r=E9solution du probl=E8me encore plus int=E9r=E9ssante. (parce-que ca veut dire qu'on VA apprendre quelque chose)

Note que je pourrais m'en foutre, vu que 99,9 % des cartes fonctionnent sans aucun probl=E8me. Ce qui me g=E8ne est que, vu que je n'ai pas encore identifi=E9 la source du probl=E8me, il est tout =E0 fait possible que cela se reproduise : autant ca ne me g=E8ne pas que ca arrive au labo R&D, autant je d=E9teste que ca se produise chez un client. ( je pense que tout le monde comprend ca )

Aujourd'hui j'allais faire des mesures sur le hard de la carte, donc je recompile le firmware en mode debug, et en r=F4dant le long des sources je d=E9couvre un truc un peu limite dans la gestion du watchdog du uP : j'essaie un correctif avec un patch 'fast n' dirty', et voici que la carte fautive fonctionne correctement !

Malgr=E9 ca je suis loin de jeter l'=E9ponge car je ne m'explique toujours pas comment les 99,9 % des autres cartes fonctionnent sans ce patch, avec le firmware d'origine, et sans aucun probl=E8me !

J'en suis =E0 soupconner un bug d=FB =E0 une interaction subtile entre le soft et un composant qui serait =E0 la limite de ses sp=E9cifications ... sympa, non ?

Reply to
Jean-Christophe

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.