Еще бы и программный ногодрыг не работал... Четыре провода проложены, как положено. Это хорошо. Но мало.
Заметьте, у adnega все каналы SPI работают! А вы ссылаетесь на форум каких-то... неучей...

Сейчас не получается воссоздать ошибку. Раньше точно помню, что замыкал MISO на 3.3В и получал 0xFE.
Допускаю:
1. тогда я где-то нокосячил;
2. сейчас использую простой проект (LTDC, SDRAM, SPIx), а тогда - куча SPI (кнопки и светодиоды на сдвиговых регистрах, цифровой микрофон, I2S-кодек),
таймеры (DS18B20, импульсы тестирования усилителей), UART (GSM, console), SDIO (uSD-карта), I2C (радио RDA5807). Все это густо разбавлено DMA.

Не будьте так высокомерны. Это форум поддержки ST.

И что с того? "Специалист" любого уровня может задать там тупейший вопрос. Как и здесь. Если не путаю, там был участник Cliv(не вспомню точный ник), вот он и утирал сопли направо и налево. Задайте и вы там вопрос. Гуглопереводчик-то доступен.
P.S. Нашел. clive1 он обзывается. Его ответам доверяю.

clive1 про чип селект что-то сказал, но когда я вывалил побольше информации, то он слинял. Он не сопли утирает, а работает в поддержке и отвечает на вопросы.
Мне гуглопереводчик не нужен. Я на аглицкой мове немного могу говорить

Ссылку на тему на ST выдайте, please!
"что-то сказал" слегка противоречит "переводчик не нужен"

Вы как следователь на допросе. Я просто уже не помню что он сказал. То, что я работаю в Канаде слегка противоречит вашим подозрениям обо мне и о переводчике.
Написал он банальность:

Ok, so as the -ChipSelect goes high the slave will tri-state its output. So a) make sure you keep -CS low until you have clocked in the last bit, and you are reading the slave output on the right edge of the clock
What SPI device is the slave?

Мой ответ:
Thank you for response.

First: CS starts going high one microsecond after the last clock transaction.
Second: In order to simplify the test I managed to neutralize the slave peripheral holding reset all the time. MISO output is a solid high and never changes. I read 0xFE instead of 0xFF. The same firmware operates with the same peripheral on SPI2. No problems observed. I got the same behavior on two different boards for SPI1 only. SPI2 connected to the same kind of slave (si3050 as dazy chain of 5) operates properly on both boards.

Коряво конечно, моя жена считает меня необучаемым языкам, но народ понимает что я имею ввиду.

Извиняюсь, что немного не в тему, но ситуация тоже с SPI. Сегодня выкопал баг:


Короче заметил девайс подвисает периодически. Начал дебажить - зависает в while(!(SPI2->SR&SPI_SR_RXNE));. Что в итоге происходит - пока ждем, возникает прерывание системного таймера. Он сам по себе устанавливает 1 флаг в 50 герц, по которому из главного цикла опрашивается акселерометр, это единственная его задача. После обработчика возвращаемся в цикл и больше никогда из него не выходим. То есть если в нем войти в обработчик, то бит RXNE не установится. Юзал бряк busy и через if(busy) в таймере понимал, что мы попали в прерывание во время цикла. В пошаговой отладке этот бит не устанавливается, хотя в ДШ четко сказано:

A read access to the SPIx_DR register must be managed by the RXNE event. This event is triggered when data is stored in RXFIFO and the threshold (defined by FRXTH bit) is reached. When RXNE is cleared, RXFIFO is considered to be empty.

Или по крайней мере этот бит очень быстро сбрасывается (не понятно почему)

Вам же надо...
SPI1 подключен к шине APB2, а SPI2 - к APB1.

Не флуда ради, а токмо просвещения для… какое соотношение между частотой ядра и частотой SCK, что все (ну практически все) в примерах с SPI в тупых циклах ожидают изменения флагов, а не используют \шёпотом\ прерывание?

Разобрался - до сих пор не могу в голову вдолбить, что регистру пофигу кто его читает - mcu или дебаггер. После чтения дебаггером регистра (а он читается автоматически при пошаговой отладке) RXNE сбрасывался и происходило бесконечное ожидание. Дописал timeout на всякий случай.



48МГц/93кГц.
Все что делает у меня прога это 50раз в сек читает датчик и выкидывает его на CAN шину. Даже заморачиваться не стал с прерываниями.

Вопросов больше не имею (;

наврал. 24/93

А всё равно. Кстати, если бы реализовывали на прерываниях, то отладчиком флаг не корёжили.

Я бы провел серию тестов.
Вот такую функцию (сами подставьте правильное выражение для статуса и вашего busy) поставить в разные места прерывания и найти в каком месте флаг меняется. Может каким неожиданным способом флаг читается. Ну там поинтер не туда указывает и т.д.. Когда найдете место, то под лупой рассмотрите его.


Тестировать так:
Поставили в одно место запустили. Если подвисло в ловушке, то убираем отсюда и ставим выше по коду если подвисло в ожидании флага, то ниже.