pic SPI et mémoire MMC
Répondre à la discussion
Page 1 sur 2 1 DernièreDernière
Affichage des résultats 1 à 30 sur 48

pic SPI et mémoire MMC



  1. #1
    inviteef26fb36

    pic SPI et mémoire MMC


    ------

    Bonjour à tous
    Je suis débutant et j'ai besoin de votre aide pour repondre à mes questions.
    Je dois écrire le programme de mon Pic18f252 lui permettant de stocker des données dans une mémoire MMC. J'ai donc cablé ma MMC en mode SPI avec le Pic.
    J'ai effectué des recherches concernant les sources permettant cette communication notament sur ( http://www.microchipc.com/sourcecode/#mmc )mais je n'y comprend pas grand chose, de plus il est en code CCS alors que je travail sous MPLAB.
    Tout d'abord, dans le programme, il faut initialiser la MMC par:
    * !Cs à l'état haut
    * 80 coups d'horloge
    * !Cs à l'état bas
    * envoie de la commande CMD0 qui permet le reset de la carte
    * attent que la MMC reponde avec 01h
    * si 01h alors on envoie la commande CMD1
    * puis on attend qu'elle reponde 0h00
    Si c'est bien le cas alors la carte est initialisée.
    Ainsi on a:

    ****************************** *******************

    OUTPUT_HIGH(PIN_C2); // set SS = 1 (off)
    for(i=0;i<10;i++) // initialise the MMC card into SPI mode by sending clks on
    {
    SPI_WRITE(0xFF);
    }

    OUTPUT_LOW(PIN_C2); // set SS = 0 (on) tells card to go to spi mode when it receives reset
    SPI_WRITE(0x40); // send reset command
    SPI_WRITE(0x00); // all the arguments are 0x00 for the reset command
    SPI_WRITE(0x00);
    SPI_WRITE(0x00);
    SPI_WRITE(0x00);
    SPI_WRITE(0x95); // precalculated checksum as we are still in MMC mode
    puts("Sent go to SPI\n\r");

    if(mmc_response(0x01)==1)
    return 1; // if = 1 then there was a timeout waiting for 0x01 from the mmc

    puts("Got response from MMC\n\r");
    i = 0;
    while((i < 255) && (mmc_response(0x00)==1)) // must keep sending command if response
    {
    SPI_WRITE(0x41); // send mmc command one to bring out of idle state
    SPI_WRITE(0x00); // all the arguments are 0x00 for command one
    SPI_WRITE(0x00);
    SPI_WRITE(0x00);
    SPI_WRITE(0x00);
    SPI_WRITE(0xFF); // checksum is no longer required but we always send 0xFF
    i++;
    }
    if(i >= 254)
    return 1; // if >= 254 then there was a timeout waiting for 0x00 from the mmc

    ************************** MMC get response ****************************** ********/

    /**** Repeatedly reads the MMC until we get the response we want or timeout ****/
    int mmc_response(unsigned char response)
    {

    unsigned long count = 0xFFFF; // 16bit repeat, it may be possible to shrink this to 8 bit but there is not much point

    while(SPI_READ(0xFF) != response && --count > 0);
    if(count==0)
    return 1; // loop was exited due to timeout
    else return 0; // loop was exited before timeout
    }



    Voila donc sous Mplab, j'ai remplacé la commande SPI_WRITE() par WriteSPI(). Par contre je ne sais pas comment remplacer la commande SPI_READ pour Mplab puisqu'on ne peut pas faire passer d'argument sous celui-ci.
    Je voudrais savoir la signification des arguments passer sous ses fonctions.

    merci d'avance pour vos réponses

    -----

  2. #2
    marmotte

    Re : pic SPI et mémoire MMC

    Le fait que tu codes sous MPLAB, CCS, C18 ou n'importe quel autre compilateur de fait pas changer le langage, le langage C c'est du C point, peut importe le compilateur, ou la cible !

    Ensuite lorsqu tu utilises les fonctions SPI_WRITE et READ, tu les as recuperer dans une bibliotheques j'imagine (un fichier .h), dans ce cas il doit y avoir une explication, meme succinte, sur le fonctionnement des fonctions/arguments de cette bibliotheque.

    A+

  3. #3
    inviteef26fb36

    Re : pic SPI et mémoire MMC

    Ok merci
    Je pense que j'y suis allé un peu vite concernant cette mémoire MMC.
    Je nen sais même pas comment elle est organisée en interne? Lorsque je lis certaines doc on parle de "sector"?.

  4. #4
    asmodyne

    Re : pic SPI et mémoire MMC

    Je répond un peu tard à ce post, mais quand bien même.


    Tout d'abord, je réfute d'un bloc l'assertion de "marmotte"... Le fait de changer de compilateur C, pour ce qui est des microcontrolleurs PIC, modifie ENORMEMENT
    le comportement du programme. Pour obtenir les mêmes résultats que le compilateur "x" avec un compilateur "y", les options à passer en ligne de commande (quand elle sont disponibles) ne sont pas évidentes aux débutants.

    Deuxièmement, en ce qui concerne les cartes MMC ou SD accédées par l'interface SPI des PIC, sachez que:

    A moins d'utiliser un µC de type P18 ou supérieur, le seul formatage décent reste la FAT16. Si vous cherchez à développer une application embarquant une MMC/SD que vous prévoyez de retirer régulièrement pour la modifier via un PC, le choix de ce type de partitionnement reste le meilleur (à moins d'ajouter de l'eeprom flash à votre circuit, ce qui non seulement augmente son coût mais également nuit au performances générale de votre projet). Je pourrais développer à ce sujet sur plusieur milliers de lignes....bref.

    En ce qui concerne les méthode ReadSpi, SpiRead ou autre, gardez à l'esprit qu'elle ne font qu'administrer les fonctionnalité "Hardware" de votre µC.
    Les résultats d'une lecture d'octet via le périphérique hardware d'un PIC16, par exemple, seront TOUJOURS disponible dans le registre SSPBUFF.

    Cependant, ne confondez le SPI, qui est une interface physique, et la couche procotole requise par les cartes MMC. Une lecture SPI via la méthode Spi_Read() ne fait que récuperer un octet sur le bus SPI. Une lecture sur MMC, quand à elle, consiste à envoyer un paquet de commande (6 octets) à la carte, qui contient le code de l'instruction de lecture (0x51), les 32 bits de l'addresse DU BLOCK MEMOIRE à lire, puis un octet de vérification (code de redondance cyclique). ENSUITE, la carte répond en renvoyant LE BLOC de données...
    Si vous utilisez la FAT16, la plus petite taille de bloc admise est 512 octets : d'où le choix d'un µC généreur en RAM, tel que le P18F2525 (3Ko).

    Enfin, si l'approche d'une lecture par bloc vous semble rhédibitoire, sachez qu'il est possible, lors de l'initialisation d'une MMC, de spécifier la taille des blocs transférés. J'ai travaillé avec 64octets par blocs sur un P16F886... C'est gérable, mais la pile des appels en prend un coup, et il faut être assez sage lors de la programmation afin d'éviter un stupide débordement de pile.

  5. A voir en vidéo sur Futura
  6. #5
    microtoad

    Re : pic SPI et mémoire MMC

    Bonjour,


    j'aurais quelques questions à ce sujet :

    Si vous utilisez la FAT16, la plus petite taille de bloc admise est 512 octets : d'où le choix d'un µC généreur en RAM, tel que le P18F2525 (3Ko).
    Est ce qu'on peut utiliser un pic 16F628 ou un pic 18F2550 pour pouvoir l'interfacer avec la sdcard ??

    Est ce que l'on est vraiment obligé d'utiliser le format de fichier FAT16 pour écrire dans la sdcard? ne peut t'on pas y écrire à la facon d'une mémoire eeprom par exemple??

  7. #6
    asmodyne

    Re : pic SPI et mémoire MMC

    Désolé pour cette réponse tardive.
    Je suppose qu'en parlant de 18f2550 ou 4550, vous faite référence à des pic disposant d'un périphérique USB, et fonctionnant exclusivement sous 5V.
    Eh bien oui, vous pouvez les interfacer avec une carte SD.
    Je vous conseille de lire l'Application Note #1003 de microchip à ce sujet : créer un dispositif de stockage de masse usb. Il se base sur les 18f2550/4550. Les fichiers sdcard.h et sdcard.c comportent deux routines, ReadSector et WriteSector, qui vous permettent de lire des blocs mémoires depuis la SD/MMC. Les fichier msd.c et msd.h, quant à eux, exposent comment le PIC, se comportant en controlleur USB de disque plug&play, accède à la carte SD en utilisant ces routines.
    Le plus petit bloc lisible est de 64 octets... Juste le double d'un échange en salve d'une bête eeprom flash 24C16...pour la même finalité. Par contre, si vous utiliser la carte mémoire à ces fins, elle ne sera certainement plus lisible sur un PC : si vous écrasez les deux copies du MBR de la carte SD, elle sera définivement condannée à rester une "eeprom" informatable... à mois de réecrire les deux MBR telles qu'elle étaient à l'origine, depuis le PIC de votre prototype.

    Notez bien : plus de MBR, plus de formatage , même "bas niveau"... la MBR contient les informations de structure de la carte (taille, nombre de secteur, etc) essentielles au programmes de formatage (c'est assez logique qu'il ne puisse plus opérer si elle manquent).
    Dernière modification par asmodyne ; 11/01/2008 à 01h23.

  8. #7
    asmodyne

    Re : pic SPI et mémoire MMC

    J'oubliais, cependant, que le CSD de la carte, ou, plus vulgairement, son registre, en mémoire morte (car la carte elle-même dispose de son propre controlleur) peut être lu par la plupart des nouveau lecteurs bon marché, et des systèmes d'exploitation comme Vista peuvent ainsi restaurer le MBR (je n'ai pas testé cela sous XP).

  9. #8
    RISC

    Re : pic SPI et mémoire MMC

    Citation Envoyé par marmotte Voir le message
    Le fait que tu codes sous MPLAB, CCS, C18 ou n'importe quel autre compilateur de fait pas changer le langage, le langage C c'est du C point, peut importe le compilateur, ou la cible !
    Attention....

    Le compilateur de CCS n'est pas compatible ANCI C !
    Tout programme écrit pour ce compilateur demande donc des modifications substantielles...


    Il vaut mieux de mon point de vue démarrer avec un logiciel pour carte SD fait pour le C18. Il en existe sur internet comme ici :
    http://www.digitalspirit.org/blog/in...-avec-un-pic18

    a+

  10. #9
    marmotte

    Re : pic SPI et mémoire MMC

    Citation Envoyé par asmodyne Voir le message

    Notez bien : plus de MBR, plus de formatage , même "bas niveau"... la MBR contient les informations de structure de la carte (taille, nombre de secteur, etc) essentielles au programmes de formatage (c'est assez logique qu'il ne puisse plus opérer si elle manquent).
    C'est faux !!!!

    Une carte mémoire SD peut etre formatée, même si absolument TOUS LES OCTETS y compris ceux du MBR ont été effacés.

    Pour info le MBR contient, sur une carte SD/MMC UNIQUEMENT les informations relatives aux partitions de la carte. Il adresse en réalité au maximum 4 partitions, chacune des 4 entrées de ce secteur MBR (Master Boot Record) est composée de la maniere suivante (16 octets):

    (les offsets suivants sont en octet parmi les 16 d'une entrée MBR)

    Offset 0: (taille = 1 octet) Etat de la partition (active = 0x80 / inactive = 0x00)
    Offset 1: (taille = 1 octet) Debut de la partition HEAD (inutile sur une carte flash, pas de découpage des zones de données comme sur un disque dur)
    Offset 2: (taille = 2 octets) Début de partition CYLINDER/SECTOR (idem inutile)
    Offset 4: (taille = 1 octet) Type de la partition (Unknown, FAT12, FAT16 inferieur a 32Mb, Extended DOS, FAT16 sup a 32Mb ou FAT32)
    Offset 5: (taille = 1 octet) Fin de partition HEAD (inutile)
    Offset 6: (taille = 2 octets) Fin de partition CYLINDER/SECOTR (inutile)
    Offset 8: (taille = 4 octets) Nombre de secteur entre MBR et partition correspondante (= offset de la partition sur le volume ==> ceci peut etre programmé au moment du formatage)
    Offset 12: (taille = 4 octets) Nombre de secteurs de la partition ( ==> programmé au moment du formatage de la carte, selon la taille de la partition désirée)


    Comme on peut le voir, dans le tableau précédent, strictement rien n'empêche de formater une carte dont le MBR a été effacé ou remplacé puisque les 2 seuls champs qui nous interressent sont aux offsets 8 et 12, et ces derniers seront renseignés au moment du formatage de la carte. Les autres champs ne sont pas utilisés sur ce genre de volume, y compris le champs indiquant le type de partition, puisque windows détermine le type de partition a partir du secteur BPB (Bios Parameter Block)


    Ensuite, concernant la taille d'un secteur, il ne peut pas etre plus petit que 512 octets (dans les notes microsoft, il est meme conseillé de laisser la taille d'un secteur a 512 octets!!!!)

    Après rien n'empêche en local dans ton µC de diviser encore la taille d'un secteur si tu manques de RAM, mais la carte DOIT être configurée de façon a avoir un secteur de 512 octets afin de conserver une certaine compatibilité entre ta carte et tous les outils/soft WINDOWS.


    Je viens de terminer le développement d'une librairie de gestion FAT16 ET FAT32 sur µC PIC18LF2520. Et ca marche nickel, écriture, lecture, copie sur la SD depuis un µC c'est assez jouissif

  11. #10
    marmotte

    Re : pic SPI et mémoire MMC

    Citation Envoyé par asmodyne Voir le message
    si vous écrasez les deux copies du MBR de la carte SD, elle sera définivement condannée à rester une "eeprom" informatable... à mois de réecrire les deux MBR telles qu'elle étaient à l'origine, depuis le PIC de votre prototype.

    Notez bien : plus de MBR, plus de formatage , même "bas niveau"... la MBR contient les informations de structure de la carte (taille, nombre de secteur, etc) essentielles au programmes de formatage (c'est assez logique qu'il ne puisse plus opérer si elle manquent).
    La aussi vous faites erreur, une carte mémoire, et meme n'importe quel volume formaté sous Windows ne contient QU'UN SEUL ET UNIQUE SECTEUR MBR.


    Sur un volume, les secteurs sont découpés comme suis:


    Secteur 0: MBR (contient les informations relatives aux partitions du volume)

    Secteur X: BPB 1ere partition (le X etant l'offset que l'on peut trouver dans l'entrée correspondante a la premiere partition du secteur MBR)
    Secteur X+1: FAT
    Secteur X+1+taille fat en secteurs: FAT copy
    Secteur X+1+2*taille fat en secteurs: Root directory (32 secteurs) sur une FAT16, ou alors 1er secteur de données sur une FAT32

    Puis, le même schéma pour chaque partition du volume



    Je pense que vous avez confondu avec les secteurs BPB et FSI d'un volume FAT32, qui quand à eux, possedent effectivement une copie pour les utilitaires de recouvrement en cas de probleme sur les secteurs originaux.

  12. #11
    inviteaca4e777

    Re : pic SPI et mémoire MMC

    Bonjour,

    Je suis tombé par hasard sur ce post fort interessant bien que je ne travaille pas sur les PICs.

    Je suis actuellement en train d'intégrer un "driver" de cartes SD / MMC sur ma carte électronique à base de ATMEL 91SAM7S.
    Le SPI n'étant pas dispo sur les PINs qu'il me reste (routage mal pensé au depart). J'ai recodé un SPI maison.

    Pour aider un petit peu Legos, les étapes d'initialisation des sD / MMC que j'ai pu trouver sont :
    - Reveiller la carte : PIN CS et MOSI à 1 + 80 cycles d'horloge
    - Passer en mode SPI : PIN CS à 0 + envoi CMD0 et attendre la réponse 0x01
    - Initialiser la carte : Envoi CMD1 et attendre la réponse 0x00

    - On peut ensuite demander le status de la carte : Envoi CMD13. La réponse doit être 0x00.

    Je bloque sur l'étape suivante pour récupérer le CSD de la carte. J'ai trouvé un code en C sur le net qui après avoir envoyé CMD9, attend de recevoir la réponse 0xFE. Or cela ne fonctionne pas. J'ai regardé à l'oscilloscope et ma carte MMC me répond 0x6F. Dans la documentation "Symplified Physical Layer Spec" des cartes SD il est indiqué que la carte répond 0b00111111 en entête...
    savez vous si le réponse R2 des MMC et des SD sont identiques et quel est la valeur du 1er octet d'entête de cette réponse ?

    en vous remerciant.

  13. #12
    marmotte

    Re : pic SPI et mémoire MMC

    Avant d'aller plus loin, quel est le niveau logique sur la pin DATA OUT que tu simules dans ton code lorsque tu attends un octet en provenance de ta carte mémoire?


    Tu utilises une MMC??? ca existe encore ???

  14. #13
    marmotte

    Re : pic SPI et mémoire MMC

    0x6F ne correspond a rien, a aucun entete, que ce soit MMC ou SD. Lorsque tu attends une réponse de ta carte mémoire suivant une requete de ton µC, le premier octet que tu dois attendre est l'un de ceux qui suivent (ils indiquent que la commande a bien été reçue), toute autre valeur indiquant un problème de communication, cet octet se nomme le RESPONSE TOKEN:

    0x00 ==> no ERROR
    0xFF ==> Bad response
    0x01 ==> Card is in Idle State
    0x04 ==> Illegal CMD
    0x20 ==> Address error
    0x40 ==> Parameter error


    Ensuite, si le premier octet (RESPONSE TOKEN) reçu est 0x00 (commande comprise et sans erreur), alors l'octet suivant doit être 0xFE (DATA TOKEN), suivis des 16 octets du CSD.



    Avant d'aller plus loin, quel est le niveau logique sur la pin DATA OUT que tu simules dans ton code lorsque tu attends un octet en provenance de ta carte mémoire?


    Tu utilises une MMC??? ca existe encore ???

  15. #14
    inviteaca4e777

    Re : pic SPI et mémoire MMC

    Merci pour ta réponse Marmotte !

    L'état haut est à 3v3 et l'état bas est à 0V

    Tout d'abord le plus simple : Lorsque j'attend une réponse de la carte voici ce que je fais :
    - Mise à l'état haut de la PIN MOSI (patte 2 sur les SD / MMC)
    - Mise à l'état bas de la PIN NPCS0 (patte 1 sur les SD / MMC)
    - Génération de crénaux sur la PIN SPCK (patte 5 sur les SD / MMC)
    Je génère les crénaux jusqu'à ce que je lise un état bas (bit de start) sur la PIN MISO (patte 7 sur les SD / MMC)
    Une fois que j'ai récupéré mon bit de start je génère 7 crénaux d'horloge et je récupère les 7 valeurs sur la PIN MISO afin de compléter mon octet.


    En ce qui conserne la réponse R2 de la carte je pense que je vais comprendre quelque chose !
    Ce que tu me dis confirme le code que j'ai trouvé qui boucle tant qu'il n'a pas 0xFE comme réponse. En suite il sort de la boucle et récupère le CSD...

    J'ai donc un problème. Je vais aprofondir et tanter de comprendre pourquoi je ne parviens pas à récupérer 0xFE.

    Et pour répondre à ta dernière question (pertinente), j'utilise une MMC car ma carte SD me répond 0x02 à la commande CMD0 qui doit être l'erreur : "Erase reset". Je me dis que les deux étant compatible, si j'arrive à utiliser une MMC, je parviendrai sûrement à utiliser la SD

    En te remerciant !

  16. #15
    inviteaca4e777

    Re : pic SPI et mémoire MMC

    C'est re moi, j'ai du nouveau :

    Depuis que Marmotte m'a indiqué que la carte renvoi d'abord un 0x00 avant la réponse, j'ai écrit l'algo qui suit :

    tant que reponse != 0x00
    lire reponse
    fin tant que

    // Si on arrive ici c'est que réponse == 0x00

    tant que reponse != 0xFE
    lire reponse
    debug(reponse)
    fin tant que

    La trace du debug me donne ça :

    resp 1 = 70; resp 2 = 7; resp 3 = 0; resp 4 = 42;
    resp 5 = 15; resp 6 = 48; resp 7 = 61; resp 8 = 62;
    resp 9 = 108; resp 10 = 1; resp 11 = 12; resp 12 = 82;
    resp 13 = 0; resp 14 = 5; resp 15 = 126; resp 16 = 106;
    resp 17 = 15; resp 18 = 255; resp 19 = 255...

    Toutes les réponses qui suivent valent 255. Si je compte j'ai bien 1 octet qui devrai être 0xFE + 16 autres octets qui correspondent à mon CSD.

    Quelqu'un a une idée ?

  17. #16
    inviteaca4e777

    Re : pic SPI et mémoire MMC

    Je fais un monologue depuis tout à l'heure mais j'ai trouvé la solution, donc c'est constructif et ça poura aider des gens...

    En fait dans ma fonction qui renvoi la réponse de la carte, j'ai une boucle qui attend le bit de start (etat bas du MISO)
    Or lorsque l'on reçoit une réponse R2, il ne faut pas attendre de bit de start.

    Pour aider les gens que ça interesse, voici l'algo de la fonction de lecture de la réponse de la carte :

    valeur de retour : l'octet lu
    argument : flag qui indique si on attend ou pas le bit de start

    Mettre MOSI à l'état haut
    Mettre NPCS0 à l'état bas

    Si (argument = vrai) Alors
    tant que (MISO est à l'état haut)
    générer un créneau d'horloge
    Fin Tant que
    Fin si

    résultat = 0

    Pour (compteur Allant de 6 à 0 Faire)
    générer un créneau d'horloge
    Si (MISO est à l'état haut) Alors
    résultat = résultat OU (0x01 << compteur)
    Fin si
    Fin Pour

    Mettre NPCS0 à l'état haut

    retourner réponse

  18. #17
    marmotte

    Re : pic SPI et mémoire MMC

    Donc le problème venait de tes fonctions d'émulation du port SPI c'est bien ca?

    Il n'existerait pas une lib pour ton µC qui implémente déjà l'émulation du port SPI?

  19. #18
    invite45a7ade9

    mémoire MMC==> pas de reponse

    Bonjour, sujet passionnant.
    Depuis le debut de la semaine j'essaye de faire passer la MMC (model sur ISIS) en mode SPI. Cela consiste à envoyer 80 clk avec CS = 1 puis la commande 0 c'est à dire CS=0 et envoi de 0x40 0 0 0 0 et 0x95.
    La reponse de la MMC doit etre 01. Le PB c'est qu'elle ne repond pas. Sans resistance de pull up elle repond toujours 0 et avec elle repond FF (comme si elle n'etait pas connectée).
    Je voulais savoir si qqun avait untilise Proteus (ISIS) pour developper un prog utilisant une SDCARD (ou MMC).
    Merci.
    THierry

  20. #19
    inviteaca4e777

    Re : pic SPI et mémoire MMC

    Bonjour,

    Bonne question Marmotte, c'est vrai que quand j'ai vu que je ne pouvai pas utiliser le périphérique SPI de mon micro, je n'ai pas cherché une bibliothèque "émulant" le SPI.

    De toute façon maintenant je l'ai recodé et il fonctionne parfaitement.

    J'ai avancé dans mes étapes de dialogue avec la MMC :
    J'arrive à récupérer le CSD et à en déduire (extraire) la capacité de la carte.

    J'essaie maintenant de lire et écrire des blocs.
    Je suis confronté à un nouveau problème :
    Les caractères que j'écris, me reviennent décalés de 1 bit vers la gauche.
    C'est à dire que si j'écris un 'B', je récupère un [132]

    'B' = 01000010
    [132] = 100000100

    Là où je suis perplexe, c'est que :
    - mes fonction d'envoi et de récupération d'octet (SPI) sont bonne puisque j'arrive à initialiser la carte, lire le CSD...
    - ma fonction qui lit le bloc (CMD17) est bonne aussi puisque je récupère bien le 0xFE juste avant de lire les 512 octets
    - La fonction d'écriture de bloc me semble pas trop mauvaise puisque la carte me répond 0x05 après l'envoi des données.

    Je suis même allé jusqu'à générer un créneau d'horloge avant l'envoi des données pour essayer de recaler mes bits d'un cran vers la droite mais du coup la carte me répond une erreur "data Rejected"

    Quelqu'un a une idée à ce sujet ?

    -------------------------------------------

    diode 87,

    Dans ta fonction de "réveil de la carte" tu doit mettre CS à 1 et MOSI à 1 également avant de générer tes créneaux d'horloge.

  21. #20
    marmotte

    Re : pic SPI et mémoire MMC

    Citation Envoyé par Karl2mil1 Voir le message


    J'essaie maintenant de lire et écrire des blocs.
    Je suis confronté à un nouveau problème :
    Les caractères que j'écris, me reviennent décalés de 1 bit vers la gauche.
    C'est à dire que si j'écris un 'B', je récupère un [132]

    'B' = 01000010
    [132] = 100000100

    Là où je suis perplexe, c'est que :
    - mes fonction d'envoi et de récupération d'octet (SPI) sont bonne puisque j'arrive à initialiser la carte, lire le CSD...
    - ma fonction qui lit le bloc (CMD17) est bonne aussi puisque je récupère bien le 0xFE juste avant de lire les 512 octets
    - La fonction d'écriture de bloc me semble pas trop mauvaise puisque la carte me répond 0x05 après l'envoi des données.

    Je suis même allé jusqu'à générer un créneau d'horloge avant l'envoi des données pour essayer de recaler mes bits d'un cran vers la droite mais du coup la carte me répond une erreur "data Rejected"

    Quelqu'un a une idée à ce sujet ?
    Oui moi


    Je crois que c est l'étape incontournable de celui qui fait le driver pour carte SD car je suis tombé sur exactement le même problème. Récupération du CSD nickel mais apres toutes les commandes décalées de 1 bit.

    En fait le probleme venait au moment ou je reconfigurais mon bus spi en haute vitesse, la pinoche de l'horloge changeait de niveau dans ma routine de configuration et c est ca qui me créait ce décalage de bit (un coup d'horloge pour rien).

    Verifies que ce soit pas un truc du style

  22. #21
    invite45a7ade9

    Smile Re : pic SPI et mémoire MMC

    Citation Envoyé par Karl2mil1 Voir le message
    Bonjour,

    Bonne question Marmotte, c'est vrai que quand j'ai vu que je ne pouvai pas utiliser le périphérique SPI de mon micro, je n'ai pas cherché une bibliothèque "émulant" le SPI.

    De toute façon maintenant je l'ai recodé et il fonctionne parfaitement.

    J'ai avancé dans mes étapes de dialogue avec la MMC :
    J'arrive à récupérer le CSD et à en déduire (extraire) la capacité de la carte.

    J'essaie maintenant de lire et écrire des blocs.
    Je suis confronté à un nouveau problème :
    Les caractères que j'écris, me reviennent décalés de 1 bit vers la gauche.
    C'est à dire que si j'écris un 'B', je récupère un [132]

    'B' = 01000010
    [132] = 100000100

    Là où je suis perplexe, c'est que :
    - mes fonction d'envoi et de récupération d'octet (SPI) sont bonne puisque j'arrive à initialiser la carte, lire le CSD...
    - ma fonction qui lit le bloc (CMD17) est bonne aussi puisque je récupère bien le 0xFE juste avant de lire les 512 octets
    - La fonction d'écriture de bloc me semble pas trop mauvaise puisque la carte me répond 0x05 après l'envoi des données.

    Je suis même allé jusqu'à générer un créneau d'horloge avant l'envoi des données pour essayer de recaler mes bits d'un cran vers la droite mais du coup la carte me répond une erreur "data Rejected"

    Quelqu'un a une idée à ce sujet ?

    -------------------------------------------

    diode 87,

    Dans ta fonction de "réveil de la carte" tu doit mettre CS à 1 et MOSI à 1 également avant de générer tes créneaux d'horloge.
    ---------------------------------------------------------------
    Merci pour votre reponse, la MMC repond depuis que j'ai enleve le pont diviseur de tension qui permet de passer du 5v (de l'ATMEL) au 3,3v de la carte==> tres etrange mais dans la simul avec ISIS il vaut mieux ne pas les mettre.
    Je passe à la lecture ecriture.

    Merci encore pour vos reponses.

    Thierry

  23. #22
    inviteaca4e777

    Re : pic SPI et mémoire MMC

    Bonjour et bon début de semaine à tous.

    Je reprend les ostilités avec ce décalage de bit lors des envois de données :

    Marmotte, le problème ne peut pas venir du changement d'horloge puisque je n'en change pas.

    Pour éclaircir le problème, je vous explique la procédure et les conclusions qu'on peut en tirer :

    fonction d'envoi :

    - envoi de la commande 24
    - attente de la réponse 0x00 de la carte
    - envoi de 2 octets (0xFF) et (0xFF) avant d'envoyer les données
    - début d'envoi des données :
    * envoi du data token 0xFE
    * envoi du data block (boucle de 512 octets)
    * envoi de 2 octets (0xFF) et (0xFF) comme CRC (CRC désactivé)
    - attente du data response (0x05)
    - attente de la fin de l'état busy de la carte (MISO repasse à 1)
    - fin d'algo

    Lors de cette procédure je récupère parfaitement les réponses de la carte. Notament le 0x05 à la fin, j'en conclue que mes données n'ont pas été envoyées décalée

    fonction de lecture :

    - envoi de la commande 17
    - attente de la réponse 0x00 de la carte
    - attente du data token 0xFE
    - récupération des 512 octets de donnée
    - debug de chaque octet reçu
    - Flush (récupération) des 2 octets de CRC (non traité)
    - fin d'algo

    Lors de la récupération des octets je trace chaque octet. C'est là que je peut voir que chaque octet est décalé d'un bit vers la gauche, comme si ma fonction de lecture n'avait pas reçu le 1er bit ou comme si le 1er bit n'avait pas été écrit dans la carte.

    Je pense que les fonctions d'emulation du SPI sont hors de cause puisque je dialogue bien avec la carte jusque là (CMD0, CSD, etc...)

    Merci d'avance pour vos réponses !

  24. #23
    invitedc586a5b

    Re : pic SPI et mémoire MMC

    Citation Envoyé par marmotte Voir le message
    Je viens de terminer le développement d'une librairie de gestion FAT16 ET FAT32 sur µC PIC18LF2520. Et ca marche nickel, écriture, lecture, copie sur la SD depuis un µC c'est assez jouissif
    Pourrais-tu partager ta libraire pour la gestion du FAT16 et du FAT32?
    Cela m'aiderai dans mon projet d'interfacer une carte SD (taille:128Mo hé oui j'ai pas plus petit) avec un µC soit PIC soit AVR.

  25. #24
    marmotte

    Re : pic SPI et mémoire MMC

    Citation Envoyé par gratox Voir le message
    Pourrais-tu partager ta libraire pour la gestion du FAT16 et du FAT32?
    Cela m'aiderai dans mon projet d'interfacer une carte SD (taille:128Mo hé oui j'ai pas plus petit) avec un µC soit PIC soit AVR.
    Désolé, ca je ne peux pas, je l'ai développé dans le cadre de mon travail. Par contre, je peux aider en cas de problème en cours de développement ou donner des informations qui sont parfois un peu flou, je l'accorde.

    Si tu veux commencer sur de bonnes bases, lit le Microsoft Hardware White paper, ensuite je répondrai a tes questions sans problème.

  26. #25
    invitedc586a5b

    Re : pic SPI et mémoire MMC

    Citation Envoyé par marmotte Voir le message
    Désolé, ca je ne peux pas, je l'ai développé dans le cadre de mon travail. Par contre, je peux aider en cas de problème en cours de développement ou donner des informations qui sont parfois un peu flou, je l'accorde.

    Si tu veux commencer sur de bonnes bases, lit le Microsoft Hardware White paper, ensuite je répondrai a tes questions sans problème.
    J'ai lu le white paper de microsoft (et une traduction en langue de Molière, le français). j'ai bien compris l'utilité du BPB mais là où je coince c'est sur le MBR (j'ai pas tout compris du MBR). Sinon j'ai compris que les répertoires sont des "fichiers" spéciaux avec l'attribut 'directory' et contenant une liste chainé vers les fichiers qui se trouvent dedans. Et les fichiers sont eux même une liste chainé.

    Donc j'aimerai savoir comment faire pour ne lire pour le moment que le répertoire "root" (racine) et pouvoir lire les fichiers qui se trouvent dans se répertoire, pour les autres répertorie,cela ne doit pas trop poser de problème. Et pour faire la liste, il doit suffit de n'afficher que les fichier qui n'ont l'attribut 'directory' ouest-ce que je comet une erreur?

  27. #26
    marmotte

    Re : pic SPI et mémoire MMC

    Concernant le MBR, as tu lu le message n°9 de ce thread?

    En gros le MBR c'est le premier secteur a lire, il liste l'ensemble des partitions du volume. En general un SD n'est pas partitionnée donc tu auras une seule partition. En lisant la premiere entrée du MBR (offset 0x1BE) tu pourras récuperer l'offset du BPB. Ensuite d'apres ton message tu sais faire

    LE MBR est découpé comme ceci:

    Offset 0x0 ==> Code executable - 446 octets (aucune utilité pour une carte flash)
    Offset 0x1BE ==> 1ere entrée du MBR = 1ere partition du volume - 16 octets (précisemment cette entrée qui nous interresse)
    Offset 0x1CE ==> 2eme entrée = 2eme partition (en general inutile, saus carte formatée en plusieurs partitions)
    Offset 0x1DE ==> 3 eme entrée
    Offset 0x1EE ==> 4eme et derniere entrée
    Offset 0x1FE ==> Mark - 2 octets - toujours 0x55 0xAA, si tu ne trouves pas ces valeurs, le MBR esr corrompu.

    Pour le detail de chaque entrée voir mon messahe #9 sur ce fil



    Concernant les fichiers/rep

    En effet, un repertoire est un fichier avec un attribut spécial, le premier cluster de l'entrée correspondante a ce repertoire, est en fait le cluster contenant TOUTES les entrées des fichiers/repertoires contenus dans ce repertoire.
    Les 2 premieres entrées d'un répertoire sont OBLIGATOIREMENT "." et "..", excepté pour le RootDirectory d'une FAT16 (dans une FAT32 le root directory n existe pas)
    Les fichiers sont égalements des listes chainées, le premier element etant indiqué dans l'entrée correspondante a un fichier, les autres elements, si ils existent, se trouvant dans la FAT.

    Concernant l'emplacement du rootdirectory je l'explique dans mon message #10.

    Hesite pas a ma contacter par MP...

  28. #27
    inviteaca4e777

    Re : pic SPI et mémoire MMC

    Bonjour,

    Etant toujous bloqué avec la MMC, j'a décidé de tester mon code avec un SD.
    J'arrive à réveiller la carte et la passer en SPI, à envoyer la commande CMD0, mais la carte me retourn "illegal command" lors de l'envoi de la commande CMD1.

    Quelqu'un a une idée ?

    Merci !

  29. #28
    invitedc586a5b

    Re : pic SPI et mémoire MMC

    Pour le moment, je ne pas t'aider car jesuis qu'au stade de l'étude. Je suis en train de faire le schéma d'une carte avec soit un pic soit un avr, je sait pas encore avec une carte SD et plusieur mode de communication (surement I2C, série, et autre que je n'ai pasencore fini de définir ce que fera ma carte).

  30. #29
    RISC

    Re : pic SPI et mémoire MMC

    Salut Karl2mil1,

    Tu peux t'inspirer des notes d'application déjà existantes pour les SD/MMC et la FAT 16 :

    FAT16 : http://www.microchip.com/stellent/id...pnote=en532040

    carte SD :
    http://www.microchip.com/stellent/id...pnote=en024394

    a+

  31. #30
    Olorin113

    Exclamation Re : pic SPI et mémoire MMC

    bonjour

    J'ai lu attentivement ce forum, et je suis très intéresse par la FAT32!
    Sur ma mémoire flash, quand je lit dessus, je trouve le MBR sur le secteur 0 ( entre 0 et 512 Octets), et je le retrouve sur les secteurs 3 et 6 (entre 512*3 et 512*4 Octets, et entre 512*6 et 512*7 Octets ).

    Est-ce normal? Voulez vous que je détaille ? (bon sa va faire très long...)
    Dernière modification par Olorin113 ; 16/04/2008 à 18h01.

Page 1 sur 2 1 DernièreDernière

Discussions similaires

  1. pic 16f88 et SPI
    Par invite7973ef56 dans le forum Électronique
    Réponses: 21
    Dernier message: 17/07/2009, 09h14
  2. vente PIC 16F877A et Programmateur Universel SPI Presto
    Par invite07812344 dans le forum Électronique
    Réponses: 2
    Dernier message: 06/09/2007, 11h52
  3. initialisation mémoire mmc et pic
    Par inviteef26fb36 dans le forum Électronique
    Réponses: 0
    Dernier message: 19/06/2007, 11h27
  4. 8051 et EEPROM SPI pour mémoire de programme
    Par invite7318634f dans le forum Électronique
    Réponses: 3
    Dernier message: 22/04/2006, 16h55
  5. Carte mémoire MP3 SD et MMC?
    Par invite4f7d9961 dans le forum Matériel - Hardware
    Réponses: 0
    Dernier message: 26/01/2006, 19h15
Découvrez nos comparatifs produits sur l'informatique et les technologies.