Problème de plantage PIC18F4523 et carte SD 2Go

[gillou026]

Une Transcend 2GB
-----

[jiherve]

re
bon la DS est assez succincte, on ne peut pas en tirer grand chose.
JR

[gillou026]

Bon après des heures et des heures et encore des heures (+ quelques heures) de recherche, je crois que je viens de mettre le doigt sur le problème !!!

Hier soir je me suis dit : "je vais absolument tout virer de mon programme qui ne concerne pas la SD pour ne m'occuper que d'elle !".

Il restait donc dans le programme que la création d'un fichier texte et écriture dedans !! Et ben ça marchait toujours pas !

Alors comme j'ai pas tout dit, j'explique un peu plus ...

Il y a quelques années j'avais fait une carte (industrielle, trou métal, vernis et tout ...) avec une carte SD, un PIC18F4523 un LCD 2x 20 et 4 boutons pour une appli bien précise. Cette carte marchait bien, pas de soucis.

Récemment j'ai eu besoin de rajouter un module GPS et un buzzer à mon projet. Je me suis servi d'une des anciennes cartes pour développer le soft et ajoutant les composants nécessaires (tout ça soudé en "vrac" au dos de la carte) ... et ça marchait impec !!!!

Une fois le proto au point, j'ai lancé la fabrication industrielle de quelques cartes pour faire des circuits propres. Et c'est là que les problèmes ont commencé à apparaitre de façon aléatoire (sinon c'est pas marrant) !!! Sur les nouvelles cartes toutes neuves, toutes propres : cata !!!!

Aujourd'hui j'ai suivi chaque piste pour voir s'il n'y avait pas une erreur de routage, une mauvaise isolation (bien que mon logiciel de routage me l'interdise), ... j'ai tout repassé, en me disant : "bordel c'est quoi qui est pas pareil entre le proto et les versions finales ???????


Ettttttt ...... j'ai fini par tomber sur un condo de 47 uF que j'ai mit sur les broches d'alim de la SD !!!! En parallèle avec un de 100nF.

En y repensant, je m'étais dit que ça pouvait pas lui faire de mal en cas d'appel de courant, il y aura une petite réserve !!! Condo que je n'avais pas mit sur la 1ère version !!!!

Je l'ai donc viré comme un mal propre !

Et tous les tests que je viens de faire depuis 1h00 sont tous BONSSSSS !!!!!!!!!


Donc c'est pas du tout un problème de soft, que remue dans tous les sens depuis des jours ... mais juste un P..... de condo qui me met le merdier dans mon montage !!!!

Et ben on pourra dire que ça m'aura prit du temps sur ce coup là !!!!

Mais bon, je suis pas du genre à abandonner ... fallait de toutes façons que ça marche !!! Des gens comptent dessus ... et moi aussi.

Vais aller arroser ça moi !!!!!

Merci à ceux qui ont participé à ma galère .....

[paulfjujo]

bonsoir,

je suspecte malgré tout une source d'ennui ici :

char filename[11] = "LO01.TXT"; // Fichiers Log

Mmc_Fat_Set_File_Date(annee + 2000, mois, jour, heure_gps, minutes_gps, 0);
exemple
202206062041 + zero terminateur de string
1234567890123 <---- 13 elements ! si on inclut le 0 terminateur

moi j'aurai mis 13 .. (pas superstitieux pour autant)

char filename[13];

ce genre de probleme peut se manifester ou pas ..
suivant l'endroit ou le debordement peut atterrir ...

[gillou026]

Je pensais avoir trouvé le bug avec ce fameux condensateur, mais ce n'est pas ça !!!!!

J'ai encore passé 8h00 dessus ... et là je pense avoir enfin trouvé !!!

Ce n'est pas un problème de soft mais bel et bien de hard ! Et visiblement c'est mon routage !!!

Sur mon montage il y a 4 boutons poussoirs avec pull up. Sur ma toute première version il y avait un fil qui faisait le tour de tous les boutons et était soudé sur ma carte en guise de masse commune.

Sur ma version actuelle, j'ai voulu mettre 2 trous pour chaque bouton afin de ne plus avoir à installer ce fil qui fait le tour ...

Et du coup il a fallu un bout de piste pour amener la masse du côté droit de la carte à côté de la SD ... et c'est ce bout de piste qui met la bazars !!

Quand j'appuie sur le bouton tout à droite (de façon aléatoire) ça fait planter la SD ! Pourquoi ????? Ma pull up est de 10K, donc un courant tout petit mais qui arriverait à la perturber ??

Si quelqu'un a une explication, je suis preneur.

Là je fais des tests en ayant tiré un fil de mon bouton poussoir et amené sur une autre masse que la SD et pas de beug.

Quelle histoire !!!!

Je vous ai fait un petit dessin pour illustrer la chose. Ca pourra servir à ceux qui veulent se lancer là dedans ...

[gienas]

Bonsoir à tous

... Quand j'appuie sur le bouton tout à droite (de façon aléatoire) ça fait planter la SD ! Pourquoi ????? Ma pull up est de 10K, donc un courant tout petit mais qui arriverait à la perturber ??

Si quelqu'un a une explication, je suis preneur ...

Tu découvres par là la difficulté à être sûr du fonctionnement d’un ensemble, et les ”caprices” de la technique.

Tu ne précises pas à quoi sert le quatrième bouton fautif, ni si c’est lui qui intervenait lors des ”plantages/erreurs” objets du fil présent.

On sait que le routage est très important et les découplages tout aussi importants.

Dans le as présent, on ne sait pas qui reçoit le parasite et où il se développe. Ce peut être dû (consécutif à) une action programmée par le bouton mais aussi par une variation d’intensité dans une partie de la piste de masse.

Il est très important que les références (les masses et leurs pistes) soient les plus larges possibles.

[gillou026]

Tu ne précises pas à quoi sert le quatrième bouton fautif, ni si c’est lui qui intervenait lors des ”plantages/erreurs” objets du fil présent.

On sait que le routage est très important et les découplages tout aussi importants.

Dans le as présent, on ne sait pas qui reçoit le parasite et où il se développe. Ce peut être dû (consécutif à) une action programmée par le bouton mais aussi par une variation d’intensité dans une partie de la piste de masse.

Je pense que c'est la variation d'intensité lorsque l'on relâche le bouton poussoir (de droite). Lorsque l'on appui dessus ça déclenche l'enregistrement de données sur la carte SD. Et c'est quand on relâche que ça plante (mais pas tout le temps) ... et visiblement lorsque l'on relâche pendant l'écriture sur la SD.
Si on relâche après l'écriture ça plante pas.

La piste de cuivre du bouton passe près des signaux de la SD (Di, Do, CLK, CS) et la masse est commune avec celle de la SD. Ça fait même une boucle car la SD a 2 broches pour la masse que j'ai relié.

C'est donc au final un problème simplement de routage et proximité de signaux qui fait que ça plante de façon aléatoire.

Le bouton de droite n'est plus relié à la carte par les 2 bornes que j'avais prévu. Il est relié par 2 fils volants direct sur la pull up d'un côté et sur la masse du uC de l'autre. Et là, aucun soucis !

Jamais un montage aussi simple ne m'aura fait tourner autant en bourrique !!!!

[jiherve]

bonjour
bien sur il y a un antirebonds de course!
JR

[gillou026]

bonjour
bien sur il y a un antirebonds de course!
JR

En fait pas besoin d'anti rebond car quand le programme détecte l'appui sur le bouton ça part dans une procédure qui dure 2 secondes (acquisition des données (1 sec), enregistrement des données et affichage d'un message sur le LCD pour l'utilisateur). Donc il a fini de rebondir bien avant d'être testé à nouveau ... bien avant aussi l'écriture sur la SD.

C'est véritablement quand on le lâche pile au moment de l'enregistrement sur la SD que ça plante ...

[jiherve]

re
donc un antirebonds, bien lire son code!
car ce n'est certainement pas la variation de consommation (sauf pull up de qqs ohms) qui fera la différence.
Le meilleurs antirebond c'est un vote majoritaire sur des échantillons espacés de qqs mS.
Là amha ton code ne se comporte pas comme tu le crois.
JR

[gillou026]

Sur les 3 autres boutons, qui n'ont pas leur piste de cuivre qui passe au milieu des pistes de la SD, il n'y a aucun soucis et pourtant je fais le même test dans une boucle infinie.

Dès que je détecte un 0, je pars dans une procédure qui dure plus de 2 sec. Donc fini les rebonds.

while(1)
{

 if ((bp_valid == 0) && (memo_bp_valid == 0) )
 {
            // procédure qui dure plus de 2 sec ...
 }


 if ((bp_reset == 0) && (memo_bp_reset == 0) )
 {
            // procédure qui dure plus de 2 sec ...
 }

 if ((bp_plus == 0) && (memo_bp_plus == 0) )
 {
            // procédure qui dure plus de 2 sec ...
 }

 if ((bp_moins == 0) && (memo_bp_moins == 0) )
 {
            // procédure qui dure plus de 2 sec ...
 }

 if (bp_valid == 1)
       memo_bp_valid = 0 ;

 if (bp_reset == 1)
       memo_bp_reset = 0 ;

 if (bp_moins == 1)
       memo_bp_moins = 0 ;

 if (bp_plus == 1)
       memo_bp_plus = 0 ;

Et la pull up est de 10 K. Donc le courant est très petit ...

C'est pour ça que je ne comprend pas ce qui fait planter !!! (si je continue à utiliser les 2 bornes prévues pour raccorder mon bouton de droite).

[jiherve]

re
je suis désolé mais au relâchement cela peut réactiver ton enregistrement.
Il faut un antirebonds capable de traiter appuis et relachement , dura lex sed lex!
JR

[gillou026]

Je ne peux plus éditer mon message précédent mais la variable memo_bp xxxxx me sert à mémoriser que j'ai appuyé sur le bouton et ça ne repasse pas dans la procédure tant que j'ai pas relâché.

if ((bp_valid == 0) && (memo_bp_valid == 0) )
{
memo_bp_valid = ;
// procédure qui dure plus de 2 sec ...
}

[gillou026]

re
je suis désolé mais au relâchement cela peut réactiver ton enregistrement.
Il faut un antirebonds capable de traiter appuis et relachement , dura lex sed lex!
JR

Ca plante quand on relâche le BP PENDANT la phase d'écriture sur la SD. Comment ça pourrait réactiver la procédure alors qu'elle n'est pas encore finie ?

Ca ne fonctionne pas en IT mais par scrutation ....

[jiherve]

re
oui mais quand tu relâches rien n’empêche d'y repasser.
un montage hard antirebonds:

GND -- SW-- 10K --VCC
          |--10K--10nf--GND
                | --input

ensuite tu échantillonnes à 1ms et fait un vote majoritaire ou un truc équivalent.
La gestion de la boutonaille se fait par un processus cyclique tournant sur IT.
JR

[gillou026]

Quand je détecte l'appui sur le bouton je pars dans une procédure où je lis des infos de capteurs divers et la progression de l'acquisition enregistrement ... est affichée sur le LCD par des ******.

Il doit y en avoir 6 au total qui montrent les diverses étapes. Tant que l'on a pas eu les 6, on ne revient pas dans la boucle principale et donc on ne lis pas le BP.

Et c'est toujours sur la 3 ème étoile (qui correspond à l'enregistrement sur la SD) que ça plante.

Mais avec le même programme et mon bouton pas branché où il devrait être (et avec la piste coupée entre la pull up et le bouton), ca fonctionne sans problème ...

[jiherve]

re
et ta masse SD est bonne ?
JR

[paulfjujo]

bonjour,

Avant de continuer sur ce bouton ...
voir post#34

char filename[11] = "LO01.TXT"; // Fichiers Log <- ici no problemo

As-tu modifié la taille de la table contenant le nom du fichier
11 c'est top court
minima=12
ex:
SAUVE002.TXT
123456789012
mais prevoir 13 au cas ou on manipule des strings (avec zero terminator)
au lieu de remplir byte par byte

"ça peut tomber en marche" ..ou mettre le boxon dans le programme

c'est du vecu !

[gillou026]

bonjour,

Avant de continuer sur ce bouton ...
voir post#34

char filename[11] = "LO01.TXT"; // Fichiers Log

J'ai mit 14 .... au cas où.

[gillou026]

re
et ta masse SD est bonne ?
JR

Oui la masse est bonne et j'ai fait 6 cartes où j'ai sur toutes le même problème.

Mais en connectant le BP direct sur le uC et donc sans utiliser les pistes prévues sur la carte ça fonctionne sans soucis. J'ai fait 3000 enregistrements cet après midi sans bug.

J'ai coupé la piste du BP au plus près de la pull up.

C'est quand même dingue ce truc !!

A priori j'ai trouvé d'où vient le problème et comment le régler ... mais j'aime bien comprendre les choses quand elles ne marchent pas ... et là, j'avoue je pige pas !!!

[jiherve]

re
vu la proximité de la piste clk et ton retour de BP il doit y avoir un chouette couplage, jette donc un œil à l'oscillo sur le signal d'horloge lorsque ton bouton est appuyé.
JR

[gillou026]

re
vu la proximité de la piste clk et ton retour de BP il doit y avoir un chouette couplage, jette donc un œil à l'oscillo sur le signal d'horloge lorsque ton bouton est appuyé.
JR

C'est effectivement la seule explication plausible que je verrais ...

Il y a pourtant 0.8 mm d'isolation.

Mais peut être le fait que les 2 pistes se suivent // sur 3.2 cm ça fait un couplage entre les 2 ...

Et à y regarder de plus près, les pistes du bouton forment une boucle autour du signal CLK et retour masse de la SD !!!

Donc la variation de courant dans la boucle du bouton perturbe le signal SLK qui se trouve juste à proximité !!!

[jiherve]

Re
je ne crois pas que cela soit la variation de courant stricto sensu mais celle de couplage suivant l’état du bouton, cela doit avachir les fronts et introduire du skew.
JR

[gillou026]

Pourtant c'est quand je relâche le bouton pendant la phase d'enregistrement que ça plante.

Si je lâche avant (pendant la phase d’acquisition des données qui arrivent sur ma carte) ou après que l'enregistrement sur la SD ait eu lieu ça ne plante pas.

C'est ce passage du courant dans le bouton de 5V / 1K = 5mA à 0mA PENDANT l'enregistrement (qui dure une centaine de ms) qui fait péter les plombs à la SD ...

J'avais modifié le programme qui enregistrait toutes les secondes (sans avoir à appuyer sur le bouton VALID) et ça plantait pas. Donc le programme est bon ...
C'est lié à cette disparition du courant !!

[paulfjujo]

Bonjour,

j'ai testé aussi la librarie MikroC SDcard avec 18F26K22 DIP28
package 1366882085_fat32_library_mikro c_pic.mpkg
mais ma SD (scandisk 2GB)
etait sur une board support de carte
des 50K pull up sont sur toutes le pins de la SD card, module contenant un regulateur 3,3V => module alimenté en 5V
carte formatée avec des secteurs de 512 octets

usage d'un buffer RAM de 512 bytes pour la SD
Mon 1er test etait négatif .. blocage apres l'init FAT32
à cause du SPI trop rapide ( pour une SD card type 2!) , diminuer la vitesse max du SPI par 4
// 2 Tests : LNF_TEST + File TEST +->compile OK
// mais bloque sur ligne trop longue sur terminal
// reduction drastique du nombre d'element ecris 1000 -> 20
// rajout d'un CR,LF dans les donnéees ecrites , pour la mise en page sur terminal
/ ===> File TEST + LNF_TEST ... OK
3em Test OK

attention, la lib FAT32 utilise BEAUCOUP de ressources !

_Lib_Mmc.mcl" "
_Lib_FAT32_Driver.mcl" "
_Lib_FAT32_Defs.mcl" "
_Lib_FAT32.mcl"

sur quel pins sont tes BP ?
tu dis utiliser RB0 interrupt ?

PB sur BP l'etat 0 ou 1, ou front qui mets la pagaille..
est-ce que tu peux inverser le sens d'action du bouton en question ?
je n'y crois pas trop, si ça à marché en mode volant sur breadboard...
il peut y avoir un bug soft bien caché..

je n'ai pas ce modele de PIC pour faire des essais.


test avec 18F4525 ici

[gillou026]

sur quel pins sont tes BP ?
tu dis utiliser RB0 interrupt ?

PB sur BP l'etat 0 ou 1, ou front qui mets la pagaille..
est-ce que tu peux inverser le sens d'action du bouton en question ?
je n'y crois pas trop, si ça à marché en mode volant sur breadboard...
il peut y avoir un bug soft bien caché..

Salut

Je crois que tu n'a pas lu les posts d'avant. Ca y est, ça fonctionne. Ce n'était pas du tout un problème de soft mais de routage de la carte.

La piste de cuivre qui conduit le signal du bouton au uC passe tout prêt de la piste du signal CLK de la SD et quand je relâche le BP juste quand le uC écrit sur la SD, c'est là que ça plante.

J'ai tiré 2 fils du bouton direct sur les broches du UC et là ça marche nikel (en n'ayant absolument rien changé au code bien sûr).


Donc juste un problème de routage "trop proche" qui met la pagaille.

[paulfjujo]

OK,
c'est bon à savoir ...

j'avais eu un PB similaire avec une bread board , une sortie PWM et une pin utilisée juste à coté
grosses perturbations avec les 1,8pF existants entre les 2 colonnes de la breadboard !
qui laissait passer les fronts du PWM .

[gillou026]

Oui ça ressemble un peu ...

En tout cas ça m'aura fait passer un temps fou à trouver le problème !!!!