Jump to content

    

stm32f407 SPI обнаружил косяк

55 минут назад, AHTOXA сказал:

Если вы не видите проблем, это не означает, что их нет.

На приведённых картинках проблем нет. 

Цитата

Существуют устройства, которые отменяют транзакцию, если CS снят до окончания нужного количества тактов SCLK.

Покажите где на приведённых картинках "CS снят до окончания нужного количества тактов SCLK"?

Цитата

Ну я и не ожидал, что вы поймёте. Умение читать  и понимать - это не ваше.

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

Share this post


Link to post
Share on other sites
47 минут назад, jcxz сказал:

Покажите где на приведённых картинках "CS снят до окончания нужного количества тактов SCLK"?

Хорошо, для особо одарённых я повторю картинку:

500KHz.png

Для альтернативно одарённых повторю: синий - CS, жёлтый - SCLK.

Вот вам картинка, как это должно быть (из технического описания микросхемы AT25640):

at25640_wr.gif

Опять не видите? Сочувствую. Но не удивлён.

Share this post


Link to post
Share on other sites

Поднять тактовую до положенных 5-10 МГц и ни одно прерывание не успеет CS поднять раньше чем надо.

Share this post


Link to post
Share on other sites
1 час назад, AHTOXA сказал:

Хорошо, для особо одарённых я повторю картинку:

500KHz.png

Для альтернативно одарённых повторю: синий - CS, жёлтый - SCLK.

Ещё раз: Судя по этой картинке выставление бита на шину происходит по спаду SCLK, захват бита с шины - по спаду SCLK. И никакого криминала в этой осциллограмме нет - CS можно снимать там где он снимается.

Вы понимаете написанное?

И я говорил конкретно о материале приведённом по вашей ссылке:  https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=107951&page=5&tab=comments#comment-1127161

а не о чём-то другом. 

Опять начали выкручиваться "как уж на скоровородке" приводя не относящиеся к делу картинки? Сперва ляпнуть что-то не по делу, а потом выкручиваться - это ваш стиль.

Share this post


Link to post
Share on other sites
3 часа назад, jcxz сказал:

Ещё раз: Судя по этой картинке выставление бита на шину происходит по спаду SCLK, захват бита с шины - по спаду SCLK. И никакого криминала в этой осциллограмме нет - CS можно снимать там где он снимается. 

Во-первых, CS на картинке снят ДО спада SCLK. Так что, вы, дружище, снова сели в лужу. Уже в который раз. Во-вторых, даже если подчинённое устройство захватывает данные по фронту SCLK, то проблемы всё ещё возможны. Потому что во-первых, устройство может не успеть захватить сигнал по фронту до спада CS (многие устройства гораздо медленнее, чем 168МГц STM-ка). А во-вторых, некоторые устройства требуют удерживать CS до последнего такта SCLK. И отменяют транзакцию, если снять CS хоть на полтакта раньше.

3 часа назад, jcxz сказал:

И я говорил конкретно о материале приведённом по вашей ссылке

Этот материал тоже есть по ссылке. Чуть ниже. Читать надо внимательнее.

3 часа назад, jcxz сказал:

Опять начали выкручиваться "как уж на скоровородке" приводя не относящиеся к делу картинки?

Что значит "не относящиеся к делу"? Две картинки, на одной - форма сигнала, которая получается, если управлять CS по RXNE, вторая - как требуется по спецификации устройства. Вторую картинку пришлось повторить, потому что некоторые особо одарённые товарищи не знают, как должно быть.

3 часа назад, jcxz сказал:

Сперва ляпнуть что-то не по делу, а потом выкручиваться - это ваш стиль. 

Не скромничайте, это как раз ваш стиль. Интересно, что теперь придумаете, как будете выкручиваться.

4 часа назад, VladislavS сказал:

Поднять тактовую до положенных 5-10 МГц и ни одно прерывание не успеет CS поднять раньше чем надо. 

Я ловил проблемы как раз на 10 МГц SPI. Там картинка была не столь явной, но CS снимался раньше, чем нужно. Правда, без прерываний, по опросу.

Share this post


Link to post
Share on other sites

О, так это всё та же тема тянется. Там я писал, проверяйте, что TXE сработал, затем, что BUSY завершился. И тогда снимайте CS. 

Share this post


Link to post
Share on other sites
5 minutes ago, ViKo said:

Там я писал, проверяйте, что TXE сработал, затем, что BUSY завершился. И тогда снимайте CS.

Так и делаю. Пока только для режима 0/0. Потом на отсальных проверю, если понадобится. Единственное, что меня смутило в периферии - отсутсвтие прерывания по BUSY. Не знаю, может быть превык к LPC где почти на каждый чих периферии есть прерывание.

Ну и не по теме: ну почему у DMA нет связных списков... рррр!

Share this post


Link to post
Share on other sites
2 hours ago, haker_fox said:

Ну и не по теме: ну почему у DMA нет связных списков... рррр!

Есть, у STM32H7 :)

Share this post


Link to post
Share on other sites
3 часа назад, ViKo сказал:

О, так это всё та же тема тянется. Там я писал, проверяйте, что TXE сработал, затем, что BUSY завершился. И тогда снимайте CS. 

А я вам тогда с картинками описал, почему это опасно. Но, как видно, не убедил.

Share this post


Link to post
Share on other sites
18 hours ago, jcxz said:

Судя по этой картинке выставление бита на шину происходит по спаду SCLK, захват бита с шины - по спаду SCLK. И никакого криминала в этой осциллограмме нет - CS можно снимать там где он снимается.

