SPI Wygląda na zniekształcony na MSP430

Próbuję wydobyć sensowne fragmenty z Bus Pirate podłączonego do tablicy Launchpad (za pomocą kabla Sparkfun: pomarańczowy przechodzi do P1.6, żółty do P1.5. To powinno być poprawne, chyba że mam pomieszane MOSI i MISO ...) Nie mam podłączonego CS, ponieważ po prostu używam pirata autobusowego do monitorowania czegokolwiek.

Pirat magistrali jest ustawiony na SPI, 125 kHz, Biegunowość zegara Bezczynność niska, zbocze zegara wyjściowego Aktywne do bezczynności, wejściowa faza próbki środkowa, / CS, wyjście jest normalne.

Na Launchpad mam MSP430G2231 bez zewnętrznego kryształu. Korzystając z Code Composer Studio, mam następujące funkcje:

#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);  
}

Większość z nich jest poskładana razem z różnych próbek. Po długim czytaniu arkusza danych wydaje się, że zegar USI działa na częstotliwości 125 KHz (SMCLK 1 MHz, podzielony przez 8), chociaż nie mam zakresu, aby to zmierzyć.

Kiedy biegam, wyciągam z piratów autobusowych to, co w gruncie rzeczy jest śmieciami. P umieścił punkt przerwania na pierwszej linii wektora przerwań USI i kazał przejść trzy razy, więc powinienem dostać 0, 1, 2 od pirata autobusu

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

I pozwalając mu na swobodny bieg, dostaję takie rzeczy:

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

Co nadal nie wygląda tak, jak się spodziewam.

Spędziłem większość wieczoru, przeglądając przewodnik użytkownika po chipie i nadal jestem zakłopotany.

Pisząc to, odkryłem, że mogę używać Bus Pirate jako analizatora logiki (używając LogicSniffer) i skonfigurowałem go, aby to zrobić. I zmodyfikowany program do pisania 0x55 do USISRLi zmienić USIDIVsię USIDIV_4, aby spowolnić nieco więcej, a oto wyniki:

Sygnał zegara wygląda dobrze, LogicSniffer donosi, że ma około 285 kHz ... a MOSI jest ... wyjątkowy. Spodziewałbym się ładnego naprzemiennego wzorca, ponieważ piszę 0x55 i to wszystko.

Czy ktoś ma jakieś przemyślenia na temat tego, co robię źle? Wadliwy chip? Coś innego?

EDYCJA: Ok, niewielka ilość idiotyzmu z mojej strony. Nie zmieniłem wartości zapisywanej do SPI w przerwie. Wykonanie tego powoduje oczekiwany wzorzec:

Jednak wracając do próby zapisania bajtu inkrementującego, dostaję śmieci:

Nadal mam problem, ale nie tak duży, jak myślałem ...

EDYCJA 2: Dzięki poniższym komentarzom przywiązałem przewód uziemiający do kabla Bus Pirate, który wcześniej nie był podłączony, do uziemienia mojego zasilacza (zasilacza płyty głównej Sparkfun). Wcześniej najbliższy wspólny grunt był z powrotem w koncentratorze USB, na którym zawiesiłem cały ten sprzęt.

To usunęło usterki w MOSI podczas uruchamiania programu licznika, a LogicSniffer może teraz samodzielnie samodzielnie poprawnie dekodować bajty:

Pirat autobusowy w trybie monitorowania nadal zgłasza dziwne wyniki:

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

Wydaje się, że lepiej wykrywa końce zapisów (zakładam, że to, co ograniczają nawiasy kwadratowe), ale dane dekodowania są nadal wyłączone. Nie jestem już tak zaniepokojony faktem, że kształt fali wygląda lepiej, ale byłoby miło wiedzieć, dlaczego Bus Pirate się myli.

MSP430 jest przykładem MCU, który odwraca konwencję nazewnictwa CPHA, tym samym odbiegając od standardowego opisu SPI: TI MSP430 używa nazwy UCCKPL zamiast CPOL, a jego UCCKPH jest odwrotnością CPHA. Podczas łączenia dwóch układów razem dokładnie sprawdź wartości inicjalizacji fazy zegara, aby upewnić się, że używasz odpowiednich ustawień.