Aleksandr Baranov 1 5 апреля, 2018 Опубликовано 5 апреля, 2018 · Жалоба Скорость нарастания питающего напряжения у работающих и не работающих плат одинакова? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 10 5 апреля, 2018 Опубликовано 5 апреля, 2018 · Жалоба Вариантов много, один из них - забыта инициализация каких-либо переменных или регистров которые после подачи питания имеют случайное состояние. Или как-то некорректно ожидается "раскочегаривание" кварцев, PLL... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex_Golubev 0 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Путем отключения и включения разных инициализации периферии, было установлено что проблемы возникают из-за I2C. Но как влияет в моем случаи I2C мне не ясно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 17 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Но как влияет в моем случаи I2C мне не ясно. Попробуйте для начала отключить вообще все узлы на этой шине. Если возможно, то покажите схему девайса. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 10 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Но как влияет в моем случаи 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 184 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Без дикого while(I2C2->SR1 !=0 ) ничего не работало (вроде, I2C переставал функционировать и никак его из этого ступора было не вытащить). Долго возился, но в итоге переделал все на ногодрыг. Странно, у меня прекрасно работает как раз на F429 аппаратный I2C (да ещё с DMA) с кучкой висящих на нём разных устройств (FRAM + RTC + FM-тюнер + touch-контроллер) на 400кГц. По многу часов без каких-либо сбоев. И никаких ногодрыгов и тем более - циклов в ISR. Так что у автора явно не МК виноват, а кривые руки. :laughing: #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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Или как-то некорректно ожидается "раскочегаривание" кварцев, PLL... + на плате, которая глючная, поменять кварц или генератор. Возможно дело в конкретном экземпляре. Попробуйте для начала отключить вообще все узлы на этой шине. . . . + Поотключать блоки кода или функции. + Если (вдруг) в коде проекта есть таймауты - подвигать их длительность. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 10 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Странно, у меня прекрасно работает как раз на F429 аппаратный I2C (да ещё с DMA) с кучкой висящих на нём разных устройств (FRAM + RTC + FM-тюнер + touch-контроллер) на 400кГц. Для этого проекта применялся STM32F103RET6. По многу часов без каких-либо сбоев. Масштаб "часы" это очень мало. В проекте использовался дисплей TIC154(A) на I2C для постоянной индикации. А сбои вы как-то разруливали? Бывает, slave выдает ACK на линию, а мастеру хочется START устроить, но у него ничего не получится. Тут ногодрыгом нужно slave протолкнуть до 1 на SDA. Я умышленно создавал помехи в линии, чтобы система смогла их обработать. И никаких ногодрыгов и тем более - циклов в ISR. Так что у автора явно не МК виноват, а кривые руки. :laughing: Никто с этим не спорит. Когда все хорошо (нет помех), то и сценарий работы сложно сделать плохим, но ведь бывают нештатные ситуации... в этом случае корректнее говорить о таланте разруливания, а не о кривизне рук, т.к. работают скорее не руки, а голова. Приведенный кусок - это ситуация когда сразу за STOP от предыдущей посылки формируется START для следующей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Для этого проекта применялся STM32F103RET6. У автора как раз F429, а не F103. А у них как я слышал - I2C сильно отличаются. А сбои вы как-то разруливали? Бывает, slave выдает ACK на линию, а мастеру хочется START устроить, но у него ничего не получится. Тут ногодрыгом нужно slave протолкнуть до 1 на SDA. Я умышленно создавал помехи в линии, чтобы система смогла их обработать. Не понял - что значит "slave выдает ACK на линию"? ACK слэйв выдаёт только для подтверждения приёма данных. Мастер в это время никак не может СТАРТ выдавать, он ACK или не-ACK должен ждать. И не понимаю - зачем тут ногодрыг? Никто с этим не спорит. Когда все хорошо (нет помех), то и сценарий работы сложно сделать плохим, но ведь бывают нештатные ситуации... в этом случае корректнее говорить о таланте разруливания, а не о кривизне рук, Помех по I2C у меня в том устройстве очень много. По питанию (и возможно по эфиру) от работающего рядом ESP8266. И я долго с ними боролся. Даже сюда писал. Но теперь всё работает стабильно. Приведенный кусок - это ситуация когда сразу за STOP от предыдущей посылки формируется START для следующей. 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 и без ногодрыга. :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 10 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Не понял - что значит "slave выдает ACK на линию"? ACK слэйв выдаёт только для подтверждения приёма данных. Мастер в это время никак не может СТАРТ выдавать, он ACK или не-ACK должен ждать. Мастер выдал на SCL такт, но в результате помехи slave его не принял, а поскольку slave до этого выдавал ACK уровня "0", то получается, что мастер уже такт для ACK выдал и считает транзакцию законченной, а slave ждет такта для проталкивания ACK. Если не понятно, что это редко, но возможно, и без ногодрыга это не решить, то пусть это останется вне рамок обсуждения данной темы. Так что как видно - обхожусь без циклов в ISR и без ногодрыга. :laughing: Проблема не с повторным стартом (который нужен, например, при чтении), а в идущих друг за другом обычных write-транзакций. Попробуйте нарисовать STOP и START с нулевой паузой между ними. У меня получается лишь "1"-иголка на SDA. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 6 апреля, 2018 Опубликовано 6 апреля, 2018 · Жалоба Мастер выдал на 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 131 7 апреля, 2018 Опубликовано 7 апреля, 2018 (изменено) · Жалоба Я тоже ничего не понял про ACK во время START... Вообще таких вещей протокол не предусматривает. Есть четкая последовательность выдачи сигналов на линии. Да, бывают сбои по различным причинам - от мощных переключателей вне устройства, например, происходит рассинхронизация приемника и передатчика путем вставки "лишнего" clock-а. Я, например, всегда придерживаюсь стратегии следующего рода: если процессор очень шустрый, периферия медленная, но есть DMA - я всегда работаю с DMA. I2C в STM32F429 также поднимал с обработкой всех ошибок. Я делал так: // 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 и запускаю контролирующий таймер на минимальный интервал передачи одного байта. Теперь выхожу из функции - вся остальная работа будет сделана в прерывании. 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) постоянно сваливаются нужные флаги. Изменено 7 апреля, 2018 пользователем IgorKossak [codebox] для длинного кода, [code] - для короткого! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 7 апреля, 2018 Опубликовано 7 апреля, 2018 · Жалоба I2C в STM - полное барахло и недоделка, ваш код только подтверждает это. Я внимательно смотрел его на 207 - там автомат сделан принципиально неправильно, он влипает в ситуации из которых выйти не может и без полного сброса его оттуда не вывести. Именно поэтому каждую операцию приходится окучивать таймаутами, что является полным безобразием. Нормальный автомат обязан сам давать информацию об ошибке, сам (по своим тактам) следить за своими таймаутами и иметь алгоритм нормального (без полного сброса) выхода из ошибочных ситуаций. Stm-ки попытались это сделать, но у них откровенно не получилось. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 7 апреля, 2018 Опубликовано 7 апреля, 2018 · Жалоба При отправке я сначала смотрю, а не занят ли модуль I2C прошлой транзакцией. Чтобы вечно не тупить в цикле ожидания BUSY, покрываю проверку аппаратным таймером на максимальную длину посылки через DMA. Если занят - говорю что вышел таймаут ожидания и выхожу из функции. Чуть позже добавлю сюда просто ожидание семафора, чтобы освободить задачу (эта функция крутится в составе ОСРВ). В указанном устройстве у меня есть арбитр шины I2C. Он и управляет всеми транзакциями на шине. Это процесс, который ждёт появления флагов запросов от клиентов о выполнении очередной транзакции с одним из устройств на шине. Каждый клиент, когда хочет выполнить транзакцию с одним из I2C-устройств, формирует запрос об этой транзакции, помещает его в один из слотов запросов (свободный слот), выставляет флаг наличия запроса в слоте, пингует I2C-арбитра и становится на ожидание события завершения транзакции. I2C-арбитр, когда освобождается после завершения очередной транзакции, просматривает флаги активных запросов в слотах и выбирает наиболее приоритетный из них и запускает выполнение данной транзакции (программирует периферию I2C, DMA, выполняет последовательность шагов машины состояний в ISR и т.п.). По завершении транзакции, он заносит в слот информацию о результате транзакции (ОК или ошибка или ...), переводит событие готовности слота в сигнальное состояние (клиент выходит из состояния ожидания события) и выбирает следующий слот, ждущий обслуживания. Если такового нет сейчас - уходит в IDLE. Так что всеми транзакциями на шине и всей периферией, связанной с данным портом I2C, у меня управляет один процесс - I2C-арбитр. Клиенты, запрашивающие операции обмена с I2C-слэйвами, работают только через его API. Они изолированы от железа. Именно поэтому каждую операцию приходится окучивать таймаутами, что является полным безобразием. Ничего не могу сказать про 207, но на F429 у меня транзакции по I2C не "окучены" ни какими таймаутами. Единственный таймаут, который отслеживается в коде моего I2C-драйвера - это когда при инициализации драйвера я выполняю многократно СТОП-условие по шине и контролирую наличие залипания линии SCL в низком состоянии слишком долгое время. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 7 апреля, 2018 Опубликовано 7 апреля, 2018 · Жалоба Ничего не могу сказать про 207, но на F429 у меня транзакции по I2C не "окучены" ни какими таймаутами. Однако я тогда не совсем понимаю, какая у Вас гарантия того, что данные успешно передадутся, да еще в нужное время. Если в Вашем устройства (на макете) замкнуть SCL на SDA пинцетом, затем убрать - связь восстановится? Если восстановится - то не понимаю, какая магия у Вас мониторит, что нужные флажки не взвелись через определенное время и сбрасывает автомат. Ведь идеологически любая конструкция while(ожидание флага); должна сопрягаться с установкой таймаута ожидания (не важно, средствами ОС или же аппаратным таймером). Ведь слова По завершении транзакции, он заносит в слот информацию о результате транзакции (ОК или ошибка или ...)... ставят встречный вопрос - каким же образом можно узнать результат транзакции? Ведь после установки битов управления (тот же START-бит), нужно некоторое время, чтобы в регистре статуса этот бит был выставлен и сгенерировалось прерывание. Если, как было указано выше, бесконечно ожидать, то получится полная лажа при какой-либо помехе на I2C-шине. Таймаут-то по-любому нужен, как без него... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
