Ідентифікована адреса невідомого I2C (іноді)

Я намагаюся спілкуватися з віддалено підключеною FRAM (FM24C04 від Ramtron) за допомогою I2C. Ця пам'ять вбудована у плату, яку можна вставити та вилучити в будь-який час до системи / з неї (зв’язок належним чином припиняється до вилучення пам'яті).

Проблема полягає в тому, що після вставки карти, яка містить FRAM, іноді вона не підтверджує адресу.

Вимірювання сигналів

Я виміряв сигнали, щоб побачити, що відбувається, і здається, що в обох випадках час працює нормально (працює і не працює).

Правильна комунікація I2C (читання в 3 байти):

Адреса FR2 I2C не підтверджена (адреса підлеглого коректно відправлена):

Дії, вже зроблені для вирішення цього питання (без успіху)

• Затримка додається після вставки картки із вбудованою FRAM, щоб забезпечити дотримання послідовності живлення.
• I2C зупинка генерації після виявлення невідомої адреси не підтвердження

Конфігурація шини I2C

• Один мастер (мікроконтролер STM32F205 від ST)
• Три раби (EEPROM 24AA1025 від Microchip, RTC DS1339C від Maxim IC та віддалений FRAM FM24C04 від Ramtron
• Один перемикач рівня I2C (MAX3373E від Maxim IC) використовується для забезпечення зв'язку між ведучим та FRAM
• Частота шини встановлена ​​на 100 кГц

ВИДАЛЕНО (2013-04-17)

По-перше, дякую всім за ваші коментарі.

Оскільки є багато пропозицій, ось опис розслідувань, які я робив.

Схематика

На наступному малюнку представлена ​​спрощена схема шини I2C:

Сигнали I2C_SDA і I2C_SCL безпосередньо з'єднані з мікроконтролером, а сигнали FRAM_SDA і FRAM_SCL підключені до FRAM. Зауважте, що сигнали SDA та SCL, підключені до FRAM, фільтруються за допомогою феритів BLM18 з Мурата.

FRAM підключений наступним чином:

• NC (контакт 1) -> не підключено
• A1 (контакт 2) -> GND
• A2 (контакт 3) -> GND
• VSS (контакт 4) -> GND
• ПДД (контакт 5) -> FRAM_SDA
• SCL (контакт 6) -> FRAM_SCL
• WP (контакт 7) -> GND (не захищено від запису)
• VDD (контакт 8) -> + 5V

Опис картки FRAM

Ця карта - це карта "схожа на ISA", в яку вбудовується лише ОЗУ.

Розслідування

Уповільнення частоти

Я проводив тести з частотою SCL, встановленою на 50 кГц і 10 кГц. Я вимірював сигнал SCL за допомогою осцилографа, щоб переконатися, що він був на очікуваній частоті.

Ці зміни не вирішили проблему. Я перевірив терміни, і вони знаходяться в специфікаціях даних FRAM.

Забезпечення послідовності живлення

@jippie.

1. Перемикач рівня I2C переводиться в режим три стану перед тим, як вставлена ​​карта, в яку вбудована FRAM. Сигнали FRAM_SDA і FRAM_SCL знижуються низько.
2. Після того, як "карта FRAM" вставлена, додається затримка на 100 мс для того, щоб забезпечити стабілізацію живлення (потрібно не менше 11 мс до першого стану запуску згідно з таблицею даних).
3. Активований перемикач рівня I2C.
4. Затримка на 1 мс додається для того, щоб забезпечити активацію перемикача рівня I2C і підтягування ліній (~ 4us, необхідних для даних). Сигнали FRAM_SDA і FRAM_SCL підтягуються.
5. FRAM доступний.

Сигнали FRAM_SDA та FRAM_SCL вимірювались після кожного кроку.

Проблема все ще виникає.

Умова зупинки / запуску замість повторного запуску

@gbarry.

Я намагався зупинити перед повторним запуском під час передачі байтів. Я виміряв передачу байтів за допомогою осцилографа: стан STOP з наступною умовою START добре.

На жаль, це рішення не вирішує проблему.

Думки

Ця проблема виникає лише після того, як підключена карта, в яку вбудована FRAM. Після того, як "карта FRAM" вставлена ​​і правильно адресована, я запустив кілька тисяч успішного доступу для читання (адресація і читання рабів).

Для мене це все більше нагадує технічну проблему. Але я не знаю, чи це може бути пов'язано з перемикачем рівнів I2C або з іншими рабами на шині I2C.

Чи є у вас інші ідеї чи пропозиції?

ВИДАЛЕНО (2013-04-18)

Здається, проблема вирішена

Я замінив роз'єм модуля FRAM і знайшов спосіб зробити вимірювання безпосередньо на FRAM. Здається, що все добре працює з цим новим роз'ємом.

Я зроблю більше тестів для того, щоб переконатися, що проблема виникла з-за поганого зв’язку.

Незважаючи на те, що ви кажете, що ваші комунальні послуги належним чином припинені перед вставкою чи видаленням, можливо, варто спробувати це рішення, оскільки існує ситуація, коли шина I2C може викликати проблеми після скидання лише одного з пристроїв на шині.

Перш ніж ініціалізувати апаратне забезпечення Master I2C, встановіть SDA як вхідний і тестовий показник для SDA.

Якщо він низький, тоді встановіть штифт SCL високим.

Потім перемикайте штифт SCL низьким і високим, поки SDA не підніметься (тобто вимкніть будь-які інші біти, які периферійні пристрої все ще можуть намагатися надіслати). Це не може зайняти більше 8 тактових циклів - якщо це так, то виникає якась інша проблема.

Не можу гарантувати, що це вирішить вашу проблему, але це вирішило мою !.

Для FRAM:

• спочатку підключіть GND і Vcc;
• потім переконайтесь, що A1, A2 і WP мають правильний рівень;
• лише потім підключіть шпильки даних.

Підключення інших штифтів, ніж джерело живлення до включення чіпа, може спричинити проблеми.

10k здається трохи більшим для ваших підтягувачів, а ваші передові краї виглядають повільно. Зменшіть резистори до приблизно 3 к і подивіться, чи це допомагає.

Крім того, чому час відключення напруги пливе?

Чи є шанс щось ще спробувати поговорити з цією дошкою? У мене колись була така проблема; Я міг отримати шанс 60% часу, але я не пам'ятаю, щоб коли-небудь побачити зіткнення. Я підозрюю, що i2c, який мені надали, був якимось чином ізольований від реальної внутрішньої шини. Я міг би це виконувати безперервно, і він би просто скинув 30% повідомлень. Проблема зникла з того моменту, як ми почали спілкуватися безпосередньо з пристроєм (джерелом живлення), не втручаючись у «задню планку».

Я не бачу послідовності зупинки після вашої помилки NAK. Я здогадуюсь, у вас є точка розриву, яка зупиняє програму в цей момент?

Нарешті, якщо ви думаєте, що ви єдиний в автобусі, ви можете також спробувати замінити повторний старт на зупинку / старт. Я бачив пристрої (особливо спеціальні FPGA), які не зовсім знали, як поводитися з RS.

[У відповідь на коментар]: Ви багато чого не сказали про плату FRAM, наприклад, чи це просто пам'ять або ціла підсистема. Але якщо ви зможете поставити «сферу дії» на відведення пристрою i2c, що створює проблеми, і ви все ще бачите, що зображено на малюнку, то я б виключав втручання. I2C досить простий, що якщо ви бачите правильні сигнали на вході, то чіп повинен грати належним чином, якщо у нього немає внутрішніх проблем.

Зокрема, ви хочете потрапити на сторону FRAM цього перемикача рівня. Перерва в сигналі скоріше, ніж щось трапляється, що, як правило, вважається зіткненням.

Я зазначу, що цикл NAK не відрізняється від чіпа, якого просто немає. EEPROM будуть робити це, щоб вказати, що вони зайняті. Я подивився час запису на FRAM, і це швидше, ніж один біт даних i2c ... так що це не проблема.

Оскільки проблема, коли вона відтворюється, - це постійна несправність, яка усувається лише видаленням та повторною вставкою пристрою, то це одна з двох речей: пристрій переходить у поганий стан, з якого він відновлює лише цикл живлення, або контакт поганий.

Якщо пристрій перебуває в поганому стані, від якого він відновлюється на циклі живлення, ви можете мати додатковий ланцюг, який дозволяє вашому MCU живити пристрій. Потім прошивка, не отримавши підтвердження від пристрою, може виконати процедуру відновлення, за допомогою якої він деякий час вимикає чіп, включає його знову, а потім повторює спробу.

Якщо це поганий контакт, то, можливо, вам доведеться подивитися на надійність роз’єму і знайти щось краще. Якщо ви використовуєте один і той же роз'єм для виготовлення більшої кількості цих плат, в полі можуть виникнути проблеми. У будь-якому випадку може бути людська процедура вирішення ситуації. Оператор, що працює з пристроєм, повинен знати про можливу проблему із вставкою картки та про те, що для правильної роботи її, можливо, доведеться пересадити.

На вашому головному пристрої може бути встановлено сигнал тривоги, що вказує на те, що він не може говорити з FRAM: світлодіод "неприємності" на панелі та / або звуковий сигнал або інше. Або ж зворотне: деяке світло загорається, даючи відгуки користувача про те, що FRAM прийнято і спілкування налагоджене. Якщо FRAM знаходиться далеко від головного пристрою, світло може розташовуватися на модулі FRAM: інший мікросхем I2C, який приводить в дію світлодіод.

Спорадичний характер проблеми припускає, що це може бути проблемою в часі.

У таблиці даних перелічено два набори синхронізації, один для "Стандартний режим" і один для "Швидкий режим". З ваших вимірювань здається, що ви перебуваєте на межі таймінгів "Стандартного режиму". Я не можу сказати зі скими даних, як саме чіп переведений в будь-який режим.

Я б не припускав, що ваш пристрій знаходиться у швидкому режимі. Чи можете ви зменшити таймінги в 2–4, переконайтесь, що ви знаходитесь в стандартних режимах часу для режиму запуску, високого тактового періоду та низького тактового періоду та побачите, чи ця проблема все-таки виникає?

Ви hv a 24c04a, b або c? Якщо це c04a, це був надійний дизайн. Частина b має чутливість до пандусів живлення. Яку розв'язку робити у hv на pin8 для gnd? Я збирався сказати щось про рівень сигналу, але я бачу, що ви використовуєте перекладач рівня. Можливо, ви хочете перевірити, що у вас не виникає збоїв на SCL, що мікросхема інтерпретується як додатковий годинник.