Вуйко

А что за МК? У некотрых STM USART умеет определять заданный символ в потоке. И вызывать прерывание по этому событию. Вот в прерывании и можно DMA остановить.

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

А код проверки вообще правильный? Выкладывай сюда.

Брак встречаться может, но его вероятность не такая уж высокая. Последовательность проверки должна быть следующая: 1. Включить тактирование порта. 2. Настроить определенный вывод на push-pull выход. 3. Установить его в высокий/низкий уровень и проверить сигнал выводе. Можно ничего не настраивать, а просто мультиметром замерить напряжение на определенном выводе. По умолчанию все выводы, кроме некоторых, настроены в режим плавающего входа. Напряжение на них будет в диапазоне 0,5-1,5 В.

А как определялась неработоспособность?

Как в любом другом STM. Включить тактирование GPIO порта. Настроить требуемый вывод. Включать / выключать лампочку.

У STM32F030R8T6 нет бита разрешения тактирования альтернативных функций.

USB устройство на шине обнаруживается по появлению подтяжки линии D+ на +3,3В. Что бы после перезагрузки не нужно было вручную отключать/подключать устройство, тем самым имитируя включение/отключение подтяжки, нужно этой подтяжкой управлять програмно. Тоесть просто добавить транзистор. Устройство отключено - транзистор закрыт, подтяжки нет, ничего не опознается. Нужно подключится - открываем транзистор, линия D+ подключается к +3,3В через резистор. Сопротивление резистора - 1,5 к.

Это не пропуск запроса от АЦП. Это приход лишних запросов. Стоит очень внимательно проанализировать все возможные пути запуска преобразования у АЦП. И весь код работы с таймерами №2 и №4, если они используются. Ноги у проблемы отсюда растут. Где-то лишние запуски генерируются. Ну и судя по этой строке ADC1->CR2 |= ADC_CR2_EXTTRIG; //ADC_CR2_SWSTART; АЦП должно начинать новое преобразование сразу же по окончанию предыдущего. Только вот настройки EXTSEL битов на работу с SWSTART событием я в коде не вижу.

void SPI_RW() { while(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_IT_RXNE) == RESET); return SPI_I2S_ReceiveData(SPI1); } Функция возвращает void, но return не пустой. void должен быть заменен на тип идентичный возвращаемому функцией SPI_I2S_ReceiveData(SPI1). Иначе в буффер данных будет записан мусор. uint8_t RX_LEN = 32; uint8_t RX_BUF[RX_LEN] = {0}; Инициализация массивов переменной длинны вообще стандартом языка С запрещена. Добавление const тут не поможет. RX_LEN должен быть задан через #define. Все эти ошибки компилятор прекрасно отлавливает. Ну и править код прямо в первом посте непринято. Да еще и снова на неправильный.

А этот код даже работал? Его компилятор не пропустит. Для начала убрать явные ошибки вроде: void SPI_RW() { while(SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_IT_RXNE) == RESET); return SPI_I2S_ReceiveData(SPI1); } Или: uint8_t RX_LEN = 32; uint8_t RX_BUF[RX_LEN] = {0}; Потом выкинуть StdPeripheralLibrary и переписать код на регистрах, или на HAL, в крайнем случае. Ну и разобраться как должны быть настроены GPIO для работы SPI.

А есть полный проект в котором это странное поведение наблюдается? Ради интереса у себя попробую воспроизвести.

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

И что там по адресам? Записанные данные есть? Переменная FLASH_BASE правильно задана? Если данных нет, то только по шагам смотреть что в функции записи происходит отладчиком.

Приведенный код нормально пишет в память. Значения после подключения/отключения питания в памяти сохраняются. Советую искать ошибку в алгоритме отладки. Проверить правильность записи можно и без дополнительных усилий. После записи и повторного подключения питания нужно просто подключится к МК с помощью ST-Link Utility и его средствами посмотреть что там по заданному адресу в памяти записалось.