Привет.
Контроллер STM32f429zi.
Столкнулся с такой проблемой, запускаешь программу из отладчика все работает (в частности USB), когда передергиваешь питание микроконтроллера программа начинает выполнится некорректно (отваливается USB).
Если запустить контроллер из отладчика IAR и сразу выключить отладчик (шнурок программатора-отладчика выдергиваю) не трогая питание STM32, то все нормально программа выполняется корректно.
Но если передернуть питание то опять все отвалилось.

Как можно найти причину этого?

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

Или еще может быть у Вас таблица прерываний (0 элемент - начальный адрес стека, 1 - точка входа) не в том месте расположены!

Куда грузится программа: ОЗУ или FLASH?

Не много не понял вопрос.
Но я загружаю программу во FLASH. Если вы говорите про BOOT0, то BOOT0 у меня на земле.

Создайте пустой новый проект в любимой среде, который, например, тупо моргает какой-нить лампочкой на плате.
Этот проект должен запускаться без отладчика. Если не удается этого добиться, то проблема где-то в железе или настройках среды.
Если удается, то постепенно добавляйте в этот проект исходники и вашего глючного проекта.
Цель - найти то место в ваших кодах, которые приводят к описанной проблеме.

зы. Подобный принцип поиска косяков годится для любой отрасли деятельности

Симптомы указывают на неправильное положение таблицы векторов. Надо смотреть что там в файле .icf

Есть еще один интересный момент, который меня вгоняет в ступор.
А именно, зашиваю эту же прошивку с помощью STM32 ST-LINK Utility в другой микроконтроллер и там такой проблемы нет. Беру еще один мк. там снова такая проблема беру другой ее нет.

В общем из 100 мк. 10 шт. ведут себя вот так не понятно.

Любая прошивка себя так ведет на этих МК, или только ваша?
Схемотехника плат в норме? Среди этих 100 плат эти 10 вообще рабочие (все компоненты правильные)?

В такой ситуации может быть масса причин и выяснить это можно лишь локализовав причину, хотя бы грубо: железо или софт.
Выше я описал как это можно сделать, не гадая на "кофейной гуще" и т. п. мифических предположениях.

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

Еще вариант, который у себя наблюдал - медленно заводится внешний кварц, нужна была задержка.

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

у меня так и сделано.
Плюс у меня стоит внешней генератор на 16 МГц. На нем генерация в норме.
Заметил вот еще что.
Беру не рабочей мк. ставлю уровень оптимизации в IAR low вижу не работает мк. ставлю для этого же мк. уровень оптимизации high, size работает.
Но думаю надо поставить везде high и будит счастье.
А нет беру второй мк. а для него подходит уже low.
Чета ваще не чего не понятно.

Тут есть два варианта:
1) переписать нормально код, изучая соотв. литературу и мануалы
2) воспользоваться бубном

Нажмите для просмотра прикрепленного файла

Если USB из Куба, то мне приходилось размер кучи увеличивать. А еще SysTick таймер программировать. Как оно у них работает, хрен поймешь.

Мне приходят в голову следующие вещи, из моего опыта.
Первая: при работе отладчика им запускается DWT счетчик. Если в коде он используется для отсчета каких-либо задержек (почему и как именно - писано на форуме много), а код забывает его проинициализировать, то под отладчиком (или после вываливания из отладки) будет все работать, т.к. DWT тикает, но при запуске после сброса - нет.
Вторая: отладчик стартует медленно; за это время может успеть пройти инициализация периферии, которая не успевает при холодном старте без отладчика. У меня это было что-то тактируемое медленными генераторами (RTC) и, кажется, I2C, не помню точно.

В общем и целом опыт мой подсказывает, что чудес не бывает . Если что-то ведет себя непредсказуемо и странно, за этим стоит вполне конкретная причина. Ищите!

Скорость нарастания питающего напряжения у работающих и не работающих плат одинакова?

Или как-то некорректно ожидается "раскочегаривание" кварцев, PLL...

Путем отключения и включения разных инициализации периферии, было установлено что проблемы возникают из-за I2C.
Но как влияет в моем случаи I2C мне не ясно.

Попробуйте для начала отключить вообще все узлы на этой шине.
Если возможно, то покажите схему девайса.

Нашел в исходниках "чудесные" строчки (это обработчик прерывания I2C)

Без дикого while(I2C2->SR1 !=0 ) ничего не работало (вроде, I2C переставал функционировать и никак его из этого ступора было не вытащить).
Долго возился, но в итоге переделал все на ногодрыг.

