SPI2 настроен мастером, режим приём-передача (одновременно).
В большинстве случаев на приёме младший бит в байте оказывается нулём, хотя изредка читается правильно.

Ещё используются SPI4 и SPI6, передача на всех трёх без вопросов, приём на 4-ом тоже без проблем, 2-й вот почему-то глючит.

Мнения?

полярность и фаза клока? и кто-что рулит чип селлектом?

Всё по нулям.


Софтварно.

Длинная линия, Ватсон!

"По нулям" - это "согласовано со слэйвом" или как?

Нет. Меня на такую фигню не купишь.



Да это всё не по делу.
Имеется сигнал MISO, который судя по осциллографу (да по и логике) передаёт сигнал 0х51 (к примеру), а принимается 0х50, вот и всё.

сигнал SCK то имеется на второй щуп, и полярность с фазой правильно на осцыле (а не по логике) выглядят?

Да, хорошо взглянуть бы на осциллограммы и в исходник программы.

Блин народ, вы меня удивляете.

А что, теоретически возможно так настроить SPI чтобы младший бит не принимался? :-))))))

запросто - например когда фронт стробирования данных по клокам идёт одновременно со сменной этих данных

Тогда будут ВСЕ биты нестабильны.

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

Ваще-то речь о приёме. Или вы имеете в виду, что поскоку приём это тоже передача (:-)) то вся эта фигня с проверкой BSY или TXE и здесь может нагадить?
Но ведь используется последняя либа от производителя....

Настройте SPI на прием/передачу большего числа разрядов, чем требуется. Тогда сможете сказать, влияет ли факт окончания посылки на принятые данные.

То есть баги там самые свежие? :-)

Да... Вот так надо делать (на имя ANAS не обращайте внимания, это SPI)

младший бит принимается последним.
Разные SPI по разному формируют завершающий клок и чип селект, добавив данные которые с линии могут пропасть когда им угодно, так что последний бит особенно уязвим.

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

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

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

Посмотрел как в либе сделано, там конечно 130 строк кода на убогую процедуру передачи :-)))
но вроде бы действительно проверяется сначала TXE, а перед выключением ещё и BSY, то есть всё нормально.

Кому хочецо осцыллограмму, получайте.

Что мы тут видим:: вторым байтом идёт 0х85, но в DR в итоге принимается 0x84.
Напоминаю, это вообще-то приём.

Может, неправильно задана частота периферийных шин микроконтроллера?

А чё там может быть?
SYSCLK 84
HCLK 84
APB1 42
APB2 84

Ещё пример. Первый байт принимается как 0х83!! Второй как 0х4Е!! :-о

А если порту, что такты выдает, добавить тока (частоты работы)? Или уменьшить?

Почему у вас одна осциллограмма с 1мкс/квадрат, а другая 10мкс/квадрат? Это один и тот же SPI? И неплохо бы видеть еще и SS.

Ну и на первой осциллограмме у вас что-то странное с уровнями на линии данных.

И, это... Peak Detect у вас включен в осциллографе? А BW Limit выключен? А с подключенным пробником лучше не становится?

В смысле скорость нарастания? Специально поставлена на минимум, чтобы звона и шума не было. Для эксперимента ставил на максимум - существенно ничего не меняется.


Потому что на разных скоростях пробовал. С НСС всё нормально.
Что не так с уровнями? Просто земля, куда щуп прицеплен, немного плавает.


Никаких фокусов и полтергейста нет. Вот гладенькие фронты, если чё.

Меньше 2V? А что так ма

Куда же больше?? В конце 21-ого века живём, как-никак. Питание 1.8.

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

2ViKo, f4 же работает и на 1.8В

Понятно. Там для разного питания разную латентность Flash нужно задать. Надо думать, у вас все правильно задано?

Стоит 5-ая. Это ещё с запасом. Только я вот думаю, она от частоты зависит (а частота ещё от напряжения ядра), а не от напряжения IO.

А то. Но вряд ли у вас напряжение ядра выше напряжения IO.
Может, в программу тех самых пресловутых барьеров насовать, чтобы не бежало впереди (паровоза) конвейера?
И errata sheet прочитали, и ничего не нашли?

при этом пересылается 0x82 и 0x4F как я вижу... такое чувство что последний бит не теряется а принимается инверсией. Нет у СТМ какого-то хитровыкрученного режима с какими нибудь подтверждениями ? типа 7 битной передачи с контролем четности в 8 бите?

ну это к примеру....

может там правда что схемно?
я видел как один раз из за кондеров без земли рс232 во время передачи потихоньку плыл вверх, и начинал передавать нормально а к концу передачи уплывал и лажал...


попробуйте послать 0xFF много раз
потом 0xAA, потом 0xEE, потом 0xCC, потом 0x88
все сереями и снимите осциллограммы и результаты приема...

Забил на этот СПИ и сделал путём дрыгания лапами, благо обмен редкий. Работает без каких-либо неожиданностей, причём скорость клока больше мегагерца.

Гадость какая-то этот ваш заливной STM32.. :-о :-о :-о

1МГц это потолок? Че-то мало...

PS. А как же докопаться до истины?)

Вот не про СТМ32, но похожая проблема - мучился с SPI, последний бит не принимался. Иногда.

http://electronix.ru/forum/index.php?showt...amp;hl=mrf24j40

Добавил резистор 120 Ом, помогло.

Не понятно, зачем резистор на линии данных. Звон недопустим на клоке, а на данных скока угодно. У меня впрочем его в любом случае нет..

Я не копенгаген в таких делах. Там по линии данных NC7SZ125P5X стояла, так как МРФка сама по себе не имеет 3 го состояния на выходе данных.

Может, питание проседает? Неспроста там на осциллограмме нуль скачет.


Как, уже у конце? Вот время летить...

Да фигня этафсё.... Просто земля щупа прицеплена не к плате, а ближе к БП, и на шлейфе напряжение падает.

то есть вы обнаружили стабильно повторяющуюся ошибку процессора, которая не описана в еррате? Надо срочно писать в поддержку...


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

Может, и так, а, вдруг, нет? Лучше бы посмотреть на ножке микроконтроллера относительно его же земляной ноги.
А если почитать DR два раза?

Собсно качество сигнала (на последней картинке например) я смотрел конечно не с крокодилом, прицепленным хрен знает куда, а с "иглой". Это когда крокодил вообще отцепляется от щупа, вместо него ставится насадка с иглой, и она втыкается в ближайшую к сигналу землю.
Диагноз вы видите на картинке:: качество сигнала без вопросов.

А ДР я даже в отладчике ИАРа вижу, разночтений нет.

Тогда... режимы поменяйте, те, что всё по нулям. И мк-то какой конкретно? И читаете что?
Есть "странный" битик Frame format...

ф439..

Я-то поменяю, а слэйв чё бует делать?

Вот и узнаем. Интересно же!

времянку надо проверять
все 3 сигнала
чипселект
клок
данные

Чё там интересно? Курить бамбук он бует. Так как рассчитан на CPOL = 0, CPHA = 0 :-о



НСС - программный выход, то есть на контроллер СПИ никак не влияет.
А клок и данные я показал.

Дык и стм был рассчитан. А поди ж ты :-)

Может, здесь найдете что-то полезное.
http://electronix.ru/forum/index.php?showtopic=107951

я так понимаю у вас мастер.
А слейв чипселект использует? Может так получиться что вы его снимаете программно слишком рано, и слейв бросает передавать?