SPI parece confuso en MSP430

9

Estoy tratando de obtener partes sensibles de un Bus Pirate conectado a una placa Launchpad (Usando el cable Sparkfun: Naranja va a P1.6, Amarillo a P1.5. Esto debería ser correcto, a menos que tenga confundidos MOSI y MISO ...) No tengo CS conectado, ya que solo estoy usando el pirata del autobús para monitorear cualquier cosa.

El pirata de bus está configurado para SPI, 125 kHz, polaridad de reloj inactivo bajo, salida de reloj de borde activo a inactivo, fase de muestra de entrada media, / CS, la salida es normal.

En el Launchpad, tengo un MSP430G2231 sin cristal externo. Usando Code Composer Studio, tengo lo siguiente:

#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 mayor parte de esto está empedrado de varias muestras. Después de mucha lectura de la hoja de datos, parece que el reloj USI está configurado para ejecutarse a 125KHz (SMCLK de 1MHz, dividido por 8), aunque no tengo un alcance para medir esto.

Cuando corro, obtengo lo que es esencialmente basura del pirata del autobús. P puso un punto de interrupción en la primera línea del vector de interrupción USI, y lo hizo pasar tres veces, por lo que debería haber obtenido 0, 1, 2 del pirata del autobús

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

Y dejándolo correr libremente, solo obtengo cosas como esta:

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

Que todavía no se parece en nada a lo que estoy esperando.

Pasé la mayor parte de la tarde revisando la guía del usuario para el chip, y todavía estoy perplejo.

Mientras escribía esto, descubrí que puedo usar el Bus Pirate como un analizador lógico (usando LogicSniffer), y lo configuré para hacerlo. Y modificó el programa para escribir 0x55 a USISRL, y cambiar el USIDIVque USIDIV_4a las cosas frenar un poco más, y aquí está el resultado: ingrese la descripción de la imagen aquí

La señal del reloj se ve bien, LogicSniffer informa que se trata de 285KHz ... y MOSI es ... especial. Esperaría un patrón alternativo agradable, ya que estoy escribiendo 0x55, y eso es todo lo contrario.

¿Alguien tiene alguna idea sobre lo que podría estar haciendo mal? Chip defectuoso? ¿Algo más?

EDITAR: Ok, una pequeña cantidad de idiotez de mi parte. No cambié el valor que se escribe en SPI en la interrupción. Hacer esto da como resultado el patrón esperado:

ingrese la descripción de la imagen aquí

Sin embargo, volver a intentar escribir un byte incremental me da basura: ingrese la descripción de la imagen aquí

Entonces, todavía tengo un problema, pero no tan grande como pensé ...

EDITAR 2: Gracias a los comentarios a continuación, até el cable de tierra del cable Bus Pirate, que anteriormente estaba desconectado, a tierra de mi fuente de alimentación (fuente de alimentación de placa de prueba de Sparkfun). Anteriormente, el terreno más cercano que compartían estaba de vuelta en el concentrador USB del que cuelgo todo este equipo.

Esto eliminó la falla en MOSI al ejecutar el programa de contador, y LogicSniffer ahora puede decodificar los bytes correctamente por sí mismo: ingrese la descripción de la imagen aquí

El pirata del autobús en modo monitor aún informa resultados extraños:

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

Parece más capaz de detectar los extremos de las escrituras (supongo que eso es lo que delimitan los corchetes), pero los datos de decodificación aún están desactivados. Ahora no estoy tan preocupado de que la forma de onda se vea mejor, pero aún así sería bueno saber por qué el Bus Pirate se está confundiendo.

Matt Sieker
fuente
3
Parece que el último diagrama tiene fallas en la línea MOSI, podría ser una diafonía desde el clk. ¿Eres un osciloscopio? ¿Cómo es su cableado? ¿Tiene un buen corto y sólido terreno entre el BusPirate y el MSP430?
Martin Thompson el
2
Estoy de acuerdo con @MartinThompson. La línea MOSI está fallando y el Bus Pirate se está confundiendo. Si entrecierra un poco los ojos en la segunda imagen e ignora lo que Bus Pirate cree que ve (simplemente escribí el binario que veo en la calculadora de Windows y lo convertí en hexadecimal), obtiene 6B-6C-6D, incrementándolo como lo desea. Necesita limpiar el cableado entre el Bus Pirate y el MSP.
embedded.kyle
No veo un while(1);o equivalente al final de main () para evitar que salga y haga cosas al azar.
Oli Glaser
2
@OliGlaser, si estoy leyendo la hoja correctamente, entrar en LPM0 en realidad detiene la ejecución de la CPU hasta que se produce una interrupción. La mayoría, si no todas las muestras de TI usan esto. Tiene sentido, ya que promocionan los MSP430 como partes de baja potencia, y un circuito ocupado no es muy amigable con la energía.
Matt Sieker
1
Oh, acabo de notar que esto tiene> 1 año.
apalopohapa

Respuestas:

3

MSP430 es un ejemplo de MCU que invierte la convención de nomenclatura de CPHA, divergiendo así de la descripción estándar de SPI: TI MSP430 usa el nombre UCCKPL en lugar de CPOL, y su UCCKPH es el inverso de CPHA. Cuando conecte dos chips juntos, examine cuidadosamente los valores de inicialización de la fase del reloj para asegurarse de usar la configuración correcta.

Dirceu Rodrigues Jr
fuente