Interface PIC/Carte SD

[scaypapa]

Bonjour,

Je cherche à lire une carte SD depuis un PIC. Je ne comprends pas bien le fonctionnement complet des communications en SPI et je pense que mon problème vient de là (de mon manque de connaissance ).
Au final, mon but est simplement de lire le contenu de la carte et d'ouvrir et lire des fichiers, mais j'ai trouvé un code tout fait permettant déjà de monter la carte, ouvrir un fichier ou le créer s'il n'existe pas et écrire un texte pour vérifier que tout fonctionne correctement. J'avais bon espoir que ça fonctionne tout seul puisque j'utilise un PIC18F46K22 et que le tuto en question utilise un 18F45K22, qui est de la même série.

Je réutilise donc pour l'instant exactement le code téléchargé.

=> Première chose que je ne comprends pas, dans MCC Generated Files/pin_manager.h, SD_CS est configuré sur RC0 alors que la doc indique SS1 sur RA5. J'ai essayé de configurer les 2 pins avec le même résultat, donc je reste pour l'instant sur RC0 comme dans le tuto.

=> Deuxième chose : Vu que rien ne s'écrit sur ma carte, j'ai également modifié le main.c comme ceci :

        UINT bw;
        FRESULT etat;

        SYSTEM_Initialize();

        etat = f_mount(&FatFs, "", 1);
    
	if (etat == FR_OK) {	/* Mount SD */

		if (f_open(&Fil, "test.txt", FA_OPEN_ALWAYS | FA_READ | FA_WRITE) == FR_OK) {	/* Open or create a file */

			if ((Fil.fsize != 0) && (f_lseek(&Fil, Fil.fsize) != FR_OK)) goto endSD;	/* Jump to the end of the file */

			f_write(&Fil, "Hello world! This is text message written to sd card\r\n", 54, &bw);	/* Write data to the file */
           
			endSD: f_close(&Fil);								/* Close the file */
		}
	}

	while (1) {
		// Add your application code
	}

J'ai un breakpoint sur le while pour pouvoir visualiser la valeur de etat en mode Debugger.
Il se trouve que j'ai etat = FR_NOT_READY défini comme "The physical drive cannot work" dans FatFS/ff.h
Je pense donc à une erreur de configuration de ma communication SPI (la carte SD fonctionne très bien en la branchant sur un ordinateur ou sur un système à base de PIC fonctionnel), mais comme je ne comprends pas grand chose de ce qui s'y passe, je viens vous demander si vous pourriez m'aider à initialiser correctement cette communication.

Merci beaucoup à vous.

PS : j'ai réalisé un petit circuit pour le branchement de ma carte SD en suivant les indications du même tuto. Je ne pense pas qu'il y ait de problème à ce niveau, mais par principe, je préfère préciser...
N'ayant pas de résistances de 2,1kΩ et 3,3kΩ, j'ai utilisé 2,7kΩ et 3,9kΩ pour diviser les tensions de sortie du PIC, ce qui d'après mes calculs, avec le PIC alimenté directement par le PicKit3 en 4,5V (d'après MPLabX, mes ports USB ne délivrent pas 5V), je devrais avoir des tensions d'entrées pour la carte SD de (4,5-0,7)*3,9/6,6 = 2,25V > 2,06V comme conseillé dans le tuto. La carte elle-même est alimentée par le 4,5V d'alim passant par un régulateur LDO qui délivre 3,27V à la carte (valeur mesurée).
-----

[satinas]

Salut, il faut brancher SDO pic sur DI sdcard, et SDI pic sur DO sdcard, c'est bien le cas ?
La broche SS est associée au port SPI, mais on peut aussi la dissocier, et piloter le chip select de la sdcard en mode i/o, par exemple sur C0.

[scaypapa]

Déjà merci pour ta réponse. Elle est belle comme erreur !
Heureusement, pas besoin de refaire mon circuit de branchement du support de carte SD, ces connexions sont correctes. Il suffit de brancher RC4 (SDI1 du PIC) sur ma broche notée SDO sur mon circuit et RC5 sur ma broche notée SDI.

