Всем доброго времени суток.

Суть проблемы следующая - есть плата с ARM-овым процессором (от NXP) и тремя линиями I2C, подтянутыми 4.7К резисторами к питанию 1.8В. Частота I2C 100КГц.

На плате крутится линукс, пробую по i2cdetect/i2cget получить данные с подключенных к линии микросхем - ID возвращается нормально.
Подключаю преобразователь уровня с камерой - сообщения не приходят (подтягивающие резисторы только на борде). Иногда SCL "залипает" в нуле до сброса.

На одной линии I2C без подключенных устройств подсоединился осциллографом к SCL/SDA. Пока нет подключения к SCL - сообщение нормально уходит, как только подключаю щуп, происходит следующая картина:
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Грешу на избыточную емкость на линии, но может быть еще какие-то варианты? Перепаивать резисторы такого типоразмера сложновато..

У меня похожее но только по причине использования переходника между доменами питания 3.3В - 5В и мотни из проводов длинной. процессор ВМ10Я. тоже делает такие шила вместо нормального клокового импульса. шила амплитудой примерно 2В - уровня лог1 на домене 3.3В. абонент на домене 5В их не замечает, и пропускает клоки.

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

я бы уменьшил с 4к7 до 3к3 (а то и 2к) при 1V8..

придется внимательно смотреть в исходниках ядра логику работы драйвера i2c для вашего АРМа.. найдите место где АРМ отлавливает таймауты на шине и попробуйте увеличить интервал ожидания, число попыток и после неуспеха полную реиниализацию этой подсистемы в АРМе.. ну и быть готовым к правкам в софте пользователя из-за "неожиданных" прерванных транзакций по i2c

похоже на наводки на шуп или от DC/DC на желтой линии - ищите источник помех..

на наводки не похоже: узкие пики - это мастер выставляет на клоке 1, и тут же его в 0 опускает. при этом положительное время клока считается уже прошедшим. почему так делается - спасибо тому кто раскажет.
может уменьшение до подтяжек реально поможет? яб 470ом попробовал.

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

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

AlexRayneДа, больше пока нечего придумать. Буду ждать ответа от NXP и подумаю, как снять резисторы без последствий.

Еще возникла мысль, может быть это clock stretching.. Например, время нарастания фронта недостаточно быстрое и мастер считает, что слейв держит SCL, пробует через полпериода или период выставить новый высокий уровень, но передача в итоге сбивается и слейв не возвращает ack.

А какие у вас преобразователи лог. уровней стоят?

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

На мосфетах, по такой схеме
Нажмите для просмотра прикрепленного файла
С I2C, конечно, убраны pull-up резисторы со стороны борды.

Похоже Вы правы. У меня не шлейф, а отдельные провода, но все же - сейчас попробовал прицепиться к земле поближе (тестировал осциллографом) и передача прошла без сбоев.
С преобразователем та же проблема, вероятно.. буду тестировать на новой отдельной плате.

Зачем снимать? накиньте паралельно где получиться

Спасибо, что-то я затупил, попробую воткнуть 4.7К на преобразователе.

Сейчас подключил свежезапаяную плату преобразователя уровня, i2cdetect выдает мусор, трансивер на шине перестает работать.
Если к пинам подключиться еще и осциллографом, то при загрузке линуха (видимо в этот момент CPU пытается записать данные в трансивер HDMI) SDA падает в ноль намертво, до следующего ресета.

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

upd. на линии I2C без других микросхем, при запросе i2cdetect процентов 60% сообщений проходят нормально (нет мусора), при подключении щупов - процентов 15%.

1. попробуйте отвязать щупы через транзисторные буфера или подходящую низковольтовую логику
2. шина i2c "не любит" большую емкость физических линий (мы с этим столкнулись поставив в левелшифтер полевики с большой собственной емкостью), но это вроде не ваш случай - фронты вполне валидные
3. вместо камеры для тестов подключите что-то типа 24c02/04 или подобную i2c eeprom - этим отсекаете возмущения по питанию и можно тестировать работоспособность шины, варируя длиной проводков..


согласен, посчитал импульсы, действительно это похоже на клоки с очень странным поведением - если бы давил слейв, то была бы ступенька.. с другой стороны мне неизвестны АРМы с таким поведением корки мастера i2c - всегда считал, что клок атомарен и импульс должен быть полный при отсуствие внешних воздействий.. в общем это вопрос к NXP

(вопрос к ТС - а что, собственно, за АРМ? NXP который freescale или нативный NXP типа LPC?)

и2ц мастер должен както отлавливать удерживание клока, или захват его - так что атомарность у него с оговорками.
к нашему элвису (ВМ10Я) тот же самый вопрос. имхо они могли взять готовую глючную корку и2ц, может на какихто опенкорес....
полагаю у данного проца всегда есть выход - захватить пины и програмно реализовать интерфейс. гораздо поганее если такой возможности нету.

