Obam

А что не так? 00101010b==0x2A старшим битом вперёд. Всё нормально.

Из описания (SLAU208M, Chapter 2, стр 99-101) не очень следует, что PMM должен вкдючать "…Backup Supply при выключении основного питания…". Или цитата подразумевает что-то иное? PS: отставить! стр 126 "The switch is controlled by the high-side SVS that supervises the primary supply, DVCC."

• 8- or 16-bit transfer frame format selection

SPI2->CR1 |= SPI_CR1_BIDIOE; //BIDIOE передача SPI2->DR = 0x8F; //Пишем в буфер передатчика SPI1. while(!(SPI2->SR & SPI_SR_TXE));// Ожидаем окончания передачи данных SPI2->CR1 |= SPI_CR1_BIDIOE; //BIDIOE передача for(uint32_t i=0; i<0x000FFFFF; i++); //Прием данных. SPI2->CR1 &= ~ SPI_CR1_BIDIOE; //BIDIOE прием while(!(SPI2->SR & SPI_SR_RXNE));//приняли данные bufPr1 = SPI2->DR;//Считываем данные из приемного буфера SPI1. При этой операции происходит очистка буфера и сброс флага RXNE SPI2->CR1 |= SPI_CR1_BIDIOE; //BIDIOE передача Ну откуда??? 8 синхроимпульсов от "SPI2->DR = 0x8F" и 8 синхроимпульсов от "SPI2->CR1 &= ~ SPI_CR1_BIDIOE"

Шутки шутками, но доку (DS на датчик и контроллер и RefMan на контроллер) - курить до просветления. Данные в датчик должны "вдуваться" старшим (MSB) битом вперёд: R\~Wбит это старший, AD5..AD0 - записаны от старшего к младшему => 10001111b. Зачем это преворачивать? "Так ведь чтобы что то передать это что то надо записать в DR, оттуда и считать что пришло, разве нет?" Так вы и писали в DR 0x8F при BIDIOE==1, а как этот байт был отправлен, то BIDIOE 1-->0 переключит SPI на приём и автоматически вычитает (R\~W==1 не забыли?) из датчика данные по только что переданному адресу, их вы увидите тоже в DR. И ещё: если не будет выполнено "This line is driven at the falling edge of SCL and should be captured at the rising edge of SCL." то не правильно будут тактироваться данные. CPOL, CPHA соответствуют требуемому?

А сообществу рассказать что да как…

Стоять!!!!! Назад!!!!! В DR 0xBC писать не надо. Это датчик во втором байте должен вернуть (т.е. процессор вычитать). Вот примерно так: По поводу плавного спада: надо разобраться с исходным уровнем и активным фронтом SCK.

DataRegister ;) "bufPr1 = SPI2->DR;//Считываем данные из приемного б…" 0xBC должен ответить датчик. Данные SPI-блоком в контроллере могут двигаться по переднему или по заднему фронту синхроимпульсов. Вот ответ датчика с правильным ID и будет признаком правильной настройки интерфейса. Наличие синхроимпульсов во время плавного спада данных не годится.

И из DR читается 0xFF? Повторяемость результата есть? Не нравится мне плавный спад: синхроимпульсы в это время есть? Кстати, фронты синхроимпульсов правильно выбраны?

Кроме того, если нет записи, по-вашему, 11110010b (0x4F наоборот) по какому адресу читался ID датчика? Что датчик отвечает? Осцилл. старый? Почему сигналограммы в paint?

Да ну? 0x4F как на картиночке будет расположено? Тут старая сказка "про белого бычка": бит 0 в байте данных и бит 0 при его передаче. :)

"…Мойша The Beatles напел…" :) Синхроимпульсы как расположены? 0x4F, положим, видно. Плавный спад - разряд входной емкости. Ответ должен быть 0xBC. 10101010 - на фига? Датчик же висит на шине - хрень какая-нибудь загонтся в него… Ё-моё! 0x4F! Маэстро, вы, не охренели? Запись в регистр для чтения?

Очень хорошо; что с данными?

Зациклить обмен с датчиком. Ждущая развертка, запуск от CS. На каждый цикл обмена (CS 1-->0 и 1-->0) должно быть 16 синхроимпульсов SCK, на первые 8 - ваши данные (0x4F), на вторые 8 - ответ датчика. Разворачивайте, смотрите.

Обратно от датчика что?

Здравствуйте :) Точно Spi переведён на приём? Copy-paste погубит мир :) А вообще, для подобных работ осциллограф наипервейшее средство. Есть? PS: Ох, ё-моё, а ведь переведён…

Архитектуру уточните. У cortex-m, к примеру, никак.

Этот документ SLAU144J? Главу 7, стр. 308-326? Не похоже. С 430-ыми надо работать, имея на руках datasheet на конкретный контроллер (там описаны конкретные особенности) и user's guide на семейство, к которому принадлежит ваш контроллер (там описаны все общие свойства).

Так грамотно написанный обработчик систему не вешает. :) NVIC_IPRx??? Прошу прощения, "обдёрнулся": конечно же NVIC_ISPRх. Что я имел в виду? Соответствующий флаг в NVIC_ISPRх у прерывания, активируемого уровнем, остаётся "1" и при активном состоянии прерывания. Его (флаг) надо не забыть снять в NVIC_IСPRх, но и причина вызова прерывания должна быть устранена. Тогда повторного (лишнего) входа в обработчик не будет.

Нет, пока ещё нет :) 256 Байт это так называемая Info память - у неё просто странички маленькие, а вообще, у вас памяти по контроллерным меркам, как "у дурака фантиков" (без обид - фигура речи). В любой свободной странице Flashа можно сохранять данные. Рекомендация - User'sGuide читать и заданный вопрос даже не возник бы.

В соответствующем регистре NVIC (NVIC_IPRx) обработчиками pending-флаги снимаются? Это случай, если прерывание по уровню…

Ну а преобразовать в бинарник, а потом в Hex какие проблемы? WinHex - про такую программу вообще никогда не слышали?

Joseph Yiu "The Definitive Guide to the ARM® Cortex-M3" и ещё одна - просветлению способствует Vincent Mahout "Assembly Language Programming ARM Cortex-M3"

Контроллер после сброса "взлетает" на внутреннем RC-генераторе 8 МГц (HSI). Мало того что HSI имеет время старта <2 мкс, так он уже и готов к этому моменту. Сконфигурировать выходы в нужное состояние (на 8 МГц)- считанные команды, неоткуда там браться 8 мс. TS, смотрите в результирующий код: точно ли настройка и установка GPIO выполняется с точки входа Reset_Handler?

Вся система тактирования начинается с мультиплксора выбирающего из HSI, HSE или PLLCLK.