Ben düşünüyorum ben cevabı buldum. Bu bilinen bir sorun olduğu ortaya çıktı, ama sadece sorunun nerede olduğuna karar verdikten sonra buldum ve bunu aradım!
İşte yaşadığım süreç, bunu takip edebilirsiniz (ve gerekirse varsayımlarımdan farklı sonuçlar görürseniz araştırmanızı uyarlayabilirsiniz). Sonuç olarak, MSP430 I²C davranışı ile I²C Slave, IDT ZSC31014 olduğundan şüphelendiğiniz aygıtın gerekli I²C davranışı arasında (en azından bir miktar) uyumsuzluk olduğu görülüyor . Bu cihazın veri sayfasına sahip olmak, bunu anlamak için çok önemlidir, bu yüzden bulduğunuz için teşekkür ederiz.
İyi haber şu ki, bu sorun için en azından açıklayacağım (en azından) 2 geçici çözüm var.
Çizim kalınlaşır, farklı bir osiloskop bağlamanın devrenin doğru çalışmasını sağlamaz ve tek farkın bir ACK'nın iletilmemesi olduğu görülebilir.
Yeni izler faydalı, teşekkürler, onları biraz farklı yorumlasam da.
(İlk izlemede beni ilgilendiren SCL sinyal altlığı hala en son izde var. SCL'deki alt sürgünün, özellikle SCL ve SDA sinyalleri arasındaki farklı dikey ölçekler göz önüne alındığında, SDA'daki alt süreden daha büyük görünmesi ilginç. Yine de SCL'nin nihayetinde altını çizdiğini araştırmayı öneririm, ancak ana sorunla ilgili olduğuna inanmıyorum.)
SDA'da bu iki "aksaklık" vardır:
Bir I²C Master, bir Slave'in ACK'yi gerçekleştirmesine izin vermek için SDA'nın kontrolünü serbest bıraktığında ve ardından Master SDA'yı tekrar sürdüğünde ACK darbesinin hemen öncesinde veya hemen sonrasında meydana gelen bir aksaklık nadir değildir. Bu yüzden bunu görmezden geliyorum.
Öyle erken daha sıradışı olan, ilk SCL darbesi öncesinde, SDA aksaklık. Bu erken SDA aksaklığının genliğinden (daha sonra bakınız) ve sadece bu ilk SCL darbesinden (0 olarak etiketlenmiş) önce gerçekleşmesi gerçeğinden, ancak SDA'da bir aksaklık (SCL gibi) görebileceğimiz daha sonraki SCL darbelerinden önce gerçekleşmez. 4, 5, 6 veya 7 etiketli darbeler), bunun bir ölçüm artefaktı olmadığını veya SCL'den bir bağlanma olmadığını biliyoruz (örneğin).
(Daha sonra başvurmak üzere, erken SDA aksaklığı en son izlemede en az 2V gibi görünür , bu nedenle önceki yorumlardan 3.6V'de Vdd ile SDA aksaklık genliğini en az (2 / 3.6) = 0.55 x Vdd yapar. ilgili I2C mantık düzeyi eşikleri daha sonra ele alınacaktır.)
ACK farkını göz ardı ederek, ikinci ekran görüntüsünde iki iz kümesi arasında başka bir fark gördüğüme inanıyorum. Erken SDA aksaklığının genliği, etiketli üst SDA izi C1(sarı-ish?) Ve etiketli 2. SDA izi M3(mavi) ile karşılaştırıldığında biraz farklı görünmektedir . Şimdi, aşağıda açıkladığım gibi, erken SDA aksaklığının genliğindeki farklılıkların, sorunun ortaya çıkmasına veya kaybolmasına neden olabileceğine inanıyorum.
Özellikle aksaklık üzerinde daha fazla çözünürlük yardımcı olacaktır (bu "uzaktan" sorunlar üzerinde çalışmaya çalışırken sorunun biridir - Ben 'kapsamı kendim çalıştıramazsınız!). Yakınlaştırdığınızda, normal bir I²C mantığı "1" in başlangıcına benzediğini varsayacağım (yani yükselen kenarda bir RC eğrisi, özellikle de çekmeleri geçici olarak zayıflatıyorsanız, örneğin 10k). t Tekrar "0" mantığına geçmeden önce tam pozitif gerilime ulaşın. Daha sonra bağlanan başka bir web sayfasında gösterilen şey budur. Aksaklığınızda farklı bir şekil görürseniz, sonraki analizim geçerli olmayabilir.
I²C Master, I²C Start ile ilk SCL saat darbesi (MSbit olmasına rağmen "0" olarak adlandırdığınız) arasındaki aksaklık noktasında veri yolunu kontrol eder. Yani bu noktada SCL düşük olan rağmen, bir SDA aksaklık, MSP430 davranış beni şüpheli yapılmış olmamalı onlar sonraki SDA durumunu okumadan önce yüksek gitmeye SCL bekliyor olacak şekilde, I²C uyumlu cihazlar etkiler.
Peki, I²C Slave gerçekten I²C uyumlu mu? Görünüşe göre, ZSC31014 " telaşlı " ve diğer I²C cihazlarından daha az toleranslı, tam da MSP430'un bu aksaklığı ürettiğine inandığımda!
ZSC31014 veri sayfası onlar aygıtın I²C davranışını itiraf listeleri 3 alanlar "farklı" dir. Ayrıca, bu listedeki ilk ikisinden başka zamanlarda da etkilenebilirsiniz (bu analizin bir parçası değildir), ancak aşağıda kırmızı olarak işaretlediğim ve bu erken SDA aksaklığıyla ilgili üçüncü nokta:
Bu erken SDA aksaklığının genliği kritiktir . Bu aksaklık, ZSC31014 tarafından tekrar düşmeden önce mantıksal "1" olarak tanınacak kadar yükselmezse, sorun olmaz - cihaz, bu "kuralı" kırmak için SDA'da düşen bir kenar görmelidir ve yalnızca bir düşme zaten mantıksal bir "1" olarak kabul edilmiştir, kenar.
SDA sinyalinin genliğini etkileyen her şey, örneğin SDA sinyalindeki bir 'kapsam veya mantık analizörünün ek yükü gibi, aksaklığın ZSC31014 tarafından bir mantığa "1" ulaştığı olarak tanınmasını durdurmak için yeterli olabilir ve bu nedenle "düşmemesi" SDA kenarı ", listede üçüncü nokta olabilir (iyi bir günde, gerilimlere, sıcaklıklara vb. Bağlı olarak). Ancak, bulduğunuz gibi, farklı osiloskoplar arasındaki varyasyon, bazılarının sorunu durdurmak için yeterli yük eklediği ve diğerlerinin yapmadığı anlamına gelir. Bu kurulum çok marjinal olmalı!
Bu, önceki "çalışan" sensör gruplarınızın "sadece" çalışıyor olabileceğinden endişe duymamı sağlıyor, çünkü bu "çalışan" kurulumlardaki MSP430 MCU'ları da muhtemelen SDA hataları üretecek. Daha sonra bildirdiğiniz farklı davranışı ("çalışma" grubu ile "çalışmayan" grubu) açıklayabilecek sensör grupları arasındaki olası bir fark hakkındaki teorim daha sonra açıklanmaktadır.
İlginç bir şekilde, ZSC31014, üreticiden bu listede belirtilmeyen başka bir alanda standart I²C'den farklıdır ve bu, sensör grupları arasında neden bir fark gördüğünüzü açıklayabilir.
Standart I²C mantık eşikleri (basitleştirilmiş) - I²C spesifikasyonunda gösterildiği gibi "0" mantığı için 0,3 x Vdd'nin altında ve "1" mantığı için 0,7 x Vdd'nin üzerindedir :
Bununla birlikte, ZSC31014'ün farklı eşikleri vardır, 0.2 x Vdd ve 0.8 x Vdd, yani bu eşikler arasındaki "tanımlanmamış bölgesi" tipik I²C cihazlarından daha büyüktür:
Yani daha büyük "tanımsız bölge" arttırır tanımsız gerilim seviyesi alanına giren aksaklık şansını olabilir mantıksal bir "1" (0.2 x Vdd yukarıdaki şey hatırlamak olarak tanınması olabilir mantıksal bir "1" olarak ZSC31014 tarafından tanınması , tanımlanmamış bölgede her şeye izin verilir - mantık "1" olarak tanınması gerektiğinde yalnızca 0,8 x Vdd'nin üzerindedir ). Ve, gibi daha önce açıklandığı takdirde sorun olması mantık "1" ulaşmış olması olarak ZSC31014 tarafından tanınan, sen I²C davranışı için kırmızı işaretli "kuralı" gerektirdiğini kırdım, o zaman bir mantık "0" tekrar düştüğünde ZSC31014 tarafından.
Bu "tanımlanmamış" gerilim bölgesindeki mantık seviyelerinin tanınması belirtilmediğinden, sensör üreticisi yalnızca "0.7" mantığını tanıyan bir parti yaparsa, yalnızca 0.7 x Vdd'ye ulaşırsa, tanımlayan başka bir parti yaparsa, Örneğin, 0.4 x Vdd kadar düşük bir mantık "1". Bu varsayımsal ikinci partinin, SDA aksaklığını, listelerindeki üçüncü noktaya aykırı olarak düşen bir SDA kenarı olarak görmesi, ancak özelliklerini ihlal etmemesi daha olasıdır.
(Yıllar boyunca üzerinde çalıştığım sorunların birçoğu şöyleydi: İkisi de boşlukları olan bir spesifikasyonu ayrı ayrı kıran iki cihaz var - ancak biri telaşlı ve daha az toleranslı, diğeri , belirsiz davranışlarından dolayı bağlı cihazların daha toleranslı olmasına ihtiyaç duyar ! Bu iki cihazın her biri diğer cihazların çoğuyla iyi bir şekilde bağlantılıdır, ancak birbirine bağlandığında güvenilmez (veya tamamen başarısız).
Peki ne yapabilirsin? İki seçenek düşündüm:
MSP430 kullanmayın - bu erken SDA aksaklığını oluşturmayan başka bir MCU kullanın. Ancak, yazılımda çok fazla zaman harcadığınızı ve bu önlenebilirse, kodu başka bir MCU'ya taşımak istemediğinizi umuyorum.
Dahili I²C donanım modülünü kullanmak yerine MSP430 üzerindeki I²C protokolünü "bit-bang". Bu şekilde, I²C sinyallerinin kontrolü tamamen sizdedir ve bu aksaklığın oluşmasını önleyebilirsiniz. Ancak, kendi I²C rutinlerinizi oluşturmak, hatalarını ayıklamak ve sonuçta ortaya çıkan kod MSP430 I²C donanım modülünü kullanmaktan daha büyük olabilir, bu da Flash alanınız azsa kendiniz bir sorun olabilir.
Sonra MSP430 I²C sorunlarını aramaya gittim ve MSP430 + ZSC31014'ün bu kombinasyonunun MSP430'daki bu erken SDA aksaklığı nedeniyle bilinen bir sorun olduğunu buldum! Bu konuya TI E2E MSP430 forumunda bakın:
TI E2E forumu: I2C çevre çipi için soruna neden olan MSP430 I2C aksaklık darbeleri
Geçici çözüm, SDA pozitif aksaklık zamanda yüksek olacak şekilde ZSC31014 I²C adresini değiştirmek orada bahsedilen olabilir , meydana ve SDA sonra yine yüksek yapılmış olduğundan, hiçbir orada gerçek SDA aksaklık:
Geçici çözümümüz, ZSC yongasını 6 bitlik biti ile bir adrese sahip olacak şekilde yapılandırmaktır (örneğin, şimdi 0x42 kullanıyoruz) - bu, aksaklık darbesini, adres biti 6 süresi için güzel bir temiz "yüksek" bite dönüştürür. sorunlu düşme kenarı.
Aynı geçici çözüm, ZSC31014 veri sayfasındaki, işaretlediğim kırmızı kutudaki öneriyi tersine çevirir. ZSC31014 I²C adresinin ilk biti (MSbit olan) 0 ise bir SDA aksaklığının önlenmesi gerektiğini söylüyorlar - bu yüzden I²C adresinin MSbit'ini "0" yapmayın, bunun yerine "1" yapın. 7 bitlik I²C adresinde bit 6'yı ayarlayın!
Bu TI E2E forum iş parçacığı ve ZSC31014 veri sayfası I²C adresine odaklandığından, belki de SDA aksaklığı oluşmaz veya veri yoluna başka verilerin gönderilmesi sırasında bir sorun olmaz. Bunu araştırman gerekecek.
Bu nedenle, farklı bir MCU kullanmanın ilk geçici çözümünü yok sayarak, iki (daha pratik) geçici çözüm şunlardır:
- SDP'de bu aksaklığı oluşturmamak için MSP430 I²C veri yolunu kendi kodunuzu yazarak bitirin veya
- ZSC31014 I²C adresini 7 bitlik adresinin 6 biti ayarlanacak şekilde değiştirin; bu, aksaklık meydana geldiğinde SDA'nın zaten yüksek olduğu anlamına gelir, bu nedenle ZSC31014 adreslendiğinde SDA'da gerçek bir aksaklık olmaz (bir SDA aksaklığının veri aktarımı sırasında diğer I²C Start olaylarından sonra gerçekleşmezse veya gerçekleşirse, ZSC31014 "üzülmez").
Umarım yardımcı olur!