У вас какие то ужасы.
Проверьте уровень логического нуля, сравните с ДШ всех чипов на шине. Бывает VIL = 0.2*VCC = 0.35V
Видел в ДШ даже 0,3V.
ноль 0,3v обеспечить и без преобразователя уровня не всегда получается.

Скорее Freescale, проц - s32v234, во многих моментах пересекается с imx6.

Так или иначе, добавил в параллель 4.7К (получилось 2.35К) со стороны борды, и заменил на 2.2К со стороны преобразователя - I2C работает, даже на линии с микросхемами!

До самого девайса (камера) не удалось пока достучаться. Утром еще заметил, что сигнал тактовой 27МГц после преобразователя получается со смещением. Заменил резисторы на 2.2К так же (думал из-за емкости не успевает разряжаться), но результат такой же практически:
Нажмите для просмотра прикрепленного файла
Сверху 1.8В сигнал от борды, снизу - соот-но от преобразователя. Частота не верно показана, она 27МГц.

Вот из ит "борда"?

борда=board, отладочная плата в данном случае -)

не очень представляю, каким образом работая на передачу, можно на той же линии поймать коллизию.. пойму, если дергая scl, проц смотрит sda
у того же imx6 есть строчка
"Data output to 12Cn_SDA stops, but 12Cn_SCL is still generated until the end of the byte during which arbitration is lost."

тут же (а картинках ТС) какая-то ерунда - клок пошел вверх и на половине почти мгновенно упал.. ну не бывает так.. с малоподобной гипотезой, что кратковременно валится питание выходных буферов или отваливаются пуллапы


ну вполне, что вам что ТС, можно изобразить i2c-gpio для тестирования, а то и для работы, если хватит производительности проца и не попортятся остальные времянки (gpio mode достаточно грузит систему при плотном обмене)

с элвисом не знаком, и если нет официальных еррат, то наверно надо напрямую спрашивать у производителя: "какого хрена i2c?", прикладывая времянки и схему соединения..

Такой вопрос возник - как проще всего преобразовать уровень сигнала 1.8В к ~2.8В на частоте 27МГц?
Текущая схема не годится..

Вроде бы можно попробовать использовать драйвер для мосфета или ОУ.
Смотрел, например MC34151, но у него Drive Output Rise Time 14нс, а у меня период - 37нс.

попробуйте глянуть на спецификации 74HC14 от NXP. думаю много других подобных вариантов найдется

чтобы точно работало - SN74AVC1T45 и им подобные с двумя питаниями.
можно пробовать и преобразователи с одним питанием но там надо проверять уровни.
придется считать задержки: из-за преобразователей уровня времянки могут уехать.

AlexRayne , _3m Спасибо, поставлю преобразователь.

А какие там задержки могут быть? Камера же через n периодов выдает свою частоту и hsycn/vsync, а задержки входной частоты как бы и не важны.
Или речь не об этом?

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

На камеру приходит сигнал тактовой 27МГц с платы, через n циклов задержки (точно не помню сколько) камера выдает обратно частоту, синхронную с данными на 8-битной шине (сама картинка), сигналами горизонтальной и вертикальной синхронизации.

Сигналы выдается источником (камерой) и защелкиваются приемником (soc) синхронно с клоком. Если на пути клока возникнет задержка времянки могут нарушиться.

Да, действительно, проверю, спасибо!

У мну конечно частоты пониже но проблема схожая. STM32L151 как источник I2C на одной плате, разъем - шлейф -разъем и пять микросхем - абонентов I2C на другой плате. Шлейф отдельными проводами. Подтягивающие резисторы не на конце линии, а у начала цепочки микросхем - абонентов шины.

Так вот, из - за отражения 3-4 микросхемы отказываются выдавать данные. Хотя на шине видны. И почему - то защелкивается в нуле SDA. Пока нашел кривое решение: просканировал шину на разных частотах и нашел что при 170КГц все исправно работает. Хорошо видно как при смене частот отваливаются разные абоненты. Причем это единственный диапазон 120 - 170 Кгц из возможного 10КГц - 1МГц.

Согласен, решение кривое. Может перенести резисторы (1к, 3.3В) на конец линии?

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

Как тогда бороться с отражениями? Ставить с двух сторон?

Главное, такты передать от мастера к слугам. А данные раньше или позже придут правильные.

С резистором на SCL стало только хуже. Сейчас вспоминаю как я с десяток подряд лет паял шлейфы SCL по 1-3м не задумываясь об всяких там отражениях. Правда там проще все было - DS1621 на конце и все.