... Mais ça ne fonctionne toujours pas Toujours ce etat = FR_NOT READY.
Donc ça ne devait pas être la seule erreur...

[satinas]

Tu peux regarder les signaux qui sortent du port spi, et suivre au debugger l'initialisation de la carte.
Le port spi est d'abord configuré en basse vitesse, puis on réveille la carte par une série de pulses clk avec cs high, ensuite on envoie les commandes read/write propres à la sdcard avec cs low.

[A voir en vidéo sur Futura]

[scaypapa]

Pas facile ces histoires. Du coup, je me retrouve dans les tréfonds du code que j'ai téléchargé et j'ai es doutes sur le fait que le souci vienne de mon code téléchargé. A mon avis, ça vient plutôt de ma configuration ou de mes branchement

Donc j'ai essayé de suivre ce qui se passe sur le PORTC qui contiens les 4 pins des communications SPI.
C'est apparemment dans cette fonction que ça se passe (diskio.c).

/*-----------------------------------------------------------------------*/
/* Initialize Disk Drive                                                 */
/*-----------------------------------------------------------------------*/

DSTATUS disk_initialize (
	BYTE pdrv		/* Physical drive nmuber (0) */
)
{
	BYTE n, cmd, ty, ocr[4];
	UINT tmr;


	if (pdrv) return STA_NOINIT;		/* Supports only single drive */

	if (Stat & STA_NODISK) return Stat;	/* No card in the socket */

	sd_init();
	for (n = 10; n; n--) sd_rx();	/* 80 dummy clocks */

	ty = 0;
	if (send_cmd(CMD0, 0) == 1) {			/* Enter Idle state */
		
        /* CHEZ MOI, ça ne va pas plus loin : le send_cmd échoue... */

	}
	CardType = ty;
	deselect();

	if (ty) {			/* Initialization succeded */
		Stat &= ~STA_NOINIT;		/* Clear STA_NOINIT */
		sd_open();
	}

	return Stat;
}

Les "80 dummy clock" semblent bien être envoyés, on a CS à 1 et SCK passe de 0 à 1 un grand nombre de fois.
Il cherche ensuite à envoyer la commande CMD0 (Idle State). Cette même fonction semble tenter d'envoyer une commande CMD55 définie comme "APP_CMD" ? Je ne cherche pas trop à comprendre, ce doit être les différentes étapes pour parler à la carte.
Encore une fois, CS est mis à 1 et des cycles d'horloge sont envoyés.
Puis enfin, CS est mis à Low et il renvoie des cycles d'horloge. Puis il fait wait_ready(), chose que la carte ne sera jamais (ready)...

// Je ne mets que les petits bouts de code où ça coince :
// Voici ce qu'il fait pendant le wait_ready()

uint8_t SPI1_Exchange8bit(uint8_t data) {
	// Clear the Write Collision flag, to allow writing
	SSP1CON1bits.WCOL = 0;

	SSP1BUF = data;

	while (SSP1STATbits.BF == SPI_RX_IN_PROGRESS) {
	}

	return (SSP1BUF);
}

/*-----------------------------------------------------------------------*/
/* Wait for card ready                                                   */
/*-----------------------------------------------------------------------*/

static
BYTE wait_ready (void)	/* 1:Ready, 0:Timeout */
{
	UINT tmr;


	for (tmr = 5000; tmr; tmr--) {	/* Wait for ready in timeout of 500ms */
		if (SPI1_Exchange8bit(0xFF) == 0xFF) break;
		__delay_us(100);
	}

	return tmr ? 1 : 0;
}

// Et voici la fonction qui appelle wait_ready()
BYTE select (void)	/* 1:Successful, 0:Timeout */
{
	SD_CS_SetLow();	/* Set CS# low */
	SPI1_Exchange8bit(0xFF);	/* Dummy clock (force DO enabled) */
	if (wait_ready()) return 1;	/* Wait for card ready */

	deselect();
	return 0;	/* Timeout */
}

