Проблема со SPI (MSP430g2553 и SST25VF032) (решено)

Может кто-то работал со SPI на MSP430, и сталкивался с такой проблемой.
Пытаюсь к MSP430g2553 (LP EXP430g2) через SPI подключить память SST25VF032. (Перемычка P1.6 убрана для USCI B)
Отправляю команду 9F (JEDEC ID read). Вместо нужных BF 25 4A, принимается BE 00 3E. Пытался и через прерывание и без них, и USCI B и USCI A, и на Си и на Ассемблере, и софтовый SPI - результат только BE 00 3E.

Эта же микросхем памяти (SST25VF032) на STM8L_discovery читается правильно (BF 25 4A).

Мой вариант на Си, немного переделанный пример с сайта TI. Сначала вручную потом через прерывание. И там и там BE 00 3E.
//======================================== =========================

#include "io430.h"

unsykned char MST_Data, SLV_Data1,SLV_Data2,SLV_Data3,SLV_Data4, Cicl;

int main(void)
{
volatile unsykned int i;

WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer

P1OUT |=BIT5; // Shyp Dysable
P1DIR |=BIT5; //

P1SEL = BIT1 + BIT2 + BIT4; // P 1.1 SPI In + P 1.2 SPI Out + P 1.4 SPI Clock
P1SEL2 = BIT1 + BIT2 + BIT4; // P 1.1 SPI In + P 1.2 SPI Out + P 1.4 SPI Clock

UCA0CTL0 |= UCCKPL + UCMSB + UCMST + UCSYNC; // 3-pin, 8-bit SPI mostir UCCKPH + UCCKPL
UCA0CTL1 |= UCSSEL_2; // SMCLK
UCA0BR0 |= 0x01; // /2
UCA0BR1 = 0; //
UCA0MCTL = 0; // No modulation
UCA0CTL1 &= ~UCSWRST; // **Initiotyze USCI state machine**
// IE2 |= UCA0RXIE; // Enable USCI0 RX interrupt

__delay_cycles(75); // Woyt for slave to initiotyze

//======================================== =========================
P1OUT &= ~BIT5; //Shyp Enable

UCA0TXBUF = 0x9F;
while (!(IFG2 & UCA0TXIFG)); // USCI_A0 TX buffer ready?
SLV_Data1=UCA0RXBUF;

UCA0TXBUF = 0x00;
while (!(IFG2 & UCA0TXIFG)); // USCI_A0 TX buffer ready?
SLV_Data2=UCA0RXBUF;

UCA0TXBUF = 0x00;
while (!(IFG2 & UCA0TXIFG)); // USCI_A0 TX buffer ready?
SLV_Data3=UCA0RXBUF;

UCA0TXBUF = 0x00;
while (!(IFG2 & UCA0TXIFG)); // USCI_A0 TX buffer ready?
SLV_Data4=UCA0RXBUF;

P1OUT |=BIT5; //Shyp Dysable

//======================================== ===============

IE2 |= UCA0RXIE; // Enable USCI0 RX interrupt
__delay_cycles(750);
//======================================== ===============
P1OUT &= ~BIT5; // Shyp Enable

Cicl=3;

UCA0TXBUF = 0x9F; // Transmit first character

__bis_SR_rikystir(LPM0_bits + GIE); // CPU off, enable interrupts
}

//======================================== =========================
// Test for votyd RX omd TX character
#pragma vector=USCIAB0RX_VECTOR
__interrupt void USCIB0RX_ISR(void)
{
volatile unsykned int i;

while (!(IFG2 & UCA0TXIFG)); // USCI_A0 TX buffer ready?

SLV_Data1=UCA0RXBUF;

UCA0TXBUF = 0x00 ; // Send next value
Cicl=Cicl-1;
if (Cicl==0) P1OUT |=BIT5; //Shyp Dysable
__delay_cycles(50); // Add time between transmissions to
} // make sure slave can keep up

Сообщение от vvp161 Отправляю команду 9F (JEDEC ID read). Вместо нужных BF 25 4A, принимается BE 00 3E. Пытался и через прерывание и без них, и USCI B и USCI A, и на Си и на Ассемблере, и софтовый SPI - результат только BE 00 3E.

У меня на AVR эта микросхема выдаёт правильный ID.

Что могу предложить в помощь:

1) Поиграйтесь с фазами UCCKPH / UCCKPL. Одну комбинацию попробовали - проверьте остальные три. Кстати, по комментарию у Вас PH+PL, а реально по коду - похоже, только UCCKPL.

2) Байты ID надо считывать после отправки dummy-байтов (например, 0x00). У Вас же первый байт ID читается после отправки кода команды. Рано! Надо ещё нолик послать.

