Saya pikir saya sudah menemukan jawabannya. Ternyata ini adalah masalah yang diketahui, tetapi saya hanya menemukan bahwa setelah saya memutuskan di mana masalahnya, dan mencari itu!
Ini adalah proses yang saya lalui, sehingga Anda bisa mengikutinya (dan, jika perlu, Anda bisa menyesuaikan investigasi Anda jika Anda melihat hasil yang berbeda dari asumsi saya). Intinya adalah bahwa tampaknya ada ketidakcocokan antara (setidaknya beberapa) perilaku MSP430 I²C, dan perilaku I²C yang diperlukan oleh perangkat yang Anda curigai sebagai Slave I²C, IDT ZSC31014 . Memiliki lembar data untuk perangkat itu sangat penting untuk memahami hal ini, jadi terima kasih telah menemukannya.
Berita baiknya adalah ada (setidaknya) 2 solusi untuk masalah ini, yang akan saya jelaskan di bagian akhir.
Plot mengental, tampaknya menghubungkan osiloskop yang berbeda tidak membuat sirkuit berfungsi dengan benar, dan dapat dilihat bahwa satu-satunya perbedaan adalah bahwa ACK tidak sedang dikirim.
Jejak baru sangat membantu, terima kasih, meskipun saya menafsirkannya sedikit berbeda.
(Undershoot sinyal SCL, yang membuat saya khawatir pada jejak awal, masih ada pada jejak terbaru. Sangat menarik bahwa undershoot pada SCL tampaknya lebih besar daripada undershoot pada SDA, terutama mengingat skala vertikal yang berbeda antara sinyal SCL dan SDA pada jejak terbaru. Saya masih akan menyarankan untuk menyelidiki bahwa undershoot SCL pada akhirnya, tapi saya tidak percaya itu terkait dengan masalah utama.)
Ada dua "gangguan" di SDA:
Glitch tepat sebelum atau sesaat setelah pulsa ACK tidak jarang, ketika Master I²C melepaskan kontrol SDA untuk memungkinkan Slave untuk melakukan ACK dan kemudian Master mungkin kembali drive SDA lagi. Karena itu saya mengabaikan yang itu.
Ini adalah kesalahan SDA awal , sebelum denyut SCL pertama, yang lebih tidak biasa. Dari amplitudo kesalahan SDA awal (lihat nanti) dan fakta itu terjadi hanya sebelum pulsa SCL pertama (berlabel 0), tetapi tidak terjadi sebelum pulsa SCL nanti di mana kita akan dapat melihat kesalahan pada SDA (seperti SCL pulsa berlabel 4, 5, 6 atau 7), kita tahu itu bukan artefak pengukuran, atau kopling dari SCL (misalnya).
(Untuk referensi kemudian, kesalahan SDA awal terlihat seperti setidaknya 2V dalam jejak terbaru, sehingga dengan Vdd pada 3.6V dari komentar sebelumnya, yang membuat amplitudo kesalahan SDA setidaknya (2 / 3.6) = 0,55 x Vdd. Bandingkan dengan ambang batas tingkat logika I2C yang relevan dibahas nanti.)
Mengabaikan perbedaan ACK, saya percaya saya melihat perbedaan lain antara dua set jejak di screenshot kedua. Amplitudo kesalahan SDA awal itu tampak sedikit berbeda, membandingkan jejak SDA atas berlabel C1(kuning-ish?) Dan jejak SDA ke-2 berlabel M3(biru). Saya sekarang percaya bahwa perbedaan amplitudo dari kesalahan SDA awal, adalah apa yang dapat menyebabkan masalah Anda muncul atau menghilang, seperti yang saya jelaskan di bawah ini.
Bahkan lebih banyak resolusi secara khusus tentang kesalahan akan membantu (itu adalah salah satu masalah dalam mencoba mengatasi masalah "jarak jauh" - Saya tidak dapat mengoperasikan lingkup 'sendiri!). Saya akan berasumsi bahwa ketika Anda memperbesar, sepertinya awal dari logika I²C normal "1" (yaitu kurva RC di tepi naik, terutama jika Anda sementara membuat pull-up lebih lemah misalnya 10k) kecuali itu tidak t mencapai tegangan positif penuh sebelum didorong ke logika "0" lagi. Itulah yang ditampilkan di halaman web lain yang ditautkan nanti. Jika Anda melihat bentuk berbeda untuk kesalahan Anda, maka analisis saya nanti mungkin tidak berlaku.
Master I²C mengendalikan bus pada titik kesalahan itu, antara I²C Start dan pulsa clock SCL pertama (yang telah Anda beri label "0" meskipun MSbit). Itu membuat saya curiga terhadap perilaku MSP430, meskipun dengan SCL rendah pada saat itu, kesalahan SDA seharusnya tidak mempengaruhi perangkat yang sesuai dengan I²C, karena mereka akan menunggu SCL untuk naik tinggi sebelum mereka selanjutnya membaca keadaan SDA.
Jadi, apakah I²C Slave benar - benar sesuai dengan I²C? Ternyata, ZSC31014 adalah " cerewet " dan kurang toleran daripada beberapa perangkat I²C lainnya, tepat pada saat saya percaya MSP430 menghasilkan kesalahan itu!
The ZSC31014 datasheet daftar 3 daerah di mana mereka mengakui perilaku I²C perangkat adalah "berbeda". Anda mungkin juga dipengaruhi oleh dua yang pertama dalam daftar ini di waktu lain (itu bukan bagian dari analisis ini), tetapi itu adalah poin ketiga yang saya tandai di bawah ini dengan warna merah, yang terkait dengan kesalahan SDA awal:
Amplitudo kesalahan SDA awal itu sangat penting . Jika kesalahan itu tidak naik cukup untuk dikenali oleh ZSC31014 sebagai logika "1" sebelum jatuh lagi, maka Anda OK - perangkat harus melihat ujung yang jatuh pada SDA untuk melanggar "aturan" itu dan hanya dapat a jatuh tepi jika telah diakui sebagai logika "1".
Apa pun yang mempengaruhi amplitudo dari kesalahan SDA itu, seperti beban tambahan 'lingkup atau penganalisa logika pada sinyal SDA, mungkin cukup untuk menghentikan kesalahan yang dikenali oleh ZSC31014 sebagai mencapai logika "1" dan karena itu tidak ada "jatuh" Tepi SDA ", titik ketiga dalam daftar, dapat terjadi (pada hari yang baik, tergantung pada voltase, suhu, dll.). Namun, seperti yang Anda temukan, variasi antara osiloskop yang berbeda sudah cukup untuk berarti bahwa beberapa dari mereka menambah beban yang cukup untuk menghentikan masalah, dan yang lain tidak. Pengaturan ini harus sangat marjinal!
Ini menegaskan kekhawatiran saya bahwa kumpulan sensor Anda yang "berfungsi" sebelumnya, mungkin "hanya" bekerja, karena MSP430 MCU pada pengaturan "yang berfungsi" kemungkinan besar juga akan menghasilkan gangguan SDA. Teori saya tentang perbedaan yang mungkin antara kumpulan sensor, yang dapat menjelaskan perilaku berbeda yang telah Anda laporkan (kumpulan "bekerja" vs. kumpulan "tidak bekerja") dijelaskan selanjutnya.
Menariknya, ZSC31014 berbeda dari standar I²C di area lain yang tidak disebutkan pada daftar dari pabrikan, dan ini bisa menjelaskan mengapa Anda tampaknya melihat perbedaan antara kumpulan sensor.
Ambang logika standar I²C adalah (disederhanakan) - di bawah 0,3 x Vdd untuk logika "0", dan di atas 0,7 x Vdd untuk logika "1" seperti yang ditunjukkan dalam spesifikasi I²C :
Namun ZSC31014 memiliki ambang yang berbeda , 0,2 x Vdd dan 0,8 x Vdd, yang berarti bahwa "wilayah tidak terdefinisi" antara ambang tersebut lebih besar daripada perangkat I²C khas:
Yang lebih besar "wilayah terdefinisi" meningkatkan kemungkinan kesalahan yang memasuki area level tegangan undefined, mana mungkin diakui sebagai logika "1" (ingat, apa pun di atas 0,2 x Vdd bisa diakui oleh ZSC31014 sebagai logika "1" , karena di wilayah yang tidak ditentukan, apa pun diizinkan - hanya di atas 0,8 x Vdd ketika harus diakui sebagai logika "1"). Dan, seperti yang dijelaskan sebelumnya, jika kesalahan diakui oleh ZSC31014 telah mencapai logika "1", maka ketika itu jatuh lagi ke logika "0", Anda telah melanggar "aturan" yang ditandai dengan warna merah untuk perilaku I²C yang diperlukan oleh ZSC31014.
Karena pengenalan level logika dalam wilayah tegangan "tidak terdefinisi" tidak ditentukan, produsen sensor tidak melanggar spesifikasi jika mereka membuat satu batch yang mengenali logika "1" hanya ketika mencapai 0,7 x Vdd, tetapi membuat batch lain yang mengenali logika "1" serendah 0,4 x Vdd, misalnya. Batch kedua hipotetis akan lebih cenderung melihat kesalahan SDA sebagai tepi SDA jatuh, melanggar titik ketiga dalam daftar mereka, namun tidak melanggar spesifikasi mereka.
(Banyak masalah yang telah saya kerjakan, selama bertahun-tahun, adalah seperti ini: Ada dua perangkat, yang tidak satu pun yang secara individual melanggar spesifikasi yang memiliki celah - tetapi satu rewel dan kurang toleran, pada titik di mana satu lagi perlu perangkat yang terhubung menjadi lebih toleran karena yang perilaku jelas! masing-masing kedua perangkat baik-baik saja berinteraksi dengan mayoritas perangkat lain, tetapi tidak dapat diandalkan (atau benar-benar gagal) ketika terhubung satu sama lain.)
Jadi apa yang bisa kamu lakukan? Saya memikirkan dua opsi:
Jangan gunakan MSP430 - gunakan MCU lain yang tidak membuat kesalahan SDA awal. Namun saya berharap Anda telah menginvestasikan banyak waktu dalam perangkat lunak dan tidak ingin port kode ke MCU lain, jika itu bisa dihindari.
"Bit-bang" protokol I²C pada MSP430, alih-alih menggunakan modul perangkat keras I²C bawaannya. Dengan begitu, Anda memegang kendali penuh atas sinyal I²C dan dapat mencegah terjadinya kesalahan itu. Namun, itu jelas merupakan pekerjaan untuk membuat rutinitas I²C Anda sendiri, men-debug-nya, dan kode yang dihasilkan mungkin lebih besar daripada ketika menggunakan modul perangkat keras MSP430 I²C, yang dengan sendirinya bisa menjadi masalah jika Anda kekurangan ruang Flash.
Kemudian saya pergi mencari masalah MSP430 I²C, dan saya menemukan bahwa kombinasi MSP430 + ZSC31014 ini adalah masalah yang diketahui, karena kesalahan SDA awal dari MSP430! Lihat utas ini di forum TI E2E MSP430:
Forum TI E2E: pulsa kesalahan MSP430 I2C menyebabkan masalah bagi chip periferal I2C
Solusi yang disebutkan di sana, adalah mengubah alamat ZSC31014 I²C sehingga SDA tinggi pada saat kesalahan positif dapat terjadi, dan karena SDA dibuat tinggi maka, tidak ada kesalahan aktual pada SDA:
Solusi kami adalah mengonfigurasi chip ZSC agar memiliki alamat dengan set bit 6 (mis. Kami sekarang menggunakan 0x42) - ini mengubah pulsa kesalahan menjadi bit "tinggi" bersih yang bagus untuk durasi bit alamat 6, yang menghilangkan dari ujung jatuh bermasalah.
Solusi yang sama secara efektif adalah kebalikan dari saran di lembar data ZSC31014, di kotak merah yang saya tandai. Mereka mengatakan kesalahan SDA harus dicegah jika bit pertama (yang merupakan MSbit) dari alamat ZSC31014 I²C adalah 0 - jadi jangan buat MSbit dari alamat I²C menjadi "0", jadikan "1" sebagai gantinya yaitu atur bit 6 di alamat I²C 7-bit!
Karena utas forum TI E2E dan lembar data ZSC31014 keduanya berfokus pada alamat I²C, maka mungkin kesalahan SDA tidak terjadi, atau tidak menjadi masalah jika itu terjadi, selama pengiriman data lain di bus. Anda perlu menyelidiki itu.
Oleh karena itu, mengabaikan solusi pertama menggunakan MCU yang berbeda, dua solusi (lebih praktis) adalah:
- Bit-bang MSP430 I²C bus dengan menulis kode Anda sendiri, sehingga Anda tidak membuat kesalahan itu di SDA, atau
- Ubah alamat ZSC31014 I²C sehingga bit 6 dari alamat 7-bitnya ditetapkan, yang berarti bahwa SDA sudah tinggi ketika kesalahan akan terjadi, jadi tidak ada kesalahan yang sebenarnya terjadi pada SDA ketika ZSC31014 ditangani (dengan asumsi bahwa kesalahan SDA baik tidak terjadi setelah I²C lainnya Memulai acara selama transfer data, atau jika ada yang terjadi, bahwa ZSC31014 tidak mendapatkan "kesal").
Semoga itu bisa membantu!
