При запуске из отладчика программа работает, когда отключаешь и снова включаешь STM32 программа перестает работать Опции

[Alex_Golubev]

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

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

Сообщение отредактировал Alex_Golubev - Apr 5 2018, 03:42

[Alex_Golubev]

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

[adnega]

Но как влияет в моем случаи I2C мне не ясно.

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

Код

        case    TIC_STATE_POS_STOP:
            I2C2->CR1 = I2C_CR1_PE | I2C_CR1_STOP;
            tic_state = TIC_STATE_FILL_START;
            break;

        case    TIC_STATE_FILL_START:
            s1 = 0;
            while(I2C2->SR1 !=0 ) s1++;
            I2C2->CR1 = I2C_CR1_PE | I2C_CR1_START;
            tic_state = TIC_STATE_FILL;
            break;

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

[jcxz]

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

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

Код

#define TUNER_ADDR_NATIVE_SEQ 0x10 //RDA5807 mode, sequential register address
#define TUNER_ADDR_NATIVE_RND 0x11 //RDA5807 mode, random access mode.
#define TUNER_ADDR_COMPATIBLE 0x60 //TEA5767 compatible mode
#define FRAM_ADDR             0x53 //адрес FRAM-памяти FM31T37x
#define RTC_ADDR              0x6B //адрес RTC FM31T37x
#define TSC_ADDR              0x41 //адрес touchscreen controller STMPE811

[adnega]

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

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

По многу часов без каких-либо сбоев.

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

И никаких ногодрыгов и тем более - циклов в ISR.
Так что у автора явно не МК виноват, а кривые руки.

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

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

[jcxz]

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

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

А сбои вы как-то разруливали? Бывает, slave выдает ACK на линию, а мастеру хочется START устроить, но у него ничего не получится.
Тут ногодрыгом нужно slave протолкнуть до 1 на SDA. Я умышленно создавал помехи в линии, чтобы система смогла их обработать.

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

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

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

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

CODE