SPI так же считает, раз данные по спаду SCLK захвачены, значит можно этот момент считать окончанием передачи и сбрасывать BSY, но некоторые устройства при таком подходе реально не работают. Например, SPI дисплеи(ST7735) у меня отказываются запускатся если делитель для SPI 64 и больше, но они работают если добавить задержку перед поднятием NSS, тогда оно происходит не в середине последнего периода.

Edited by Reflector

Share this post


Link to post
Share on other sites
16 минут назад, AHTOXA сказал:

А я вам тогда с картинками описал, почему это опасно. Но, как видно, не убедил.

Так, как я описал, у меня работает во всех проектах (немногих), что с памятью, что с ЦАПами, с регистрами. Вообще не помню проблем с SPI.
Пока нет доказательств обратного, доверяю своим решениям.
 

Share this post


Link to post
Share on other sites
21 минуту назад, ViKo сказал:

Пока нет доказательств обратного, доверяю своим решениям.

А осциллограммы не считаются доказательствами? :-)

Share this post


Link to post
Share on other sites
40 минут назад, AHTOXA сказал:

А осциллограммы не считаются доказательствами? :-)

Помню и осциллограммы, и споры. И свои осциллограммы там же демонстрировал. И в даташите на пару тактов задержку припоминаю смутно.
Если вдруг что-то перестанет работать, вернусь к теме. А пока нет возможности эксгумировать...

Share this post


Link to post
Share on other sites

ИМХО, @AHTOXA дело говорит.

Прецедент пойман? Пойман. Условия есть на картинках - желающие могут повторить.

Я не удивлен такому поведению SPI-флагов из-за, в целом, неудачной реализации модуля SPI в МК STM32.

У меня пока что тоже во всех проектах CS рулится по RXNE, BSY вообще не понял, зачем нужен, да и не сильно было интересно.

Потом же проще будет искать баг в работе с капризной микросхемой, принимая во внимание результаты проведенного эксперимента.

 

Другое дело - должен ли так себя вести RXNE? Наверное, нет. Но это вопрос уже к индусам (или кто там эти МК делает?).

Share this post


Link to post
Share on other sites

У меня вот какой опыт, из записей своих извлёк. И в теме я то же писал.
 


/*
  SPI устройстве M25PE40, MCU STM32F207. Код следующий. Конец Chip Select
  перенес до последнего чтения из DR. Первая закомментированная строка
  (проверка TXE) никогда не используется, осталась от прошлого.
  А использовалась проверка RXNE или проверка BSY. Скорость тоже выбиралась
  из двух вариантов: самая медленная (60 MHz / 256) и максимально допустимая
  (60 MHz / 4 = 15 MHz).
  */
uint32_t SFMID_read(void) {
  SMSS_ON();
  uint32_t id = 0;
  SPI1->DR = SFM_RDID;		// послать команду "RDID"
  while (!(SPI1->SR & SPI_SR_TXE)); // ждать освобождение передатчика
  SPI1->DR = SFM_DUMMY;		// послать пустой байт
  while (!(SPI1->SR & SPI_SR_RXNE));	// ждать байт в приемнике
  id = SPI1->DR;	    // High Impedance
  while (!(SPI1->SR & SPI_SR_TXE)); // ждать освобождение передатчика
  SPI1->DR = SFM_DUMMY;		// послать пустой байт
  while (!(SPI1->SR & SPI_SR_RXNE));	// ждать байт в приемнике
  id = SPI1->DR << 16;		// Manufacturer
  while (!(SPI1->SR & SPI_SR_TXE)); // ждать освобождение передатчика
  SPI1->DR = SFM_DUMMY;		// послать пустой байт
  while (!(SPI1->SR & SPI_SR_RXNE));	// ждать байт в приемнике
  id |= SPI1->DR << 8;		// Memory type
  // while (!(SPI1->SR & SPI_SR_TXE));	// ждать освобождение передатчика
  // while (!(SPI1->SR & SPI_SR_RXNE)); // ждать байт в приемнике
  while (SPI1->SR & SPI_SR_BSY);    // ждать, если SPI занят
  SMSS_OFF();
  id |= SPI1->DR;	    // Memory capacity
  // while (SPI1->SR & SPI_SR_BSY); // ждать, если SPI занят
//  SMSS_OFF();
  // Test = id;
  return id;
}

/* Посылаю в длинный последовательный регистр (или в ЦАП) последовательность из
   нескольких байтов. Читать ничего не читаю (не нужно, нечего). Так вот в таком
   случае определять завершение передачи способом */

  while (!(SPI3->SR & SPI_SR_RXNE));	// ждать конец передачи - так нельзя!

/* не годится! Потому что флаг RXNE установится после первой же пересылки байта.
   И не сбросится, пока не прочитаешь регистр данных DR.
   Так как мне не нужно было читать из SPI, то конец передачи обнаруживался
   "досрочно", при первой же проверке SR & SPI_SR_RXNE.
   В этом случае правильное решение - проверять BSY. */

  while (!(SPI3->SR & SPI_SR_TXE));    // ждать освобождение буфера передатчика
  while (SPI3->SR & SPI_SR_BSY);    // ждать освобождение приемопередатчика

/* Поскольку пересылка байтов может быть прервана в середине, то BSY тоже может
   иметь "разрыв". Спасает ожидание освобождения буфера передатчика перед
   проверкой BSY, что гарантирует, что началась пересылка последнего байта,
   и приемопередатчик занят. */

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now