ну тогда только что есть какое то прерывание, которое непонятно как все ставит раком. Потому что я так понимаю данные попавшие в регистр DR должны выдавиться полюбому, а мы видим что они не выдавливаются...


а если в том месте где вы ставите брекпоинт поставить for(volatile int i=0;i<32000;i++) __NOP();
ну вообщем любую тупую задержку, да на побольше, чтобы секунда прям вышла... несколько раз цикл воткните... хотя отправки по уарту уже сделали эту задержку...

А воткните циклы выдачи на уарт значения SR после строчки
SPI2->DR = Data; ну так для полноты картины...


думаю что уже все проверили, может чип какой то подгоревший? Фиг же его знает, если бы SPI так странно не работал это бы все заметили...

Есть у меня последняя идея.

Может там какая просадка или помеха по питанию при попытке отправки по SPI, которая реально вешает проц... Циклы выдачи после DR=d0; Должны помочь понять. Если вы ставите брек поинт или медленно идете тока хватает, а если программа быстро летит, что-то проседает и кирдык?

ладно, мне кажется я частичто решил проблему.
Сейчас работаю БЕЗ дебаггера, компилирую заливаю на чип включаю плату (хотя в дебаггере поведение такоеже)

вот фрагмент кода №1, как уже знаете просто цикл проверки и отправка байта.



А вот фрагмент кода №2


Этот код просто бесконечный цикл, пока с USART3 не будет получена команда 01, как только эта команда получена цикл прерывается, и исполнение программы переходит к фрагменту кода №1

Так вот, компилю, заливаю на флеш.
Затем включаю плату, естесственно ничег не происходит т.к. цикл фрагмента кода №2 работает, затем подаю команду 01 с USART3 и немедленно вижу свой байт на осциллографе!


Вобщемто заработало на чипе и без дебаггера с брейк поинтами... но просто интерестно, в чем же была проблема?

Выходит проблема была в том что когда я подаю питание на плату (и на чип естесственно) то толи порт вывода толи SPI2 периферия еще не успела войти в рабочий режим необходимый для отправки данных?
Или чтото вроде того?
Что думаете?

думаю стоит ли у вас микросхема рессета проца?

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

да было иначе периферия не работала бы вообще.

Вот еще один интересный тест сделал(как вы говорили проверил также статус после записи), вот код (в этот раз убрал бесконечный цикл в начале):




И вот некоторые наблюдения:

1) Когда я скомпилировал и зашил контроллер, то я не только не увиден на осциллографе свой байт, но я еще и не увидел байты полученные от USART3!! Интерестно нет?

2) Затем перед кодом который показан выше я добавляю фрагмент кода №2из моего предыдущего поста(непрерывный цикл с ожиданием команды от USART3), комилю, заливаю, включаю..естесственно ничего пока не происходит т.к. нет команды от USART3 на прерывание цикла, подаю команду на прерывание цикла, И вижу свой отправленныйбайт на осциллографе!
А также вижу уже 4 полученных байта, и вот они:
00 02 до посылки
00 03 после посылки!

Как видите интерестно то что после посылки не только TXE=1 но и RXNE=1 что говорит о том что приемник полный.. (хотя странно ничего я не принимаю..)


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

Если есть какие то еще идеи интерестно было бы узнать





стоит просто ресет кнопка на плате, сбрасывание не помогало ничем

а как SPI должен отличить есть что-то на входе или нет? Входная нога в каком то состоянии, клоки тикают, значит через 8-9 клоков входной регистр наберет значение. В примере кода что вам давали выше, была проверка не только на отправку, ну и на прием, а перед отправкой байта всегда еще происходил забор пришедшего.

Такова суть СПИ, как включили клок генератор, так байт не только отправиться но и примется...

Кстати вот интересный момент, а где вы включаете клок генератор? Он в STM автоматом что ли включается по записи байта в DR?

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

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

Читать даташит до просветления... в части тактирования ядра, тактирования SPI и работы самого SPI...
Исходите из того, что транзакция начинается не сразу после загрузки DR... следовательно... и изменение TXE происходит не сразу...

Сообщение отредактировал HHIMERA - Apr 22 2013, 03:49

я вот поглядел даташит(как и реф мануал) и не увидел там упоминания о том что SPI может вообще не запуститься... А тем более упоминания о паузе перед посылкой которая влияет на его работоспособность. Также не нашел никаких битиков говорящих о неработоспособности или о том что еще не вышло время подготовки SPI.

Я просмотрел секцию бутлода из даташита и опять же не увидел упоминания о том что в начале какие то клоки не работают.

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

Его я включаю перед тем как начать работать с СПИ. Вот так:




тоже самое делал и я после тех двух описанных мною тестов в посте №34 и №32.

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






а это не важно, т.к. я отправляю первый байт, и ТХЕ уже заведомо имеет значение 1.
Об этом я тоже писал, Вы видимо не прочли ветку и поспешили дать банальный совет.

HHIMERA выразился не точно. TXE выставляется сразу после загрузки данных в регистр. Пересылка (сдвиг) наружу начинается позже, через 2 такта шины. Тогда же устанавливается флаг BSY.
Кстати, за эти два такта периферийной шины процессор успевает наделать много чего.
BlackOps, поставьте задержку вместо точки останова.

Как прочитали - так и работает... увы...


Угу...
Ещё раз... разногласия/разночтения по SPI присутствуют только в F0 и F3...

вы написали уже 2 сообщения, но так и не дали ответа. Меня СПИ в этом проце не интересует я другим занимаюсь, потому не копал. Наблюдаю действия человека который с ним мучается, противоречий не вижу, потому заинтригован.

Если же у вас есть что по сути посвятите нас темных... [DELETED]

Сообщение отредактировал IgorKossak - Apr 22 2013, 11:16

[DELETED]

Сообщение отредактировал IgorKossak - Apr 22 2013, 11:18

Где-то есть упоминание (для F4), что между установкой битика включения тактирования блока и работы с блоком должно пройти какое-то время. У меня так FSMC не заработал)
Попробую найти это в доках...

UPD: STM32F405/407xx and STM32F415/417xx device limitations
2.1.12 Delay after an RCC peripheral clock enabling
Description
A delay between an RCC peripheral clock enable and the effective peripheral enabling
should be taken into account in order to manage the peripheral read/write to registers.
This delay depends on the peripheral’s mapping:
● If the peripheral is mapped on AHB: the delay should be equal to 2 AHB cycles.
● If the peripheral is mapped on APB: the delay should be equal to 1 + (AHB/APB
prescaler) cycles.
Workarounds
1. Use the DSB instruction to stall the Cortex-M CPU pipeline until the instruction is
completed.
2. Insert ”n” NOPs between the RCC enable bit write and the peripheral register writes
(n = 2 for AHB peripherals, n = 1 + AHB/APB prescaler in case of APB peripherals).

Наконец-то увидел инициализацию.
Зачем SSI и SSM одновременно ставить? В моём (работающем) варианте только SSM стоит (на что я и обращал внимание).
А как следствие - отказ SPI работать, когда кто-то другой держит сигнал SS.

[DELETED]


ну да, наверное правильнее было сразу попросить и инициализацию...

Сообщение отредактировал IgorKossak - Apr 22 2013, 11:17