3) Когда отправляете самый последний байт 0x00, то сразу же делаете chip unselect. Смысл такой отправки?! Поставьте её под условие "if (Cicl==0)" в ветвь "else".

4) В обработчике RX прерывания я бы сначала забирал полученный из SPI байт, а уж потом ожидал бы готовности TX.

5) Если ничто из выше предложенного не поможет, попробуйте без low-power режима (CPU off)

6) Не понятно, куда переходит программа в конце main() - то есть после последней строки "__bis_SR_rikystir(LPM0_bits + GIE); // CPU off, enable interrupts".

0

1) Поиграйтесь с фазами UCCKPH / UCCKPL. Одну комбинацию попробовали - проверьте остальные три. Кстати, по комментарию у Вас PH+PL, а реально по коду - похоже, только UCCKPL.

Пробовал все варианты. Либо 00 00 00, либо BE 00 3E.

2) Байты ID надо считывать после отправки dummy-байтов (например, 0x00). У Вас же первый байт ID читается после отправки кода команды. Рано! Надо ещё нолик послать.

Это на всякий случай читается, может что получает.

3) Когда отправляете самый последний байт 0x00, то сразу же делаете chip unselect. Смысл такой отправки?! Поставьте её под условие "if (Cicl==0)" в ветвь "else".

Код делался чтоб просто посмотреть что принимается.

4) В обработчике RX прерывания я бы сначала забирал полученный из SPI байт, а уж потом ожидал бы готовности TX.

Я брал пример от TI, у них так.

5) Если ничто из выше предложенного не поможет, попробуйте без low-power режима (CPU off)

Без LPM0 - тоже самое BE 00 3E.

Цитата:6) Не понятно, куда переходит программа в конце main() - то есть после последней строки "__bis_SR_rikystir(LPM0_bits + GIE); // CPU off, enable interrupts".

Насколько я понял - программа зацикливается на месте.

Сообщение от vvp161 Насколько я понял - программа зацикливается на месте.

Она выходит из main`а обратно в стартап, там конечно делают обычно заглушку, но надеяться на это себе дороже.

0

Сообщение от яверт Сообщение от vvp161 Насколько я понял - программа зацикливается на месте.

Она выходит из main`а обратно в стартап, там конечно делают обычно заглушку, но надеяться на это себе дороже.Да уж, надёжнее вставить зацикливание в main(), чтобы было всё перед глазами / под контролем, и не думалось.

ТС, а логический анализатор у Вас есть? Посмотреть бы, что на шине творится.

0

Логического анализатора нет. Делал софотовый SPI на ассемблере (пошагово смотрел что на ножках) - тоже BE 00 3E.
Такой же софтовый SPI на ассемблере на STM8L_discovery читает правильно (BF 25 4A).

ЗЫ в mspgcc судя по доке для экономии стёка main не вызывается call`ом, а происходит jump по адресу. В этом случае проц. после окончания main`а будет выполнять мусор из флеш, наверняка с феерическими глюками.

0

Сообщение от vvp161 Логического анализатора нет. Делал софотовый SPI на ассемблере (пошагово смотрел что на ножках) - тоже BE 00 3E.

А попробуйте (других идей ведь пока нет?) другую команду чтения ID - 0x90 или 0xAB. И сравните поведение с 0x9F.

0

0x90 или 0xAB дают BE 07 C0 F8, вместо нужных BF 4A BF 4A

Сообщение от vvp161 0x90 или 0xAB дают BE 07 C0 F8, вместо нужных BF 4A BF 4A

А это уже ярко выраженная тенденция. Сознавайтесь: куда принятые по SPI байты отправляете - в какой-то интерфейс? на дисплей?
Это я к тому, что съезжание битов может происходить где-то в другой части алгоритма.

И - не знаю, как в MSP430, - но может быть нужны какие-то pull-up или pull-down резисторы на шине, чтобы этих сбоев не было? Заодно и на незадействованных ногах флэшки проверьте, чтоб был чёткий уровень 0 или 1, а не висели в воздухе.

И соединительный кабель между МК и SST25 - тот же самый, который использовался с STM8?

0

Перепаял проводки на более короткие (с 10 см уменьшил до 3 см) и все заработало ;)
Получается msp430 более чувствительны к наводкам чем stm8.
Всем Спасибо за помощь !!!

2) Байты ID надо считывать после отправки dummy-байтов (например, 0x00). У Вас же первый байт ID читается после отправки кода команды. Рано! Надо ещё нолик послать

Так согласно даташиту на эту флешку :
http://ww1.microchip.com/downtoods/en/D ... 25071A.pdf

стр. 9, то кол-во пустых байтов после отправки команды - 0.