Я думаю , що знайшов відповідь. Виявляється, це відома проблема, але я лише виявив, що після того, як я вирішив, де проблема, і шукав її!
Ось процес, який я пройшов, тож ви можете прослідкувати за ним (і, якщо необхідно, ви зможете адаптувати своє дослідження, якщо побачите результати, які відрізняються від моїх припущень). Суть полягає в тому, що, мабуть, існує несумісність між (принаймні деякою) поведінкою MSP430 I²C і необхідною поведінкою I²C пристроєм, яким ви підозрюєтесь, що є Slave I²C, IDT ZSC31014 . Наявність таблиці для цього пристрою має вирішальне значення для розуміння цього, тому дякую, що знайшли його.
Хороша новина полягає в тому, що для цієї проблеми (щонайменше) є два обходи, які я поясню наприкінці.
Діаграма згущується, виявляється, що підключення іншого осцилоскопа не змушує схему працювати належним чином, і видно, що різниця полягає лише в тому, що ACK не передається.
Нові сліди корисні, дякую, хоча я трактую їх дещо інакше.
(Сигнал підкреслення SCL, який стосувався мене на початковому сліді, все ще присутній на останньому сліді. Цікаво, що нижня стрілка на SCL здається більшою, ніж нижня стрілка на SDA, особливо враховуючи різні вертикальні шкали між сигналами SCL та SDA на Останній слід. Я б все-таки запропонував дослідити, що SCL підкреслює, врешті-решт, але я не вважаю, що це пов'язано з основною проблемою.)
Є два "глюки" в SDA:
Збій безпосередньо перед імпульсом АСК або безпосередньо після нього не є рідкістю, коли майстер ІСС звільняє управління ПДР, щоб дозволити Рабу виконувати АСК, а потім Ведучий може знову запустити ПДР. Тому я ігнорую це.
Саме ранній зліт SDA, перед першим імпульсом SCL, є більш незвичним. З точки зору амплітуди цього раннього виходу ПДР (див. Пізніше) і того, що він виникає лише до цього першого імпульсу SCL (позначений 0), але не виникає перед пізнішими імпульсами SCL, де ми могли б побачити збої в SDA (як SCL імпульси з міткою 4, 5, 6 або 7), ми знаємо, що це не артефакт вимірювання, а не з'єднання з SCL (наприклад).
(Для подальшого ознайомлення, ранній глюк ПДД нагадує щонайменше 2 В за останнім слідом, тому з Vdd на 3,6 В з попередніх коментарів, це робить амплітуду збою від ПДР принаймні (2 / 3,6) = 0,55 х Vdd. Порівняйте це з відповідні пороги логічного рівня I2C, обговорені пізніше.)
Ігноруючи різницю ACK, я вважаю, що я бачу ще одну різницю між двома наборами слідів на другому скріншоті. Амплітуда цього раннього глюка ПДД здається дещо іншою, порівнюючи верхній слід ПДР C1(жовто-іш?) Та 2-й слід СДД M3(синій). Зараз я вважаю, що відмінності в амплітуді ранніх проблем ПДР - це те, що може спричинити появу або зникнення вашої проблеми, як я пояснюю нижче.
Ще більша роздільна здатність конкретно про глюк допомогла б (це одна з проблем у спробі працювати над проблемами "віддалено" - я не можу керувати "сферою себе!"). Я припускаю, що коли ви збільшуєте масштаб, це виглядає як початок нормальної ²C логіки "1" (тобто RC-крива на висхідній грані, особливо якщо ви тимчасово зробите підтяжки слабкішими, наприклад, 10 к), за винятком того, що це не ' t досягти повної позитивної напруги, перш ніж вона знову буде переведена на логіку "0". Це те, що показано на іншій веб-сторінці, пов’язаній пізніше. Якщо ви бачите різну форму вашого глюку, то мій пізній аналіз може не застосовуватися.
Майстер I²C контролює шину в точці цієї глюки, між початком I²C та першим тактовим імпульсом SCL (який ви позначили "0", хоча це MSbit). Це змусило мене підозріло ставитися до поведінки MSP430, хоча при низькому рівні SCL в цей момент глюк ПДД не повинен впливати на пристрої, сумісні з I²C, оскільки вони будуть чекати, коли SCL підніметься до того, як наступний раз прочитає стан SDA.
Отже, чи справді I²C Slave дійсно сумісний з IC? Виявляється, ZSC31014 є " метушливим " та менш толерантним, ніж деякі інші пристрої I²C , саме в той час, коли я вважаю, що MSP430 виробляє цю проблему!
У ZSC31014 листках перераховані 3 областей , в яких вони допускають поведінку I²C пристроїв є «іншими». На вас також можуть вплинути перші два в цьому списку в інші часи (це не є частиною цього аналізу), але це третій пункт, який я позначив нижче червоним кольором, який пов'язаний з тим раннім глюком ПДР:
Амплітуда цього раннього глюку ПДД є критичною . Якщо цей глюк не зростає достатньо, щоб ZSC31014 був визнаний логікою "1", перш ніж він знову впаде, тоді ви все в порядку - пристрій повинен бачити падіння на ПДД, щоб зламати це "правило", і це може бути тільки падіння край , якщо він вже був визнаний в якості логічної «1».
Що-небудь, що впливає на амплітуду цього глюка ПДД, як-от додаткове навантаження 'діапазону чи логічного аналізатора на сигнал SDA, може бути достатньо для того, щоб ZSC31014 не визнавав глюк таким, що досягає логіки "1", а отже, і не "падає" ПДР ", що є третім пунктом у списку, може відбутися (у добрий день, залежно від напруги, температури тощо). Однак, як ви з’ясували, різниця між різними осцилоскопами є достатньою для того, щоб деякі з них додавали достатнього навантаження, щоб зупинити проблему, а інші - ні. Цей параметр повинен бути дуже маргінальним!
Це підтверджує моє занепокоєння, що ваші попередні "робочі" партії датчиків можуть працювати "лише просто", оскільки MCU-модулі 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 х Vdd. Ця гіпотетична друга партія з більшою ймовірністю сприйматиме збій ПДР як падаючу межу ПДР, порушуючи цю третю точку в їхньому списку, але не порушує їх специфікації.
(Багато проблем, над якими я працював протягом багатьох років, були такими: Є два пристрої, жоден з яких не порушує окремо специфікацію, що має лазівки, - але один метушливий і менш толерантний, у точці, де іншому потрібні підключені пристрої, щоб бути більш толерантними через свою незрозумілу поведінку! Кожен з цих двох пристроїв добре взаємодіє з більшістю інших пристроїв, але є ненадійними (або повністю виходять з ладу), коли підключаються один до одного.)
Отже, що ти можеш зробити? Я подумав два варіанти:
Не використовуйте MSP430 - використовуйте інший MCU, який не створює такого раннього глюку SDA. Однак я думаю, що ви вклали багато часу в програмне забезпечення і не хочете перенести код в інший MCU, якщо цього не вдасться уникнути.
"Біт-баг" протокол I²C на MSP430, замість використання вбудованого апаратного модуля I²C. Таким чином, ви повністю контролюєте сигнали I²C і можете запобігти виникненню цих збоїв. Однак, очевидно, буде певна робота над створенням власних підпрограм I²C, їх налагодження, і отриманий код може бути більшим, ніж при використанні апаратного модуля MSP430 I²C, який сам по собі може бути проблемою, якщо вам не вистачає Flash-місця.
Тоді я пішов шукати проблеми MSP430 I²C, і я виявив, що ця комбінація MSP430 + ZSC31014 є відомою проблемою, завдяки тому, що раніше виникли проблеми з ПДР від MSP430! Перегляньте цю тему на форумі TI E2E MSP430:
Форум TI E2E: Імпульси зломлення MSP430 I2C спричиняють проблеми для периферійних мікросхем I2C
Згадане там рішення полягає в тому, щоб змінити ISC-адресу ZSC31014 таким чином, щоб SDA був високим на той момент, коли позитивний глюк міг відбутися, а оскільки SDA підвищений, то в будь-якому разі, в SDA немає фактичних збоїв:
Наше вирішення полягає в тому, щоб налаштувати чіп ZSC на адресу з його набором біт 6 (наприклад, ми зараз використовуємо 0x42) - це перетворює імпульс глюка в приємний чистий "високий" біт для тривалості адреси 6, який позбавляється проблемного падаючого краю.
Це ж рішення фактично є зворотним наведенням на таблицю даних ZSC31014, у червоному полі, яке я позначив. Вони кажуть, що проблему з ПДР слід запобігати, якщо перший біт (що є MSbit) адреси ZSC31014 I²C 0 - тому не робіть MSbit адреси I²C "0", а не "1" встановіть біт 6 у 7-бітній I²C-адресу!
Оскільки цей потік форуму TI E2E та таблиця даних ZSC31014 фокусуються на I²C-адресі, то, можливо, жодний злам SDA не виникає, або це не проблема, якщо він трапляється під час надсилання інших даних по шині. Вам потрібно буде це дослідити.
Тому, ігноруючи перший спосіб використання іншого MCU, два (більш практичні) способи вирішення:
- Біт-треск шини MSP430 I²C, написавши власний код, щоб не створити цей глюк на SDA, або
- Змініть ISC-адресу ZSC31014 таким чином, щоб встановлено біт 6 її 7-бітної адреси, це означає, що SDA вже високий, коли б іллют стався в іншому випадку, тому жоден фактичний глюк не виникає в SDA, коли адресовано ZSC31014 (якщо припустити, що і глюк SDA не відбувається після інших запуску подій I²C під час передачі даних, або якщо такий трапляється, ZSC31014 не "засмучується").
Сподіваюся, що це допомагає!