А уж было думал, что проблема решилась полностью, но нет -)
После добавления второй микросхемы для согласования уровня (на обратной стороне платы припаял проводами, закрепив клеем) i2c стала сбоить снова.
Причем ситуация такая, на линии i2c-1, где помимо камеры висит hdmi, при старте платы и линуха, пытается инициализироваться этот hdmi, но заваливается SDA:
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

На пустой линии i2c-0, если туда вешать камеру, вылазит такое (на этот раз SCL):
Нажмите для просмотра прикрепленного файла
Причем, иногда проходит несколько команд, находятся фантомные устройства на линии, но потом неизменно SCL падает.

Вероятно, дело в наводках на линию I2C с обратной частоты 27МГц, которая идет по проводу к разъему.

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

Согласен, наводки от тактовой визуально не видны и разницы до/после модификации по форме сигнала нету.
Попробую посмотреть в стороны i2c/gpio.

я уже запутался, откуда вторая микросхема? был же левелшифтер на дискретах..
вы бы примитивную функционалку нарисовали с номиналами и длинами шин, а то сам черт ногу сломит..
если на ваш проц (аналог imx6) нет никаких еррат, то пройдите по цепочке:
- отключите от проца всё и подвесьте что-то типа eeprom на 1.8в - убедитесь, что корка проца работает безукоризненно..
- повесьте ту же eeprom за левелшифтером на коротких проводках - проверяете исправность канала
- наращивайте длину проводов до появления ошибок, так узнаете критичную длину шины
потом пункты два и три делаете для камеры, начиная с минимальной длины, т.к. 27МГц после левелшифтера может звенеть и заваливать фронты
i2c отличная шинка и замечательно работает, если не наглеть с длиной, скоростью и емкостью физики..
да, пуллапы ставятся не от балды - у филипса (philips->nxp->qualcomm) была аппнота
ну и неоднократно упоминаемый вариант i2c-gpio, но панацея, но для независимой проверки сгодится..
по камере - при подключение никаких чудес нет? например висящий в воздухе shutdown или левые импульсы на reset камеры..

Микросхему (NOR) я напаял сверху и подключил ее вместо преобразователя (частота слишком высокой оказалась для такой схемы на мосфетах), для линии входной частоты. Старые дорожки разрезал, чтобы не было антенного эффекта. В это время i2c протокол работал хорошо, удалось обнаружить камеру по i2cdetect. Правда адрес отличался от того, что указан в ДШ, этот момент я не понял. После чего я допаял еще одну микросхему NOR, дабы пустить через нее обратный сигнал частоты от камеры. И начались (продолжились) вышеописанные глюки.

Длина линий не более 15см, номиналы со стороны проца ~2.35K(после допайки резисторов), со стороны камеры - 2.2К. Напряжение IO пинов камеры - 2.8В, проца - 1.8В.

На этой линии висит только лишь HDMI трансмиттер -по нему видно, что передача идет нормально, когда нет камеры на линии, иначе просто не идет сигнал на монитор.
Errata молчит. Про пулапы я почитал, все вписывается по расчетам.
С камерой все нормально, ресет подтянут к уровню, она выдает все сигналы синхронизации и данные.

Хочу передалать схему на полноценном преобразователе уровня, удалось найти из двунаправленных (без DIR пина) только txs0108e. По характеристикам подходит, поддерживает push/pull / open drain и по частоте тоже запас.

если у камеры есть селектор адреса, то у вас (у камеры) видимо уровень болтается.. если конечно это не дефект таймингов на шине при передаче адреса камеры по i2c..

а трансмитер гадить не может? он часом не мастерит в сторону smb hdmi вычитывая edid?

малость избыточно.. зачем вам двунаправленность? только для управления по i2c.. с камеры валит поток и синхра, в камеру тактовая и возможно gpio управление..

Тут нет селектора и все линии у меня к чему-то подтянуты..

Возможно. Однако, есть линия I2C-0, на которой вообще пусто, но на ней тоже происходят подобные сбои (фантомные девайсы появляются, а потом линия падает в ноль).
Кроме того, после первого исправаления при тестировании hdmi не мешал абсолютно.

Большинство микросхем в наличии <= 8 бит, не удобно разбивать, 8 бит на данные входящие, а остальные сигналы разнонаправленные. Да и так больше шансов, что tpd у сигналов будет одинаковое..

вы это о клоках или и2ц?
обратный левел-шифт из низковольтового домена в высоковольтовый надо делать микрухами т.н. "толерантными" к более высокому питанию. нетолерантные дадут вам как минимум большую утечку из сигнального входа на высокое питание, а в худшем случае дадут прямой ток диода. попробуйте врезать в сигнал клока перед входом вашего НОР резистор небольшой - 50-100ом.

