I2C slave адрес не е потвърден (понякога)

Опитвам се да комуникирам с дистанционно свързан FRAM (FM24C04 от Ramtron) през I2C. Тази памет е вградена в карта, която може да бъде вмъкната и извадена от системата по всяко време (комуникацията е прекратена правилно, преди паметта да бъде премахната).

Проблемът е: Веднага след поставяне на картата, която съдържа FRAM, адреса понякога непотвърдено.

Измервания на сигнала

Измерих сигналите, за да видя какво се е случило и изглежда, че и в двата случая времето е добро (работа и не работа).

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

I2C FRAM адрес не е потвърден (slave адресът е изпратен правилно):

Мерки, вече предприети за решаване на този проблем (неуспешни)

Добавено закъснение след поставяне на карта с вграден FRAM, за да се гарантира, че се спазва последователността на захранването.
I2C спира да генерира, след като разпознава роб адрес, който не е потвърден

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

Един главен (STM32F205 микроконтролер от ST)
Три подчинени (EEPROM 24AA1025 от Microchip, RTC DS1339C от Maxim IC и дистанционното FRAM FM24C04 от Ramtron
Превключвател на ниво I2C (MAX3373E от Maxim IC) позволява комуникация между главното устройство и FRAM
Честотата на шината е настроена на 100 kHz

РЕДАКТИРАНО (17.04.2013 г.)

Първо, благодаря ви много за вашите коментари.

Тъй като има много предложения, ето описанието на изследването, което направих.

Схема

Следващата фигура показва опростена схема на I2C шината:

Сигналите I2C_SDA и I2C_SCL са свързани директно към микроконтролера, а сигналите FRAM_SDA и FRAM_SCL са свързани към FRAM. Имайте предвид, че SDA и SCL сигналите, свързани към FRAM, се филтрират, използвайки Murata BLM18 ферити.

FRAM е свързан, както следва:

NC (щифт 1) -> не е свързан
A1 (щифт 2) -> GND
A2 (щифт 3) -> GND
VSS (щифт 4) -> GND
SDA (щифт 5) -> FRAM_SDA
SCL (щифт 6) -> FRAM_SCL
WP (Пин 7) -> GND (не е защитен от запис)
VDD (щифт 8) -> + 5V

Описание на FRAM картата

Тази карта е "ISA-подобна" карта, в която е вграден само FRAM.

Разследвания

Забавете честотата

Проведох тестове с SCL честота 50kHz и 10kHz. Измерих SCL сигнала с осцилоскоп, за да се уверя, че е с очакваната честота.

Тези промени не решиха проблема. Проверих времената и те са в рамките на спецификациите на листа с данни FRAM.

Осигуряване на текущата последователност

Превключвателят на ниво I2C се поставя в режим на три състояния, преди да се вмъкне картата, в която е вграден FRAM. Сигналите FRAM_SDA и FRAM_SCL се изтеглят ниско.
След поставяне на "FRAM картата", се добавя закъснение от 100 ms, за да се гарантира, че захранването е стабилизирано (изисква се поне 11 ms преди първото стартово условие според листа с данни).
Активиран е превключвателят на ниво I2C.
Добавя се закъснение от 1 ms, за да се гарантира, че превключвателят на нивото на I2C е активиран и линиите са изтеглени високо (

4us се изисква според информационния лист). Получават се сигнали FRAM_SDA и FRAM_SCL.

Има достъп до FRAM.

Сигналите FRAM_SDA и FRAM_SCL се измерват след всяка стъпка.

Проблемът все още възниква.

Условие за спиране/стартиране вместо повторно стартиране

Опитах се да спра преди многократното стартиране по време на прехвърлянето на байта. Измерих прехвърлянето на байтове с осцилоскоп: условието СТОП, последвано от условието СТАРТ, е ОК.

За съжаление това решение не решава проблема.

мисли

Този проблем възниква само след свързване на картата, вградена във FRAM. Извърших няколко хиляди успешни достъпа до четене (адресиране и четене на подчинени устройства), след като "FRAM картата" беше поставена и правилно адресирана.

Все повече ми звучи като хардуерен проблем. Не знам обаче дали това може да е свързано с превключвателя на нивото на I2C или другите подчинени на I2C шината.

Имате ли други идеи или предложения?

РЕДАКТИРАНО (18.04.2013 г.)

Проблемът изглежда решен

Размених конектора на модула FRAM и намерих начин да направя измервания директно на FRAM. Изглежда, че всичко работи добре с този нов конектор.

Ще направя още тестове, за да се уверя, че проблемът се дължи на лоша връзка.

Въпреки че казват, че комуникациите ви са били правилно изключени преди да бъдат вмъкнати или премахнати, това решение може да си струва да се опита, защото I2C шината може да причини проблеми само на едно от устройствата в шината след нулиране.

Преди да инициализирате главния хардуер I2C, задайте SDA като вход и проверете дали SDA е нисък.

Ако е ниско, поставете SCL щифта високо.

След това превключете SCL щифта на нисък и висок, докато SDA стане висок (т.е. премахнете останалите битове, които периферните устройства все още се опитват да изпратят). Това не може да отнеме повече от 8 цикъла на часовника. Ако е така, тогава има друг проблем.

Не мога да гарантирам, че това ще реши проблема ви, но той реши моя!

Първо свържете GND и Vcc.
След това се уверете, че A1, A2 и WP са на правилното ниво.
Едва след това изводите за данни се свързват.

Свързването на щифтове, различни от захранването, преди включване на чипа може да доведе до проблеми.

10k изглежда малко голямо за вашите набирания, а предните ви ръбове изглеждат бавни. Намалете съпротивленията до около 3k и вижте дали това помага.

Защо напрежението на изключване се отклонява с течение на времето?

Има ли шанс нещо друго да се опитва да говори с този съвет? Веднъж имах такъв проблем; Можех да получа потвърждение 60% от времето, но не помня да съм виждал сблъсък. Подозирам, че i2c, който ми беше предоставен, беше някак изолиран от реалната вътрешна шина. Можех да го стартирам непрекъснато и ще изтрие само 30% от съобщенията. Проблемът изчезна в момента, в който говорихме директно с устройството (захранване), без „задната платка“ между тях.

След вашата грешка в NAK няма да се показва последователност на спиране. Предполагам, че имате точка на прекъсване, която спира програмата в този момент?

Ако смятате, че сте единственият в автобуса, можете също да опитате да замените повторения старт със спирка/старт. Виждал съм устройства (особено персонализирани FPGA), които не са знаели как точно да се справят с RS.

[Отговор на коментар]: Има много неща, които не сте казали за FRAM картата, например дали това е само памет или цяла подсистема. Но ако можете да поставите прицела директно върху кабелите на i2c устройството, което ви създава проблеми и все още можете да видите какво е на снимката, бих изключил намеса. I2C е толкова прост, че освен ако нямате вътрешен проблем, чипът трябва да играе правилно, ако видите правилните сигнали на входа.

По-специално, искате да стигнете до страницата FRAM на този нивелир. Прекъсването в сигнала е по-вероятно от нещо, което обикновено се разглежда като сблъсък.

Ще отбележа, че цикълът на NAK не може да се различи от чип, който просто го няма. EEPROM правят това, за да покажат, че са заети. Потърсих времето за запис на FRAM и е по-бързо от единичен бит за данни i2c. така че това не е проблем.

Тъй като проблемът с възпроизвеждането е постоянна грешка, която може да бъде отстранена само чрез премахване и повторно поставяне на устройството, това е едно от двете неща: Устройството е в неизправно състояние, от което се възстановява само когато е изключено и включено . или има лош контакт.

Ако устройството премине в лошо състояние, след като се изключи и включи, можете да имате допълнителни схеми, които вашият MCU може да използва, за да изключи устройството. След като не получи потвърждение от устройството, фърмуерът може да извърши процес на възстановяване, при който за известно време изключва чипа, включва го отново и след това опитва отново.

Ако контактът е лош, може да се наложи да проверите надеждността на конектора и да намерите нещо по-добро. Използването на един и същ конектор, за да направите повече от тези карти, може да причини проблеми на полето. И в двата случая може да има човешки процес за справяне със ситуацията. Операторът, работещ с устройството, трябва да е наясно с потенциалния проблем с поставянето на картата и може да се наложи да бъде поставен отново, за да функционира правилно.

Вашето основно устройство може да активира аларма, показваща, че не може да говори с FRAM: светодиод "грешка" на контролния панел и/или звуков сигнал или каквото и да било. Или обратното: светлина, която светва и дава на потребителя обратна връзка, че FRAM е приет и комуникацията е установена. Ако FRAM е далеч от главното устройство, светлината може да бъде на FRAM модула: друг I2C чип, който задвижва светодиод.

Спорадичният характер на проблема предполага, че това може да е проблем с времето.

Информационният лист съдържа две времеви редове, една за "стандартен режим" и една за "бърз режим". От вашите измервания се вижда, че сте на ръба на времето за "стандартен режим". От информационния лист не мога да разбера как точно чипът се поставя в един от двата режима.

Не бих предположил, че устройството ви е в бърз режим. Ако можете да намалите времената с коефициент 2-4, уверете се, че сте в рамките на стандартния режим на времето за начало на условията на задържане, висок период на часовника и нисък период на часовника и проверете дали този проблем продължава?

Имате ли 24c04a, b или c? Ако е c04a, това е здрав дизайн. Част b е чувствителна към рампи за захранване. Кое отделяне имате на Pin8? Исках да кажа нещо за нивата на сигнала, но виждам, че използвате преводач на нива. Може да искате да проверите дали не получавате грешка със SCL, която чипът би интерпретирал като допълнителен часовник.