Je surveillais donc SSP1BUF et SSP1STATbits.BF
SSP1BUF est bien à 0xFF, et quand BufferFull passe à 1, SSP1BUF passe à 0x00.
Ceci systématiquement. Du coup, au bout de 5000 tentatives, la fonction select() retourne 0 et le montage de la carte s'arrête avec l'erreur FR_NOT_READY.
Je voit bien également pendant ce temps, mon CS à 0 et mon SCK passer de 0 à 1 (mais rien d'autre).

Je ne sais pas si je suis clair. En tout cas, ça ne l'est pas vraiment pour moi...

[scaypapa]

PS : à aucun moment, je n'ai vu mes RC4 et RC5 passer à 1... (respectivement SDI et SDO sur le PIC et donc respectivement reliés à DO en direct et DI par pont diviseur sur la carte SD)…

[terriblement]

Salut,

A quel endroit tu initialises les ports comme entrée et sortie ?

[scaypapa]

Bonjour.

Le code complet que j'ai téléchargé semble avoir été créé avec l'aide de MicrochipCodeConfigurator. Je n'aime pas trop son travail parce qu'il écrit tout, même pour les ports inutilisés et les fonctions qui ne servent pas, ce qui n'aide pas toujours à la clarté.
Mais dans l'ensemble, il n'y a pas de raisons qu'il ait écrit de bêtises, d'autant que j'utilise la même série de µC que dans le tuto.
Donc MCC crée un fichier MCC Generated Files/mcc.c qui appelle PIN_MANAGER_Initialize() dans le fichier MCC Genereated Files/pin_manager.c et qui contient entre autres :

	LATC = 0x01;
	TRISC = 0xD6;   //0b11010110
	ANSELC = 0xC4;    //0b11000100

J'ai pu trouver ici, en fin de document, chapitre 3.17 "Card Reset State" sur la manière d'initialiser la carte :

Send at least 74 clock pulses to the card with CS and DataOut lines set to logic "1"

Qu'entendent-ils par "DataOut" ? Le DO de la SD ou le SDO du PIC ?
Parce qu'en mode Debug, je n'ai vu que CS passer à 1 pendant qu'il envoie des cycles d'horloge.

Autre question (qui en découle) pour voir si j'ai bien compris : en théorie, mes 3 pins CS, SDO et SCK du PIC sont en sortie (Tris = 0), SDI est en entrée (Tris = 1) et leur Tris n'a aucune raison d'être modifié en cours de route (ce qui voudrait dire que leur DataOut est bien le SDO du PIC) ?

[satinas]

SCK passe de 0 à 1 un grand nombre de fois.

à aucun moment, je n'ai vu mes RC4 et RC5 passer à 1

étrange comme comportement, tu confirmes ?
fais des essais sans la sdcard

[scaypapa]

Re.

J'ai essayé de mettre des LEDs sur mes sorties (CS, SCK et SDO) pour mieux visualiser.
Je confirme qu'en pas à pas, seules CS et SCK agissent apparemment.
Aussi, je ne vois nulle part dans le code quand l'oscillateur est passé à moins de 400kHz (obligatoire normalement pour l'initialisation de la carte).
Encore une fois, je serais bien surpris que le problème soit dans le code puisqu'il semble fonctionner pour les autres.
J'ai essayé de modifier la fonction disk_initialize() en ajoutant au début OSCCON = 0x12; (250kHz) et à la fin de remettre OSCCON = 0x72; (16MHz, sa valeur d'origine). Mais du coup, comme il y a un __delay_us(100); dans la fonction wait_ready(), le délai devient interminable... Il faudrait modifier également la constante _XTAL_FREQ, mais ça ne me parait pas possible...

Et encore une fois, je ne pense pas que le souci vienne du code, mais plutôt de moi... Encore faut-il la trouver !

[satinas]

OSCCON à 0x72 donne Fosc = 16MHz
SPI1CON1 à 0x22 donne bien 16M/64 = 250kHz

Pas sur qu'une led puisse afficher les données fugitives sur SDO/SDI

[scaypapa]

étrange comme comportement, tu confirmes ?
fais des essais sans la sdcard

