Перейти к содержанию
    

SPI1 в STM32F429 считывает 0 в младший бит

Если не давать сброс на периферийное устройство (slave), подключенное к SPI, то у него на выходе MISO стоит твердая единица. Однако если считывать в процессор, то вместо 0xFF читается 0xFE.

 

Происходит ошибочное чтение нестабильно. Иногда читается правильно. Однако если к выходу SPI CLK присоединить щуп осциллографа, то правильного чтения больше не происходит. Стабильно читается 0xFE.

 

Я нашел в форуме ST, что такое происходит если читать данные не дожидаясь установки RXNE в единицу. Однако в моем коде я жду установки RXNE в единицу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Попробуйте прочитать по флагу BSY. Вообще есть ли у вас возможность посмотреть оба канала - MISO относительно клока?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Смотря, каким фронтом записываете и читаете. Надо внимательно изучить все варианты.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Попробуйте прочитать по флагу BSY.

+1.

В своё время отлаживал SPI, приходилось плясать вокруг разных битов статуса. До конца не стал вникать, как оно по феншую должно быть. Получил вариант, который работает, и оставил его:

SPI1_DR = 0x05;
while ((SPI1_SR & (1 << 1)) == 0) { /* wait for TXE */ }
while ((SPI1_SR & (1 << 0)) == 0) { /* wait for RXNE */ }
while ((SPI1_SR & (1 << 7)) != 0) { /* wait for !BUSY */ }
CS_DEASSERT();
return SPI1_DR;

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вообще сам флаг BSY для приема использовать не правильно. Для этого и нужен RXNE. Я отлаживая SPI на LIS3DS6 при вылавливании косяков тоже его использовал, думая что он сейчас все решит. Проблема оказалась в другом.

После записи в регистре DR оставалось 2 байта. и при следующем чтении CS устанавливался и сразу сбрасывался

И считывалось хрен знает что. Может тут тоже CS ножка на этот бит улетает и MISO в HiZ попадает? Отсюда и периодические срабатывания...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Попробуйте прочитать по флагу BSY. Вообще есть ли у вас возможность посмотреть оба канала - MISO относительно клока?

 

Оба канала в смысле MOSI MISO? Нет как раз спалил логический анализатор. Только двухлучевой осциллограф.

 

Но у меня на MISO жестко стоит единица -- нет надобности. Должен всефда читать 0xFF.

 

Смотря, каким фронтом записываете и читаете. Надо внимательно изучить все варианты.

 

Там всего четыре варианта. Я выбрал то, что надо периферийному устройству:

инвертированный CLK и по читать фронту. Но в моем тесте нет вариантов получить сдвиг или гонки на меняющемся в момент выборки входе даже если неправильная фаза выборки -- у меня всегда единица на входе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Оба канала в смысле MOSI MISO? Нет как раз спалил логический анализатор. Только двухлучевой осциллограф.

Я когда боролся с акселерометром нашел проблему просмотрев одновременно сигналы CS, MISO, CLK.

Если есть возможность посмотрите их. У меня тоже читалось одно, а на ноге была единица - как я понял она подтягивалась осциллографом, я это по ссылке выше описывал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Но у меня на MISO жестко стоит единица -- нет надобности. Должен всефда читать 0xFF.

Видел такое, вроде, на SPI4 на PE2-PE6.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Видел такое, вроде, на SPI4 на PE2-PE6.

 

На форуме поддержки мне написали, что известная проблема, но ST не шевелится:

 

This is a recurrent problem, with around a dozen threads on this forum, which was never completely investigated down to the root - but I am afraid it can't be without active involvement of ST.

 

It might be related to the sequencing of the very first SCK clock after enabling the peripheral, i.e. whether the SCK line was in active or inactive state from the point of view of CPOL just before enabling the peripheral or so. I've seen issues of a similar nature although not quite the same, when changing CPOL/CPHA on-the-go without stopping/restarting the peripheral (it's lots of fun to find out what's going on, I can recommend it as a weekend project ;-) ). Also, one friend of mine discovered, that the SPI receiver is driven from the pin directly rather than from an internal signal (i.e. when no pin was not set as SPI-SCK AF, the receiver did not work at all).

 

I can't quite explain how could it be more specific to SPI1 - either through different parasitics, or different source clock (different APB)?

 

https://my.st.com/public/STe2ecommunities/m...urrentviews=260

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

На форуме поддержки мне написали, что известная проблема, но ST не шевелится:

Хоть бы в эррате упомянули.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что-то мне подсказывает, что если прочитать руководство, то окажется, что-нибудь из примечаний пользователи не выполняют.

У меня в STM32F207 переключаются режимы работы, так сначала запрещаю, изменяю, потом разрешаю. И все работает. Не думаю, что в STM32F429 сделали неработающий SPI. Не верю!

На упомянутом выше форуме поддержки сидят Кубодрочеры, похоже.

 

void AnaDAC_send(uint16_t data)
{
  ANAS->CR1 &= ~SPI_CR1_SPE;        // запретить SPI
  ANAS->CR1 |= SPI_CR1_CPOL;        // данные стабильные на срезе \_
  ANAS->CR1 |= SPI_CR1_SPE;            // разрешить SPI

  ANSYN_ON();                        // \__
  ANAS->DR = (uint8_t)(data >> 8);    // послать биты 15 - 8
  while (!(ANAS->SR & SPI_SR_TXE));    // ждать освобождение буфера
  ANAS->DR = (uint8_t)(data);        // послать биты 7 - 0
  while (!(ANAS->SR & SPI_SR_TXE));    // ждать освобождение буфера
  // while (!(ANAS->SR & SPI_SR_RXNE)); // ждать конец передачи - нельзя!
  while (ANAS->SR & SPI_SR_BSY);    // ждать освобождение приемопередатчика
  ANSYN_OFF();                        //            __/

  ANAS->CR1 &= ~SPI_CR1_SPE;        // запретить SPI
  ANAS->CR1 &= ~SPI_CR1_CPOL;        // данные стабильные на фронте _/
  ANAS->CR1 |= SPI_CR1_SPE;            // разрешить SPI
}

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не думаю, что в STM32F429 сделали неработающий SPI. Не верю!

 

Да я тоже не верю, но уж упростил задачу до минимума. Инициализирую SPI, удерживаю периферию в сбросе (что значит на вход MISO подаю единицу).

Читаю инигда 0xFE иногда 0xFF. Подключаю осциллограф к клоку и всегда читаю 0xFE.

Каким таким чудесным образом клок влияет на достоверность чтения? В форуме объяснили этот эффект тем, что клок с ножки используется для работы приемника SPI.

 

Но попробую добавить while (ANAS->SR & SPI_SR_BSY);

 

Вы привели код для передачи. У меня с этим проблем нет. Вот прием читает нестабильно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А у Вас что, на клоке вход и нет ни сигнала ни подтяжки? Почему подключение осциллографа влияет хоть на что-то?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А у Вас что, на клоке вход и нет ни сигнала ни подтяжки? Почему подключение осциллографа влияет хоть на что-то?

 

На клоке есть сигнал клок. Представьте мастер SPI у которого MISO жестко к единице подключен. Это мой тест. Если читаем, то только 0хFF, но никак не 0xFE.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...