Странно, у меня прекрасно работает как раз на F429 аппаратный I2C (да ещё с DMA) с кучкой висящих на нём разных устройств (FRAM + RTC + FM-тюнер + touch-контроллер) на 400кГц.
По многу часов без каких-либо сбоев.
И никаких ногодрыгов и тем более - циклов в ISR.
Так что у автора явно не МК виноват, а кривые руки.

+ на плате, которая глючная, поменять кварц или генератор. Возможно дело в конкретном экземпляре.

+ Поотключать блоки кода или функции.
+ Если (вдруг) в коде проекта есть таймауты - подвигать их длительность.

Для этого проекта применялся STM32F103RET6.


Масштаб "часы" это очень мало. В проекте использовался дисплей TIC154(A) на I2C для постоянной индикации.
А сбои вы как-то разруливали? Бывает, slave выдает ACK на линию, а мастеру хочется START устроить, но у него ничего не получится.
Тут ногодрыгом нужно slave протолкнуть до 1 на SDA. Я умышленно создавал помехи в линии, чтобы система смогла их обработать.


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

Приведенный кусок - это ситуация когда сразу за STOP от предыдущей посылки формируется START для следующей.

У автора как раз F429, а не F103. А у них как я слышал - I2C сильно отличаются.


Не понял - что значит "slave выдает ACK на линию"? ACK слэйв выдаёт только для подтверждения приёма данных. Мастер в это время никак не может СТАРТ выдавать, он ACK или не-ACK должен ждать.
И не понимаю - зачем тут ногодрыг?


Помех по I2C у меня в том устройстве очень много. По питанию (и возможно по эфиру) от работающего рядом ESP8266. И я долго с ними боролся. Даже сюда писал. Но теперь всё работает стабильно.



Приведённый код - часть ISR-а драйвера I2C, работающего по флагам в регистрах I2C и машине состояний (isrStep).
Если для устройства нужна I2C-транзакция с рестартом или повторным стартом (дуплексная транзакция), то перед запуском транзакции I2C в option драйвер устанавливает соответствующий флаг или OPTION_DUPLEX_SS (для переключения вывод->ввод выполнить на шине СТОП-СТАРТ) или OPTION_DUPLEX_RS (для переключения вывод->ввод выполнить на шине ПОВТОРНЫЙ СТАРТ). Что именно нужно OPTION_DUPLEX_SS или OPTION_DUPLEX_RS - выясняется из даташита на слэйв.
Так что как видно - обхожусь без циклов в ISR и без ногодрыга.

Мастер выдал на SCL такт, но в результате помехи slave его не принял, а поскольку slave до этого выдавал ACK уровня "0",
то получается, что мастер уже такт для ACK выдал и считает транзакцию законченной, а slave ждет такта для проталкивания ACK.
Если не понятно, что это редко, но возможно, и без ногодрыга это не решить, то пусть это останется вне рамок обсуждения данной темы.


Проблема не с повторным стартом (который нужен, например, при чтении), а в идущих друг за другом обычных write-транзакций.
Попробуйте нарисовать STOP и START с нулевой паузой между ними. У меня получается лишь "1"-иголка на SDA.

При таких ошибках, драйвер выявляет ошибку на шине и уходит в fault(). Т.е. - рестарт устройства. При желании можно не всё устройство перезапускать, а только I2C-драйвер.
А старт драйвера I2C у меня начинается с 15-кратного выполнения операций СТАРТ и СТОП на шине. Ногодрыгом. Что выведет любого слэйва из непонятного состояния.


А я Вам ещё раз повторяю: у меня при выполнении STOP и последующем START (опция OPTION_DUPLEX_SS) в приведённом выше драйвере, на шине наблюдаются нормальные условия СТОП и СТАРТ. А не иголка. Т.е. - I2C-контроллер сам отрабатывает необходимую времянку.
И из указанного списка устройств на шине, для TUNER_ADDR_... используется OPTION_DUPLEX_SS, а для остальных - OPTION_DUPLEX_RS.

Я тоже ничего не понял про ACK во время START... Вообще таких вещей протокол не предусматривает. Есть четкая последовательность выдачи сигналов на линии. Да, бывают сбои по различным причинам - от мощных переключателей вне устройства, например, происходит рассинхронизация приемника и передатчика путем вставки "лишнего" clock-а.

Я, например, всегда придерживаюсь стратегии следующего рода: если процессор очень шустрый, периферия медленная, но есть DMA - я всегда работаю с DMA.
I2C в STM32F429 также поднимал с обработкой всех ошибок. Я делал так:

При отправке я сначала смотрю, а не занят ли модуль I2C прошлой транзакцией. Чтобы вечно не тупить в цикле ожидания BUSY, покрываю проверку аппаратным таймером на максимальную длину посылки через DMA. Если занят - говорю что вышел таймаут ожидания и выхожу из функции. Чуть позже добавлю сюда просто ожидание семафора, чтобы освободить задачу (эта функция крутится в составе ОСРВ).
После того как I2C освободился, заполняю служебные переменные размера передаваемого сообщения, настраиваю DMA, но не включаю его. Формирую условие START и запускаю контролирующий таймер на минимальный интервал передачи одного байта. Теперь выхожу из функции - вся остальная работа будет сделана в прерывании.

В прерывании обрабатываются все события I2C в зависимости от приема или передачи, при этом каждый шаг контролируется защитным временным интервалом в зависимости от количества передаваемых данных.
Таким образом, все сошлось к следующему:
1. Настроить DMA.
2. Выдать на линию START-условие.
3. Ждать в прерывании установки события START (SB).
4. Запустить передать физический адрес устройства.
5. Ждать в прерывании установки события окончания передачи адреса (ADDR).
6. Запустить DMA.
7. Ожидать в прерывании установки события BTF.
8. Выдать на линию STOP-условие.

На почти каждый шаг накладывается штрафной таймер, контролирующий выполнение текущего шага.

Этот код работает очень долго и стабильно. Обработка ошибок возложена на вышестоящие функции, как видно, в системный журнал ошибок (структура System) постоянно сваливаются нужные флаги.

I2C в STM - полное барахло и недоделка, ваш код только подтверждает это. Я внимательно смотрел его на 207 - там автомат сделан принципиально неправильно, он влипает в ситуации из которых выйти не может и без полного сброса его оттуда не вывести. Именно поэтому каждую операцию приходится окучивать таймаутами, что является полным безобразием.

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

В указанном устройстве у меня есть арбитр шины I2C. Он и управляет всеми транзакциями на шине. Это процесс, который ждёт появления флагов запросов от клиентов о выполнении очередной транзакции с одним из устройств на шине. Каждый клиент, когда хочет выполнить транзакцию с одним из I2C-устройств, формирует запрос об этой транзакции, помещает его в один из слотов запросов (свободный слот), выставляет флаг наличия запроса в слоте, пингует I2C-арбитра и становится на ожидание события завершения транзакции. I2C-арбитр, когда освобождается после завершения очередной транзакции, просматривает флаги активных запросов в слотах и выбирает наиболее приоритетный из них и запускает выполнение данной транзакции (программирует периферию I2C, DMA, выполняет последовательность шагов машины состояний в ISR и т.п.). По завершении транзакции, он заносит в слот информацию о результате транзакции (ОК или ошибка или ...), переводит событие готовности слота в сигнальное состояние (клиент выходит из состояния ожидания события) и выбирает следующий слот, ждущий обслуживания. Если такового нет сейчас - уходит в IDLE.
Так что всеми транзакциями на шине и всей периферией, связанной с данным портом I2C, у меня управляет один процесс - I2C-арбитр. Клиенты, запрашивающие операции обмена с I2C-слэйвами, работают только через его API. Они изолированы от железа.


Ничего не могу сказать про 207, но на F429 у меня транзакции по I2C не "окучены" ни какими таймаутами.
Единственный таймаут, который отслеживается в коде моего I2C-драйвера - это когда при инициализации драйвера я выполняю многократно СТОП-условие по шине и контролирую наличие залипания линии SCL в низком состоянии слишком долгое время.

Однако я тогда не совсем понимаю, какая у Вас гарантия того, что данные успешно передадутся, да еще в нужное время. Если в Вашем устройства (на макете) замкнуть SCL на SDA пинцетом, затем убрать - связь восстановится? Если восстановится - то не понимаю, какая магия у Вас мониторит, что нужные флажки не взвелись через определенное время и сбрасывает автомат.
Ведь идеологически любая конструкция

должна сопрягаться с установкой таймаута ожидания (не важно, средствами ОС или же аппаратным таймером).
Ведь слова

ставят встречный вопрос - каким же образом можно узнать результат транзакции? Ведь после установки битов управления (тот же START-бит), нужно некоторое время, чтобы в регистре статуса этот бит был выставлен и сгенерировалось прерывание. Если, как было указано выше, бесконечно ожидать, то получится полная лажа при какой-либо помехе на I2C-шине. Таймаут-то по-любому нужен, как без него...

А зачем их замыкать? Вы своё ПО пишете с таким расчётом, что кто-то вскроет корпус и замкнёт дорожки?