enum {OPTION_DUPLEX_RS, OPTION_DUPLEX_SS, OPTION_2BYTE, OPTION_TIMER, OPTION_SA};
..
extern "C" void Isr()
{
u32 i0 = i2cU->SR[0], i1;
if (!i0) return;
switch (isrStep) {
case IS_RESTART: //передан повторный START
if (!(i0 &= ~(1 << SR0_BTF | 1 << SR0_TXE))) return;
case IS_START: //передан START
if (i0 != 1 << SR0_SB) fault(i0);
i0 = i2cU->SR[1];
if ((i0 & (1 << SR1_MSL | 1 << SR1_BUSY | 1 << SR1_TRA)) !=
(1 << SR1_MSL | 1 << SR1_BUSY)) fault(i0 | ERR_BAD_START << 16);
if (saddr & 1)
if (cnt + 1 < 0) i2cU->CR[0] = 1 << CR0_ENA | 1 << CR0_ACK;
i2cU->DR = saddr;
if (option & 1 << OPTION_TIMER) actTimer = HrTimerGet();
isrStep = IS_SADDR;
return;
case IS_SADDR: //передан Slave Address
...
case IS_CMD1: //передана вся стартовая последовательность
if (i0 == 1 << SR0_TXE) return;
if (i0 != (1 << SR0_BTF | 1 << SR0_TXE)) fault(i0);
if (option & (1 << OPTION_DUPLEX_SS | 1 << OPTION_DUPLEX_RS)) {
saddr++;
i2cU->CR[0] = (option >> OPTION_DUPLEX_SS & 1) << CR0_STOP |
1 << CR0_START | 1 << CR0_ENA;
isrStep = IS_RESTART;
return;
} else if (cnt) {
i1 = IS_TX;
...

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

[adnega]

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

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

Так что как видно - обхожусь без циклов в ISR и без ногодрыга.

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

[jcxz]

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

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

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

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

[Arlleex]

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

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

CODE

// HW_ExchangeTransmitData - функция отправки данных по внешнему каналу обмена.
// Параметры:
// Buffer - указатель на буфер передаваемых данных;
// Size - объем данных в байтах.
// Возвращаемое значение:
// HW_EXCHANGE_TRANSMIT_OK - отправка успешно запущена;
// HW_EXCHANGE_TRANSMIT_ERROR_TIMEOUT - канал обмена занят транзакцией данных.
unsigned int HW_ExchangeTransmitData(void *Buffer, unsigned int Size)
{
HW_EXCHANGE_TIMER_START(65535);

while(I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY) && !ExchangeBusyStatus);
HW_EXCHANGE_TIMER_STOP();

unsigned int PhysicalBusy = ExchangeBusyStatus;
ExchangeBusyStatus = 0;

if(PhysicalBusy)
return HW_EXCHANGE_TRANSMIT_ERROR_TIMEOUT;
else
{
ExchangeTxDataQuantity = Size;

DMA_MemoryTargetConfig(DMA1_Stream6, (unsigned int)Buffer, DMA_Memory_0);
DMA_SetCurrDataCounter(DMA1_Stream6, ExchangeTxDataQuantity);

I2C_GenerateSTART(I2C1, ENABLE);

HW_EXCHANGE_TIMER_START(1);

return HW_EXCHANGE_TRANSMIT_OK;
}
}

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

CODE

void I2C1_EV_IRQHandler(void)
{
if(I2C_GetITStatus(I2C1, I2C_IT_SB) == SET)
{
ExchangeDirection = HW_EXCHANGE_DIRECTION_TRANSMITTER;

HW_EXCHANGE_TIMER_STOP();

I2C_Send7bitAddress(I2C1, HW_EXCHANGE_I2C_ADDRESS_ABONENT, I2C_Direction_Transmitter);

HW_EXCHANGE_TIMER_START(1);

return;
}

if(ExchangeDirection == HW_EXCHANGE_DIRECTION_RECEIVER)
{
BaseType_t xHigherPriorityTaskWoken = pdFALSE;

if(I2C_GetITStatus(I2C1, I2C_IT_ADDR) == SET)
{
if(!ExchangeOverrunStatus)
{
ExchangeOverrunStatus = 1;

DMA_MemoryTargetConfig(DMA1_Stream0, ExchangeRxDataBuffer, DMA_Memory_0);
DMA_SetCurrDataCounter(DMA1_Stream0, ExchangeRxBufferSize);

DMA_ClearFlag(DMA1_Stream0, DMA_FLAG_TCIF0);

DMA_Cmd(DMA1_Stream0, ENABLE);
}
else
System.ExchangeStatus |= SYSTEM_EXCHANGE_STATUS_RX_ERROR_DATA_OVERRUN;

(void)I2C_GetFlagStatus(I2C1, I2C_FLAG_TRA);
}

if(I2C_GetITStatus(I2C1, I2C_IT_BTF) == SET)
{
(void)I2C_ReceiveData(I2C1);

System.ExchangeStatus |= SYSTEM_EXCHANGE_STATUS_RX_ERROR_BUFFER_OVERFLOW;
}

if(I2C_GetITStatus(I2C1, I2C_IT_STOPF) == SET)
{
if(DMA_GetCmdStatus(DMA1_Stream0) == ENABLE)
DMA_Cmd(DMA1_Stream0, DISABLE);

if(I2C_GetFlagStatus(I2C1, I2C_FLAG_RXNE) == SET)
{
(void)I2C_ReceiveData(I2C1);

System.ExchangeStatus |= SYSTEM_EXCHANGE_STATUS_RX_ERROR_BUFFER_OVERFLOW;
}

*ExchangeRxDataQuantity = ExchangeRxBufferSize - DMA_GetCurrDataCounter(DMA1_Stream0);

xSemaphoreGiveFromISR(ExchangeRxSemaphoreHandle, &xHigherPriorityTaskWoken);

I2C_GenerateSTOP(I2C1, DISABLE);
}

portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
else
{
BaseType_t xHigherPriorityTaskWoken = pdFALSE;

if(I2C_GetITStatus(I2C1, I2C_IT_ADDR) == SET)
{
HW_EXCHANGE_TIMER_STOP();

DMA_ClearFlag(DMA1_Stream6, DMA_FLAG_TCIF6);

DMA_Cmd(DMA1_Stream6, ENABLE);

(void)I2C_GetFlagStatus(I2C1, I2C_FLAG_TRA);

HW_EXCHANGE_TIMER_START(ExchangeTxDataQuantity + 1);
}
else if(I2C_GetITStatus(I2C1, I2C_IT_BTF) == SET)
{
HW_EXCHANGE_TIMER_STOP();

I2C_GenerateSTOP(I2C1, ENABLE);

ExchangeDirection = HW_EXCHANGE_DIRECTION_RECEIVER;

xSemaphoreGiveFromISR(ExchangeTxSemaphoreHandle, &xHigherPriorityTaskWoken);
}

portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
}

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

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

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

Сообщение отредактировал IgorKossak - Apr 7 2018, 14:03

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!

[jcxz]

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

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

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

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

[Arlleex]

Ничего не могу сказать про 207, но на F429 у меня транзакции по I2C не "окучены" ни какими таймаутами.

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

Код

while(ожидание флага);

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

По завершении транзакции, он заносит в слот информацию о результате транзакции (ОК или ошибка или ...)...

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

[jcxz]

Если в Вашем устройства (на макете) замкнуть SCL на SDA пинцетом,

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

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

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

получится полная лажа при какой-либо помехе на I2C-шине.

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

[adnega]

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

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

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

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

[jcxz]

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

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

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

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

[adnega]

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

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

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

[jcxz]

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

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

[adnega]

Как именно может "завесить обмен" обычный СТАРТ или ACK - я думаю тут не только я, но никто не понял....

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

[jcxz]

Если slave в ACK, а master хочет сгенерировать START, то как он это может сделать?

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

[adnega]

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

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