по поводу адресов - это частенько происходит от того что неучитывается сдвиг на младший бит адресный - который указывает тип транзакции чтение/запись.

Это именно клоки камеры. Просто после модификации обратного клока i2c опять пошла вразнос.

Не совсем понял. Толерантность по питанию требуется же при преобразовании из high->low, когда на вход подается более высокое напряжение.
А при преобразовании low-to-high питание идет высокое, а открывается "низким" уровнем.
И судя по сигналам, по части клока все нормально. На линии данных приходят нули (там уровень так же задавлен до 1В и не воспринимается входными буферами), поэтому картинка черная (точнее, зеленая, т.к. YUV цвет. пространство).
Сейчас нет под рукой названия микросхемы, дома посмотрю.

Попробую найти TXS0108E и повесить на плату, пропущу i2c и клоки в обе стороны, чтобы убедиться, что не будет сюрпризов.

p.s. Вы правы по части адреса, 0x42 >> 1 = 0x21

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


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

Вы писали: "обратный левел-шифт из низковольтового домена в высоковольтовый", а тут 2.8В от камеры в 1.8В, высоковольтный в низковольтный. Думаю, просто ошибка, но я понял о чем речь.


Микросхемы уже сегодня-завтра будут, так что можно будет проверить и убедиться.

И как успехи?

Была проблема, в одном МЕТАЛЛИЧЕСКОМ корпусе, один блок питания, несколько блоков. На линии i2c просеры по 2 вольта(как у тебя на фотке). В следствии этого залипал один из слэйвов. Проскоки оказались синфазны с работой импульсного БП. И их амплитуда зависела от нагрузки на БП. Грешили на неправильную разводку земли. Я всё перепробовал, улучшения были но незначительные. Затем думали наводки - хрен. Затем плату с процессорным модулем отвинтил от корпуса и включил её навесу не касаясь корпуса. И, вот! Помехи нет! Кароче, двухкиловольтным конденсатором 0,01мкФ GND зашунтировал на корпус и помеха почти исчезла. Насовав таких кондёров по периметру - устранило помеху.

Честно говоря - никак. Припаять все пины у TSSOP микросхем нормально не получилось (провода тонкого нет, получаются спайки и ноги норовят отвалиться от перегрева).

На выходных попробую откопать кусок текстолита и вспомнить старый добрый ЛУТ, сделаю небольшой переходник и подпаяю нормально.

То есть изначально земля процессорного модуля соединялась с корпусом? А корпус был заземлен?

посмотрите пустышку в ближайшем лабазе - ЧипДип, Микроника, Радетали..

для экспериментов на коленке надо было искать корпуса СОИК или СОТ23/35/53 или СЦ70. идея возни с двунаправленым буфером мне с самого начала не нравилась.

Ну отпишитесь - чего получилось то.

Я бы уже давно провел простой эксперимент - заменил бы резистор подтяжки SCL на два вдвое большего сопротивления, между ними последовательно в линию SCL впаял бы резистор ом на 470, всю эту конструкцию поместил бы между ведущим и ведомыми и сравнил бы сигналы на обоих концах этого последовательного резистора. Таким образом выяснил бы - кто "давит" этот сигнал SCL. Потому что чем больше я думаю об этих картинках, тем больше мне это кажется похожим на неправильно реализованный методом "ногодрыга" I2C, который вместо открытого коллектора использует двухтактный выход и который не предполагает возможность подтормаживания тактового сигнала (clock stretching) ведомым. Конечно трудно предположить такое поведение у аппаратного контроллера на стороне ведущего, но кто знает, как оно реализовано в программе... Может и вправду там ногодрыг авторы библиотек устроили.

ногодрыг не объясняет такого поведения - при тотемном выходе шилы короткие - котрые воспринимаются как помехи, имели бы размах питания полный.
знание того - кто же залипает шину конечно для отладки бесценно. только имхо - 470 ом слишком много. 2,5В/0,3В=9 => Rs = Rpull/9

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

да у ТС полный полтергейст.. уже советов натолкали..
http://electronix.ru/forum/index.php?showt...t&p=1453392
ну чего проще - взять копеечную еепром и погонять вместо камеры
- проблемы ушли, значит надо с камерой разбираться
- дефект остался, значит копать узел левелшифтера и узел i2c АРМа..

ТС до сих пор не озвучил полный состав шины.. известен АРМ (у меня три платы на разных imx6 (у ТС sc32) молотят месяцами - с i2c проблем нет), известно наличие некоего hdmi трансивера, известно что i2c АРМа на 1.8в, что за камера непонятно (сейчас выяснится, что она на 2.8в и дуреет от 3в3).. не, прикольно конечно, сидеть и гадать, кружочки-квадратики, 4 страница пошла..