Что значит "бесконечно"? Вы же сами пишете: "выставится в регистре бит статуса". Вот тогда ожидание и закончится.
И судя по битам статуса (насколько помню), там не может быть такой ситуации чтобы никакой бит не выставился (манипуляции с пинцетом конечно исключаем), а следовательно - бесконечного ожидания не может быть.


"при какой-либо помехе" в регистре статуса появится "какой-либо бит" и сгенерится прерывание.

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

Не знаю как у кого, а у меня на I2C максимум дисплей висит. Поскольку скорости большие не нужны, а интерфейс синхроннее некуда -
делаешь тупой ногодрыг в районе mainloop'а и не паришься за прерывания, while(condition), таймауты и т.п.
После любых случайных пинцетов изделие рано или поздно прокашляется без лишних арбитров, журналов, алгоритмов сброса.

PS. Не пора ли часть сообщений вынести в отдельную ветку по I2C, ибо к данной теме I2C мало относится?

Как же изделию разрулить такую ситуацию, когда некто влазит в него и начинает тыкать разными металлическими штуками куда ни попадя?


Да ладно Вам - тут каждая первая вторая тема такая: пара постов по теме, а потом - кто в лес кто по дрова....

В плане I2C я предлагаю ногодрыг - простейшее решение, которое не завесит шину в принципе.
Я бы не встревал, если бы лет 10 назад не столкнулся однократно с ситуацией ACK от слейва и START от мастера.
Долго ломал голову и убеждал себя, что это в нормальной жизни не повториться, но редчайшее событие, напрочь завешивающее обмен не давало покоя.
Кста, тогда это была микросхема памяти серии 24xx. С тех пор у меня настороженное отношение к I2C.

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

USB cdc.
До меня не доходит из-за чего вылазит ошибка Error setting parameters from DCB при подключение к COM port tolkit ?

Видимо это нанесло психологическую травму, которая не заживает уже 10 лет
Шутка.
Вас очень трудно понять, так как Вы не придерживаетесь стандартной терминологии I2C. О чём тут уже говорили.
Как именно может "завесить обмен" обычный СТАРТ или ACK - я думаю тут не только я, но никто не понял....

Если slave в ACK, а master хочет сгенерировать START, то как он это может сделать?
Как система оказалась в этом состоянии - совершенно другой вопрос (кто-то проворный тыкал пинцетом).

ACK или не-ACK - это состояние на шине i2c. Именно состояние шины, а не состояние линии SDA.
А состояния i2c определяются не только по состоянию линий SDA/SCL, а и по фазе работы мастера.
Т.е. - если мастер выдаёт СТАРТ, то на шине в принципе не может быть АСК, просто по определению.
Если при выполнении мастером СТАРТ на SDA держится "0", удерживаемый слэйвом, то это не АСК, это коллизия на шине, которая трактуется как одновременный доступ двух i2c-мастеров к шине. Для отслеживания этого есть соответствующий бит в регистре статуса i2c. И никакие ногодрыги или таймауты для обнаружения этой ситуации в F429 не нужны - всё нормально работает и обнаруживается. Надо внимательно читать доки.
А если уже ваше ПО трактует "0" на шине во время СТАРТ как АСК, то тут проблема только в Вашем ПО.

И что мастер может сделать в случае такой "коллизии"?

Если она вызвана помехой или внезапным перезапуском МК мастера (машина состояния I2C слэйва осталась в режиме вывода бита АСК или бита данных), то я ещё в сообщении https://electronix.ru/forum/index.php?showt...t&p=1555322 писал что я делаю. С поправкой: я выполняю 15 раз условие СТОП. СТАРТ не надо.
Такая операция на I2C при старте ПО у меня делается всегда, а не только при SDA=='0', ведь в слэйве машина состояний может из-за помехи оказаться в ошибочном состоянии вывода например очередного бита данных =='1' и вроде на SDA всё ок, но когда пойдут SCLK будет капец.
А если коллизия из-за наличия другого мастера на I2C, то тут поможет только паяльник.

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

Ребята я очень рад что вы так активно обсуждаете I2C.
Но я прошу помочь с USB. У меня с ним проблема.

В кубе сделан проект USB CDC.

При запуске мк. и открытие порта программой COM port tolkit.

Вылетает ошибка Error setting parameters from DCB.

В CDC передается пакет с настройками при открытии порта (bRequest == SET_LINE_CODING).
Он к вам приходит?

Или так.

Я такую ошибку видел только когда случайно установил скорость работы СОМ порта, которую не поддерживал сам СОМ порт. Нужно найти compt.ini в директории установки Тулкита и в ручную подправить скорость на правильную.


