Я думаю, что нашел ответ. Оказывается, это известная проблема, но я обнаружил ее только после того, как решил, где проблема, и искал ее!
Вот процесс, который я прошел, чтобы вы могли следовать ему (и, если необходимо, затем вы можете адаптировать свое расследование, если увидите результаты, которые отличаются от моих предположений). Суть в том, что, по-видимому, существует несовместимость между (по крайней мере, некоторым) поведением I2C MSP430 и требуемым поведением I²C устройством, которое вы подозреваете как подчиненное устройство I²C, IDT ZSC31014 . Наличие таблицы данных для этого устройства имеет решающее значение для понимания этого, поэтому спасибо за его поиск.
Хорошей новостью является то, что есть (по крайней мере) 2 обходных пути для этой проблемы, которые я объясню в конце.
График сгущается, кажется, что при подключении другого осциллографа схема не работает правильно, и видно, что единственное отличие состоит в том, что ACK не передается.
Новые следы полезны, спасибо, хотя я интерпретирую их немного по-другому.
(Недостаточный сигнал SCL, который касался меня на начальной трассе, все еще там на последней трассе. Интересно, что недолёт на SCL кажется больше, чем недолёт на SDA, особенно учитывая различные вертикальные шкалы между сигналами SCL и SDA на последний след. Я бы все-таки предложил в конце концов исследовать, что SCL не срабатывает, но я не верю, что это связано с основной проблемой.)
На SDA есть два «глюка»:
Сбои непосредственно перед или сразу после импульса ACK не редкость, когда ведущий I²C освобождает контроль над SDA, чтобы позволить ведомому устройству выполнить ACK, а затем мастер может снова перезапустить SDA. Поэтому я игнорирую это.
Это ранний глюк SDA, перед первым импульсом SCL, который является более необычным. По амплитуде этого раннего сбоя SDA (см. Далее) и того факта, что это происходит только до того первого импульса SCL (обозначено 0), но не происходит до более поздних импульсов SCL, когда мы могли бы видеть сбой на SDA (например, SCL). импульсы, помеченные 4, 5, 6 или 7), мы знаем, что это не артефакт измерения и не связь с SCL (например).
(Для дальнейшего использования ранний сбой SDA выглядит как минимум 2 В на последней трассе, поэтому при Vdd при 3,6 В из предыдущих комментариев это делает амплитуду сбоя SDA как минимум (2 / 3,6) = 0,55 x Vdd. Сравните это с соответствующие пороговые значения логического уровня I2C обсуждаются позже.)
Не обращая внимания на разницу ACK, я полагаю, что вижу еще одно различие между двумя наборами трасс на втором снимке экрана. Амплитуда этого раннего сбоя SDA кажется немного другой, если сравнивать верхнюю кривую SDA, помеченную C1(желтоватый цвет?), И вторую кривую SDA, помеченную M3(синяя). Теперь я считаю, что различия в амплитуде этого раннего сбоя SDA - вот что может вызвать появление или исчезновение вашей проблемы, как я объясню ниже.
Еще большее разрешение, особенно при сбое, могло бы помочь (это одна из проблем при попытке работать над проблемами «удаленно» - я не могу управлять «прицелом сам!»). Я предполагаю, что когда вы увеличиваете масштаб, это выглядит как начало нормальной логики I²C «1» (то есть кривая RC на переднем фронте, особенно если вы временно делаете подтягивания более слабыми, например, 10k), за исключением того, что это не t достичь полного положительного напряжения, прежде чем оно снова будет приведено к логическому «0». Это то, что показано на другой веб-странице, связанной позже. Если вы видите другую форму вашего глюка, мой более поздний анализ может не подойти.
Мастер I²C контролирует шину в точке этого сбоя, между I²C Start и первым тактовым импульсом SCL (который вы пометили как «0», хотя это MSbit). Это заставило меня с подозрением относиться к поведению MSP430, хотя с низким уровнем SCL в этот момент сбой SDA не должен влиять на устройства, совместимые с I²C, так как они будут ожидать повышения SCL, прежде чем они в следующий раз прочитают состояние SDA.
Итак, действительно ли I²C Slave соответствует I²C? Оказывается, ZSC31014 " суетливый " и менее терпимый, чем некоторые другие устройства I2C , именно тогда, когда я считаю, что MSP430 производит этот глюк!
В техническом описании ZSC31014 перечислены 3 области, в которых они допускают, что поведение I²C устройства «отличается». На вас также могут повлиять первые два в этом списке в другое время (это не является частью этого анализа), но это третий пункт, который я отметил ниже красным, который связан с этим ранним глюк SDA:
Амплитуда этого раннего сбоя SDA является критической . Если этот сбой недостаточно повышается, чтобы ZSC31014 распознал его как логику «1», прежде чем он снова упадет, то все в порядке - устройство должно увидеть спад на SDA, чтобы нарушить это «правило», и оно может быть только падение край , если он уже был признан в качестве логической «1».
Все, что влияет на амплитуду этого глюка SDA, например, дополнительная нагрузка оптического прицела или логического анализатора на сигнал SDA, может быть достаточным, чтобы помешать глюку, распознаваемому ZSC31014, достигать логической «1» и, следовательно, не «падать». SDA edge ", это третья точка в списке, может возникнуть (в хороший день, в зависимости от напряжения, температуры и т. Д.). Однако, как вы обнаружили, различия между осциллографами достаточно, чтобы означать, что некоторые из них добавляют достаточно нагрузки, чтобы остановить проблему, а другие - нет. Эта настройка должна быть очень маргинальной!
Это подтверждает мое беспокойство по поводу того, что ваши предыдущие «рабочие» партии датчиков могут быть «только-только» работающими, поскольку микроконтроллеры MSP430 на этих «рабочих» настройках, вероятно, также будут давать сбои SDA. Моя теория о возможной разнице между партиями датчиков, которая может объяснить различное поведение, о котором вы сообщили («рабочая» партия и «неработающая» партия), объясняется далее.
Интересно, что ZSC31014 отличается от стандартного I²C в другой области, которая не упомянута в этом списке от производителя, и это может объяснить, почему вы видите разницу между партиями датчиков.
Стандартные пороги логики I²C (упрощенные) - ниже 0,3 x Vdd для логической «0» и выше 0,7 x Vdd для логической «1», как показано в спецификации I²C :
Однако ZSC31014 имеет разные пороги: 0,2 x Vdd и 0,8 x Vdd, что означает, что его «неопределенная область» между этими порогами больше, чем у обычных устройств I²C:
Эта большая «неопределенная область» увеличивает вероятность того, что сбой попадет в неопределенную область уровня напряжения, где он может быть распознан как логическая «1» (помните, что все, что выше 0,2 x Vdd, может быть распознано ZSC31014 как логическая «1»). , поскольку в неопределенной области все разрешено - это только выше 0,8 x Vdd, когда это должно быть распознано как логическая «1»). И, как объяснялось ранее, если ZSC31014 распознает глюк как достигший логической «1», то, когда он снова падает до логической «0», вы нарушили это «правило», помеченное красным для требуемого поведения I²C. по ZSC31014.
Поскольку распознавание логических уровней в этой «неопределенной» области напряжения не указано, производитель датчика не нарушает спецификации, если он делает одну партию, которая распознает логику «1» только тогда, когда она достигает 0,7 x Vdd, но делает другую партию, которая распознает например, логическая «1» всего 0,4 x Vdd. Эта гипотетическая вторая партия, скорее всего, увидит сбой SDA в качестве падающего фронта SDA, что является нарушением этой третьей точки в их списке, но не нарушает их спецификации.
(Многие из проблем, над которыми я работал на протяжении многих лет, были такими: есть два устройства, ни одно из которых не нарушает спецификацию, в которой есть лазейки, - но одно является суетливым и менее терпимым в точке, где другому требуется, чтобы подключенные устройства были более терпимыми из-за своего неясного поведения! Каждое из этих двух устройств прекрасно взаимодействует с большинством других устройств, но ненадежно (или полностью выходит из строя) при подключении друг к другу.)
Так что ты можешь сделать? Я думал о двух вариантах:
Не используйте MSP430 - используйте другой MCU, который не создает такого раннего сбоя SDA. Однако я ожидаю, что вы потратили много времени на программное обеспечение и не хотели бы переносить код на другой MCU, если этого можно избежать.
«Бит-бэнг» протокола I²C на MSP430 вместо использования встроенного аппаратного модуля I²C. Таким образом, вы полностью контролируете сигналы I²C и можете предотвратить возникновение этого сбоя. Тем не менее, очевидно, что потребуется создать собственные подпрограммы I²C, отладить их, и полученный код может оказаться больше, чем при использовании аппаратного модуля I²C MSP430, что само по себе может стать проблемой, если вам не хватает места во Flash.
Затем я начал искать проблемы MSP430 I²C и обнаружил, что эта комбинация MSP430 + ZSC31014 является известной проблемой из-за раннего сбоя SDA в MSP430! Смотрите эту тему на форуме TI E2E MSP430:
Форум TI E2E: сбой импульсов MSP430 I2C, создающий проблемы для периферийного чипа I2C
Обходное решение, упомянутое там, состоит в том, чтобы изменить адрес I²C ZSC31014 таким образом, чтобы уровень SDA был высоким в тот момент, когда мог произойти положительный сбой , и, поскольку SDA был сделан высоким, то в любом случае фактического сбоя в SDA не было:
Наш обходной путь состоит в том, чтобы сконфигурировать микросхему ZSC, чтобы у нее был адрес с установленным битом 6 (например, мы сейчас используем 0x42) - это превращает импульс сбоя в хороший чистый "старший" бит для длительности адреса 6, который избавляется проблемного спада.
Тот же обходной путь фактически противоположен предложению в техническом описании ZSC31014, в красном поле, которое я отметил. Они говорят, что сбой SDA должен быть предотвращен, если первый бит (который является MSbit) адреса I²C ZSC31014 равен 0 - так что не делайте MSbit адреса I²C "0", вместо этого сделайте его "1", т.е. установите бит 6 в 7-битном адресе I²C!
Так как эта ветка форума TI E2E и таблица данных ZSC31014 фокусируются на адресе I²C, то, возможно, либо сбой SDA не возникает, либо не является проблемой, если он возникает, во время отправки других данных по шине. Вам нужно будет исследовать это.
Поэтому, игнорируя первый обходной путь использования другого MCU, два (более практичных) обходных пути:
- Ударьте по шине MSP430 I²C, написав свой собственный код, чтобы вы не создавали этот глюк на SDA, или
- Измените адрес I²C ZSC31014 таким образом, чтобы был установлен бит 6 его 7-битного адреса, что означает, что SDA уже имеет высокий уровень, когда в противном случае возникнет сбой, поэтому на SDA не возникает фактический сбой при обращении к ZSC31014 (при условии, что сбой SDA либо не происходит после других событий I²C Start во время передачи данных, или, если они происходят, ZSC31014 не «расстраивается»).
Надеюсь, это поможет!
