SPI semble brouillé sur MSP430

9

J'essaie d'obtenir des bits sensés d'un Bus Pirate connecté à une carte Launchpad (Utilisation du câble Sparkfun: Orange passe à P1.6, Jaune à P1.5. Cela devrait être correct, sauf si j'ai confondu MOSI et MISO ...). Je n'ai pas de CS connecté, car j'utilise simplement le pirate de bus pour surveiller quoi que ce soit.

Le pirate de bus est configuré pour SPI, 125 KHz, polarité d'horloge Idle faible, front d'horloge de sortie Actif à inactif, entrée de phase d'échantillonnage au milieu, / CS, la sortie est normale.

Sur le Launchpad, j'ai un MSP430G2231 sans cristal externe. En utilisant Code Composer Studio, j'ai les éléments suivants:

#include  "msp430g2231.h"
volatile unsigned char value=0;

#pragma vector=USI_VECTOR
__interrupt void universal_serial_interface(void)
{
    value+=1;
    USISRL=value;
    USICNT=8;
}
void main(void){
    WDTCTL = WDTPW + WDTHOLD;

    BCSCTL1 = CALBC1_1MHZ;                    // Set range
    DCOCTL = CALDCO_1MHZ;
    BCSCTL2 &= ~(DIVS_3);

    USICTL0 |= USIPE7 +  USIPE6 + USIPE5 + USIMST + USIOE;
    USICTL1 |= USIIE;
    USICKCTL = USIDIV_3 + USISSEL_2;
    USICTL0 &= ~USISWRST;
    USISRL=value;
    USICNT = 8;

    __bis_SR_register(LPM0_bits+ GIE);  
}

La plupart de ces informations sont bricolées à partir des différents échantillons. Après beaucoup de lecture de la fiche technique, il semble que l'horloge USI soit réglée pour fonctionner à 125 kHz (SMCLK de 1 MHz, divisé par 8), bien que je n'ai pas la possibilité de mesurer cela.

En courant, j'obtiens ce qui est essentiellement des ordures du pirate de bus. P a mis un point d'arrêt sur la première ligne du vecteur d'interruption USI, et l'a fait passer trois fois, donc j'aurais dû obtenir 0, 1, 2 du pirate du bus

0x00(0x00)0x00(0x00)][0x40(0x00)]

Et en le laissant tourner librement, je reçois juste des trucs comme ça:

[0xFF(0x00)][0x3F(0x00)][0x7F(0x00)][0xBF(0x00)][0xC0(0x00)0x00(0x00)][0x40(0x00)0x80(0x00)]

Ce qui ne ressemble toujours pas à ce que j'attends.

J'ai passé la majeure partie de la soirée à parcourir le guide d'utilisation de la puce, et je suis toujours perplexe.

En écrivant ceci, j'ai découvert que je pouvais utiliser le Bus Pirate comme analyseur logique (en utilisant LogicSniffer), et le configurer pour le faire. Et modifié le programme pour écrire 0x55 à USISRLet changer USIDIVpour USIDIV_4de ralentir les choses un peu plus, et voici les résultats: entrez la description de l'image ici

Le signal d'horloge semble bon, LogicSniffer rapporte qu'il s'agit d'environ 285 KHz ... et MOSI est ... spécial. Je m'attendrais à un joli modèle alternatif, puisque j'écris 0x55, et c'est tout sauf.

Quelqu'un a-t-il des idées sur ce que je pourrais faire de mal? Puce défectueuse? Autre chose?

EDIT: Ok, petite quantité d'idiotie de ma part. Je n'ai pas modifié la valeur qui est écrite dans SPI dans l'interruption. Cela entraîne le modèle attendu:

entrez la description de l'image ici

Cependant, revenir à la tentative d'écriture d'un octet d'incrémentation me fait du mal: entrez la description de l'image ici

Donc, j'ai toujours un problème, mais pas aussi gros que je le pensais ...

EDIT 2: Grâce aux commentaires ci-dessous, j'ai attaché le fil de terre du câble Bus Pirate, qui n'était pas connecté auparavant, à la masse de mon alimentation (alimentation de la platine d'essai de Sparkfun). Auparavant, le terrain le plus proche qu'ils partageaient était de retour dans le concentrateur USB auquel je suspendais tout cet équipement.

Cela a supprimé les pépins sur MOSI lors de l'exécution du programme de compteur, et LogicSniffer peut désormais décoder correctement les octets par lui-même: entrez la description de l'image ici

Le pirate de bus en mode moniteur rapporte toujours des résultats étranges:

[0x00(0x00)][0x04(0x00)][0x06(0x00)][0x10(0x00)][0x10(0x00)][0x10(0x00)][0x12(0x00)][0x18(0x00)]

Il semble mieux en mesure de détecter les extrémités des écritures (je suppose que c'est ce que délimitent les crochets), mais les données sont décodées est toujours désactivée. Je ne suis plus aussi inquiet maintenant que la forme d'onde soit meilleure, mais ce serait quand même bien de savoir pourquoi le Bus Pirate se confond.

spi msp430 Matt Sieker
la source
3
Ce dernier diagramme semble avoir des défauts sur la ligne MOSI, pourrait être une diaphonie du clk. Avez-vous un oscilloscope? À quoi ressemble le câblage - avez-vous une bonne mise à la terre solide entre le BusPirate et le MSP430?
Martin Thompson
2
Je suis d'accord avec @MartinThompson. La ligne MOSI pépine et le Bus Pirate devient confus. Si vous plissez les yeux un peu sur la deuxième image et ignorez ce que Bus Pirate pense voir (je viens de taper le binaire que je vois dans la calculatrice Windows et converti en hex), vous obtenez 6B-6C-6D, incrémentant comme vous le souhaitez. Vous devez nettoyer le câblage entre le Bus Pirate et le MSP.
embedded.kyle
Je ne vois pas un while(1);ou équivalent à la fin de main () pour l'empêcher de sortir et de faire des choses aléatoires.
Oli Glaser
2
@OliGlaser, si je lis bien la feuille, entrer dans LPM0 arrête en fait l'exécution du CPU jusqu'à ce qu'une interruption se produise. La plupart, sinon tous les échantillons de TI l'utilisent. Cela a du sens, car ils vantent les MSP430 comme des pièces de faible puissance, et une boucle occupée n'est pas très économe en énergie.
Matt Sieker
1
Oh mon Dieu, je viens de remarquer que c'est> 1 an.
apalopohapa

Réponses:

3

Le MSP430 est un exemple de microcontrôleur qui inverse la convention de dénomination de l'ACSP, s'écartant ainsi de la description SPI standard: TI MSP430 utilise le nom UCCKPL au lieu de CPOL, et son UCCKPH est l' inverse de CPHA. Lorsque vous connectez deux puces ensemble, examinez attentivement les valeurs d'initialisation de la phase d'horloge pour être sûr d'utiliser les bons paramètres.

Dirceu Rodrigues Jr
la source