А я прекрасно понимаю потому что на разных МК модули I2C настолько разные, и частенько, настолько кривые, что применять их просто не хочется. На старых ПИКах мастера I2C вообще не было, все в ручную. На АВР-ке я даже один раз сварганил мастера и слейва на прерываниях встроенного модуля, но ПО для этого выглядело настолько чудовищно нечитабельно, что никакого удовлетворения не доставило. На МСП430 были потуги применить аппаратный I2C на прерываниях, даже пару дней убил на это, пока не обнаружил, что они прое*** забыли сделать прерывание на одно состояние. Типа почти все на прерываниях, а вот тут нужно "поллингом" Плюнул, вернул ногодрыг, который по коду коротенький, компактный и понятный. Благо что I2C синхронная, её везде можно приостановить что на 10 мс, что на 1 сек.
На STM32 пока до I2C не добрался, но тоже предстоит...

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

А по поводу пинцета - даже без него бывают глюки - например еще не подано питание на slave или обращение к нему произошло до того, как завершился его startup. Нормальный I2C должен дать ошибку и возможность привести автомат в нормальное состояние, а не впадать в клиническую смерть.

Почему не может?
Во-первых: это не штатная работа, а процесс инициализации из произвольного состояния (сброса без снятия питания).
Во-вторых: это только на данном МК так (STM32F4xx), возможно там можно сделать такой сброс и через возможности штатного контроллера I2C, но оно особо не нужно разбираться - это однократная короткая операция при старте, по большому счёту без разницы как она работает. А вот штатный обмен да ещё со множеством устройств да ещё когда среди этих устройств есть FRAM-память с пересылками в несколько десятков КБ и есть устройства выдающие периодически пачки в десятки-сотни байт (тачскрин) - делать это не то что без DMA, а ещё и ногодрыгом - ну это просто какая-то уже совершенно абдуринщина в запущенной стадии.

PS: У меня в текущем проекте на XMC4500, контроллер I2C гораздо мощнее STM-ного. Здесь думаю сделать процедуру сброса при старте (несколько СТОП-условий) силами самого I2C-контроллера. Потому что на XMC4500 это сделать даже проще чем ногодрыгом. У него вообще можно всю транзакцию (СТАРТ+адрес+W, запись адреса регистра, РЕСТАРТ+адрес+R, N-чтений с ACK, 1 чтение NACK, СТОП) - можно записать одним блоком сразу в FIFO I2C и запустить на выполнение на машине состояний I2C-контроллера. А в конце транзакции получить ОДНО прерывание о завершении и вычитать из FIFO результат. Каждое слово (11 бит) в блоке: младшие 8 бит - слэйв-адрес или байт данных, старшие 3 бита - команда-состояние I2C (СТАРТ,РЕСТАРТ,СТОП,передача,...). И ISR очень простой и всего одно прерывание в конце - просто красота по сравнению с STM. Не говоря уже о ногодрыге... При желании можно подключить и DMA для наполнения FIFO I2C.
Все нештатные ситуации - NACK, lost arbitration и т.п. - отслеживаются самим I2C-контроллером, выдаётся нештатное СТОП-условие на шину (или завершение приёма байта, NACK и СТОП если идёт приём) и прерывание с флагами ошибки в регистре статуса.


Так может нужно выбирать МК с хорошей периферией?
Оцените как выглядит и насколько простая реализация обмена по I2C на XMC4500:

Первая функция - ISR. Пока нет обработки ошибочных ситуаций (не получен ACK на slave addr, lost arbitration и т.п.), позже добавлю - это мелочи.


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

По поводу I2C. До 2010 года активно использовал AVR8 для safety-critical проектов. Машина состояний там имеет аппаратную ошибку, подтвержденную тогда еще Atmel'ом. Сут= ее в том, что помехи на шине приводили к потере арбитража в Multi-master mode и шина зависала. Для решения, одновременно с циклом обмена, запускался таймер в режиме watchdog. Если цикл приема-передачи не завершался вовремя, таймер выключал и тут же включал периферию. После перехода проекта на Cortex-M проверял устойчивость I2C на FPGA(NIOS-II), NXP, Atmel, STM32F2xx/4xx(F1xx сильно отличается). Итого: к NXP нет никаких претензий, Atmel не давал никакой возможности stretch cycle, STM худо-бедно позволяла работать НО без всяких кубов/SPL. При этом, подчеркну, что создавал помехи, подключая на шину GPIO с открытым коллектором, управляемым хаотично(0/1) в короткие промежутки времени(единицы us) и проверял целостность и времена трансферов. The product safety tests were completed succesfully.
Данная информация доведена до вашего сведения, а не для дальнейших дискуссий.