[uquote="jcxz",url="/forum/viewtopic.php?p=4246860#p4246860"][uquote="AlanDrakes",url="/forum/viewtopic.php?p=4246686#p4246686"]К сожалению, не так. Код выглядит так:[/uquote]Что именно "не так"? Вы свою же осциллограмму смотрели?? Похоже что нет.

Видно, что ACK недотактирован. Не завершаете корректно I2C-транзакцию.
И зачем втюхивать какой-то "код", даже не указав к какому МК он относится??
Изучите получше I2C своего МК. Судя по осциллограмме: скорее всего не завершаете корректно I2C-транзакцию и начинаете новую. Без хрустального шара никто не сможет угадать какой МК ковыряете и что именно делаете.
PS: И хорошим тоном является не только:
a) указывать
название МК;
b) подписывать -
какая осциллограмма к какому действию относится;
c)
подписывать названия сигналов на осциллограмме.[/uquote]
[Zanuda Mode ON]
1. То есть, вас не смутило, что датчик ЯВНО I2C и висит на этой шине?
2. На "осциллограмме" (хотя это скриншот логического анализатора, но не суть) видно и начало транзакции и такая же транзакция с другим адресом, которая проходит корректно (и даже виден импульс, появляющийся в момент передачи шины slave->master) прямо под всеми ACK кроме адреса 0x9E.
a - STM32F767ZGT6 (аналогично ведёт себя и STM32L152) при наличии двух датчиков на шине.
b - Обе относятся к моменту сбоя ответа. И теперь непонятно, к сбою какого из датчиков - AHT10 / BME280.
c - 0 - SCK, 1 - SDA. Два следующих - болтаются в воздухе. Над ними - встроенный в интерфейс декодер сигналов I2C.
[Zanuda Mode OFF]
------------------------------------------------------------------------------------
По результатам теста стало понятно, что ничего не понятно.
ATH10 (Single) -> OK. Работает без нареканий все выходные (прошлые)
BME280 (Single) -> OK. Работает без нареканий все выходные (текущие)
AHT10 + BME280 -> Stuck. Зависает в случайные моменты времени от 30 секунд (~5 циклов запросов данных) до 10 минут.
Всё питается от 3.6V.
И у меня такое ощущение, что AHT10 в какой-то момент считает, что обращаются к нему. И имеются некоторые подозрения на корректность работы схемы сдвига уровня на его плате:
Убрал с платы стабилизатор и обошёл парой перемычек "схему сдвига уровней". Наблюдаем-с...
Обошёл схему сдвига уровней на AHT10.
Не помогло.
Поменял адрес оного с 0x38 на 0x39.
Не помогло.
Уменьшил агрессивность таймингов шины I2C:
I2C2->TIMINGR = 0x405
41010; (SDA_DELAY)
Теперь SDA меняется на четыре такта позже, чем SCK, а не на один, как работало с любыми другими чипами, к которым у меня был доступ. Вроди бы заработало.
Самое странное, что работает с одним датчиком на шине без сбоев!.
UPD 2:
Не помогло. Но на этот раз видно, что дело где-то на стороне одного из ведомых - это видно по фазе сигнала. STM32 делает переход уровня на SDA со сдвигом на указанное выше количество тактов (4) (хотя для наглядности выставил

, общая длительность одного бита - 0x10 + 0x10 = 32 условных такта.
Код: Выделить всё
SCK ````|____|````|____|````|____|````|____|````|____
SDA ``|__(s)___(0)__|````(1)```|___(0)__|``````````|_
В то время как ведомый тянет линию вниз по спаду уровня на SCK.
У меня создаётся подозрение, что AHT10 наблюдает за линией и "находит" START там, где его нет, а за ним из байта 0x72 читает "свой" адрес и отвечает не в попад, потому как стабильно передача обрывается, когда BMP280 выдает ответ: 0x6F 0x82 0xC0 0x7E
0x72 0xC0.
:/
Теперь виню второй датчик. Снял новый дамп обмена на шине. Дополнительно подключил канал (2) непосредственно рядом с самим AHT10 ("SDA-AHT" на скниншотах). Но ничего понятнее не стало.
Момент запуска: (Прошу обратить внимание на время на шкале ~0.9с - время от момента начала захвата).
- Scr_2.png
- Момент перезапуска шины после зависания
- (12.49 КБ) 155 скачиваний
Собственно, чтение области калибровочных констант (на скниншоте не очень хорошо видно, но всё читается), затем - проверка статуса AHT10. Удачная. (39-E1-08-00).
До момента T+137c всё идёт корректно, посылки идут пачкой:
AHT10->Trigger()
+0.1c
AHT10->GetData() -> Status? -> Not ready
+0.1c
AHT10->GetData() -> Status? -> Not ready
+0.1c
AHT10->GetData() -> Status? -> Conversion Done
BMP280->Read (0xF7..0xFC)
Скриншот не прикладываю - тут всё похоже на вертикальные полоски и паузу в пару секунд.
И по какой-то причине когда датчик давления выдаёт 0x72 в предпоследнем байте - всё виснет.
Проверил по битам, да, там можно угадать х111001 - 0x39
Общий вид транзакции:
И сами биты:
И разница между фазами сигналов, когда шину ведёт STM32 и BMP280.
Первый оставляет задержку в 2.9мкс между переходом SCK 1->0 и изменением уровня SDA, второй - 0,2мкс (плюс-минус, потому что захват происходил на 10MSa/s, ибо шина изначально медленная).
Вот и вопрос: И как это победить? У меня пока банальный вариант - разнести датчики на физически разные шины. Но это же костыль!