Bien vu Satinas !
Je n'avais pas vu ton message, j'ai donc effacé mes essais de modification de l'oscillateur et retiré mon lecteur de carte.
Sitôt qu'il est débranché, ma LED SDO s'allume !
Je ne vois pas où est le souci mais il doit venir de mon circuit avec le support SD (la LED s'éteint quand je branche le lecteur, même s'il n'y a pas de carte à l'intérieur).
J'ai cherché une éventuelle continuité entre GND et SDO mais il donne 6,55kΩ, qui correspond bien à mes 2,7kΩ + 3,9kΩ du pont diviseur.
Même test entre chaque pin allant au Pic. J'ai donc toujours 6,55kΩ entre une pin sortante du pic et GND et 6,55x2 = 13kΩ entre deux pins sortantes du Pic...

Le circuit utilisé est celui de mon premier message en inversant SDI et SDO (la carte n'a pas été modifiée, c'est au niveau des branchements entre la carte et le Pic que j'ai inversé ces 2 branchements...
JE CRAQUE !!!

[scaypapa]

OSCCON à 0x72 donne Fosc = 16MHz
SPI1CON1 à 0x22 donne bien 16M/64 = 250kHz

Pas sur qu'une led puisse afficher les données fugitives sur SDO/SDI

D'accord merci
Je me sers surtout des Leds en mode pas à pas, c'est juste plus lisible que le suivi du PORTC dans MPLabX sous forme binaire...
Evidemment, si je n'ai pas de point d'arrêt dans le code, je ne vois rien s'allumer !

[scaypapa]

Je ne vois qu'une chose qui pourrait poser problème : sur mon lecteur SD (version inversée), j'ai les pins 8 et 9 ainsi que CardDetect et WriteProtect que je n'utilise pas. Je les ai laissées en l'air. Peut être qu'il faudrait que je leur mette un pull-up vers Vdd? Ou un pull-down ? A toutes ou seulement à CD et WP ? Je ne sais pas trop...

[satinas]

Je croyais que tu avais fini le diagnostic. Si tu enlèves la sdcard et que le port spi ne marche toujours pas, c'est que ton interface a un problème. Elle ne sert qu'à raccorder le pic aux pins de la sdcard, et l'abaisseur de tension à résistances ne pose pas de problème. A moins que les leds ne mettent à genou les sorties du pic, peu probable aussi.

Donne-nous ton schéma actuel

[scaypapa]

Voici mon shéma actuel :


J'ai tripoté mon support de carte sous tous ses angles pour essayer de trouver un éventuel faux-contact ou une erreur de branchement.
Pour vérifier que mon SDO est toujours inactivé si je branche le support au pic sans carte SD à l'intérieur, voilà qu'il s'est mis à fonctionner à tous les coups !
Je mets une carte SD, la retire et la mets dans l'ordi : Le Pic m'a écrit un fichier TEST.TXT avec la bonne phrase à l'intérieur !!!

Je ne comprends pas du tout. Je dois forcément avoir un faux contact quelque part ou quelque chose du genre...
En tout cas la panne est presque identifier et (temporairement au moins, jusqu'à la prochaine panne) réparée

Si vous avez l'impression que quelque chose pose problème dans mon PCB, n'hésitez pas à me le dire...
EDIT : oops, j'ai copié une notation 100nF par erreur avant de faire ma copie d'écran...

[satinas]

PIC alimenté directement par le PicKit3 en 4,5V

J'avais loupé ça ! Un pickit ça sert à programmer, c'est pas une alimentation, une sd pompe
D'autre part, en alimentant ton pic en 3,3V, plus besoin d'adapter les niveaux.

[scaypapa]

Ah d'accord.
Je découvre un peu e j'ai vu cette option dans la config du PicKit3 : "Power Target Circuit from PicKit3" et un choix de la tension à appliquer à 0,125V près.
Il se trouve que mes ports USB ne veulent pas délivrer plus de 4,5V voire 4,625 quand ils sont en forme. Mais j'avoue que je n'ai aucune idée des limites de cette méthode.
Je n'ai jusque là jamais eu de problème comme ceci, et d'ailleurs, ça s'est mis à fonctionner en l'état.
Mais je peux aussi brancher une pile 9V pour l'alim sur ma carte de programmation, je ferai plutôt comme ça alors pour la suite des évènements

Merci.

[satinas]

Note: The PICkit 3 In-Circuit Debugger/Programmer is powered through its USB
connection. The target board is powered from its own supply. Alternatively,
the PICkit 3 can power it only if the target consumes less than 30 mA.

Tu n'as pas eu de problème car tu étais chanceux, jusqu'à aujourd'hui.
Rien que la sdcard, c'est 80mA en écriture.
Il y a des modules USB MB102 chinois pour breadboard qui sortent du 5V et du 3,3v.
Tu le branches sur une alim USB ou sur ton PC si tu veux le griller ...

[satinas]

oops, module à brancher sur une alim 7V à 12V
en fait, moi je la branche en USB avec une rallonge pour avoir du 3,3V, mais c'est pas recommandé, car il y a un risque pour le régulateur 5V

[scaypapa]

Note: The PICkit 3 In-Circuit Debugger/Programmer is powered through its USB
connection. The target board is powered from its own supply. Alternatively,
the PICkit 3 can power it only if the target consumes less than 30 mA.

C'est exactement ce que je viens de lire.

Tu n'as pas eu de problème car tu étais chanceux, jusqu'à aujourd'hui.
Rien que la sdcard, c'est 80mA en écriture.

Quand je dis que je débute
Pour le moment je n'ai pas eu de problème, car je n'ai fait que faire clignoter des LEDs et voir si j'arrivais à gérer des boutons poussoirs.
Et comme je suis très très fainéant, je n'ai encore jamais dû alimenter plus de 2 LEDs en même temps (moins y'a de fils, moins y'a de risque de panne !).

En tout cas, c'est clair que 30mA, c'est vite atteint et que c'en est fini pour moi de cette méthode d'auto-alim.
Sur la petite carte que je me suis fabriquée, il y a un connecteur pour une pile 9V suivie d'un 7805. Donc, désormais, j'utiliserai cette voie pour l'alim.
C'est juste un peu "relou" parce qu'une pile 9V, ça prend de la place par rapport au reste, ça fait un gros bloc au milieu du bouzin...

Par contre ça, j'ai pas compris :

Il y a des modules USB MB102 chinois pour breadboard qui sortent du 5V et du 3,3v.
Tu le branches sur une alim USB ou sur ton PC si tu veux le griller ...

[satinas]

Cherche MB102 sur ebay, et il faut un bloc d'alim 9V avec sortie jack pour l'alimenter.

[scaypapa]

D'accord. Merci beaucoup pour toutes tes réponses.

... mais j'ai un ultime question : ma pile 9V a rendu l'âme (elle ne délivre plus que 5V, donc en passant par le régulateur 7805, je n'ai plus du tout 5V en entrée du PIC).
J'ai voulu réessayer l'auto alimentation par le PicKit "pour voir". Il se trouve que je consomme BEAUCOUP plus de 30mA puisque maintenant que ma carte a bien voulu s'initialiser, j'ouvre un fichier que je lis caractère par caractère via l'appui sur un BP et j'affiche l'octet lu sur... 8 leds !
Je pensais tout simplement que MPLab allaiut m'envoyer chier disant qu'il n'y a pas assez de puissance. Et non. Tout fonctionne parfaitement !

Sais-tu ce que je risque à faire ça (en attendant d'avoir une alim plus adaptée) ? Je risque de griller le Pic ? Ou le PicKit lui-même ?
Ou je risque juste d'avoir un circuit d'essai qui fonctionne mal ?

[satinas]

Ah quoi bon se poser toutes ces questions, le pickit supporte mais dedans il y a des composants qui doivent souffrir, c'est dommage. Il me semblait qu'il envoyait des messages s'il était trop sollicité. Change la pile ou trouve du 5V quelque part.
J'espère que tu as au moins un multimètre pour mesurer la consommation, sinon là aussi va falloir investir

[scaypapa]

Désolé d'y revenir, mais je ne comprends vraiment pas.
J'avance bien pour tout ce qui est de la suite (ouverture, lecture de fichiers etc) mais je reste toujours bloqué sur ces histoires d'alim.

Quand je branche mon circuit alimenté en direct par le PicKit en 4,5V, bizarrement, tout fonctionne très bien. La tension (mesurée) à la carte SD est de 3,3V.
Mais j'entends très bien ce que tu me dis et je ne veux pas continuer mes essais comme ceci, trop risqué.

J'ai donc récupéré un chargeur de PC portable qui dispose d'une sortie USB 5V. J'ai donc coupé un fil USB pour y mettre un connecteur et brancher ma platine à partir de là.
J'ai contrôlé au multimètre, j'ai bien 4,98V, donc en alim du Pic et en alim de mon support SD.
Sauf qu'alors, mon régulateur 3,3V qui alimente à la carte SD sort entre 3,6 et 3,9V !
La carte refuse de s'initialiser correctement et le code semble bloquer à ce moment là :

	ty = 0;
	if (send_cmd(CMD0, 0) == 1) {			/* Enter Idle state */
		if (send_cmd(CMD8, 0x1AA) == 1) {	/* SDv2? */
			for (n = 0; n < 4; n++) ocr[n] = sd_rx();	/* Get trailing return value of R7 resp */
			if (ocr[2] == 0x01 && ocr[3] == 0xAA) {		/* The card can work at vdd range of 2.7-3.6V */

Moi, il semble sortir ocr[2] == 0x01 && ocr[3] == 0xFF

Idem quand j'alimente avec une pile 9V qui passe par un régulateur 7805 pour alimenter le Pic : j'ai l'impression que ça bug à cause d'un problème de tension d'alim de la carte.
Je ne comprends vraiment pas, sur le Datasheet de mon régulateur 3,3V, ils semblent dire que je peux alimenter entre 4,6 (3,3+Vdropout) et 15V et que j'aurais une tension de sortie comprise entre 3,2 et 3,4V.
Ou je n'ai pas compris, ou il y a une merde dans mon support de carte.

J'aimerai bien régler ce problème parce que mon but final sera d'alimenter le merdier par une batterie qui sera plutôt en 18 à 24V. Donc il faut que je puisse abaisser mes niveaux à 5 et 3,3V correctement quelque soit la charge.

[satinas]

Ton régulateur lowdrop 3,3V alimenté en 5V doit sortir 3,3V
Là on parle d'un problème électronique, je préfère que d'autres interviennent.
Pour cela fournit un schéma complet de ce que tu as fait. J'ai bien dit un schéma, pas une implantation.

[scaypapa]

D'accord, donc j'ai refait un shéma de mon interface complète, comportant ma platine pour le Pic et celle pour la carte SD
Quand je branche une pile 9V sur son connecteur dédié ou une alim externe en 5V sur le connecteur du haut, j'ai 3,6 à 3,9V en sortie du LDO.
Si j'alimente directement par le PicKit3 (qui ne veut pas délivrer plus de 4,5V), j'ai bien mes 3,3V en sortie de LDO

Je ne peux pas tout à fait confirmer la tension en sortie de LDO quand j'alimente avec une pile 9V puisque la pile 9V est celle... de mon multimètre
Mais en tout cas le programme bloque au même endroit avec les mêmes valeurs ocr = {0x00, 0x00, 0x01, 0xFF}

[satinas]

N'oublie pas de décocher l'option power target sur le PicKit3, fais aussi un essai en mode release Pickit3 non branché, c'est peut être lui qui pollue Vdd.

[scaypapa]

N'oublie pas de décocher l'option power target sur le PicKit3

Oui évidemment

fais aussi un essai en mode release Pickit3 non branché, c'est peut être lui qui pollue Vdd.

J'ai essayé de programmer le Pic, de débrancher le PicKit et de brancher ma pile 9V : même résultat, j'ai un clignotement de ma LED rouge indiquant une erreur au montage de la carte.
Si je débranche ma pile et branche à nouveau le PicKit, le circuit redémarre tout seul et initialise correctement la carte (clignotement de ma LED verte)

[satinas]

Le câblage du Pickit3 n'apparaît pas sur le schéma.
La question qui se pose est peut-on brancher du 5V derrière un régulateur 5V ?
Il ne faut pas brancher la carte SD si tu ne mesures pas 3,3V en sortie du second régulateur.