Tôi nghĩ rằng tôi đã tìm thấy câu trả lời. Hóa ra đây là một vấn đề đã biết, nhưng tôi chỉ thấy rằng sau khi tôi quyết định vấn đề là ở đâu, và tìm kiếm nó!
Đây là quá trình tôi đã trải qua, vì vậy bạn có thể làm theo nó (và, nếu cần, sau đó bạn có thể điều chỉnh cuộc điều tra của mình nếu bạn thấy kết quả khác với giả định của tôi). Điểm mấu chốt là dường như có sự không tương thích giữa (ít nhất là một số) hành vi MSP430 I²C và hành vi I²C cần thiết của thiết bị mà bạn nghi ngờ là I²C Slave, IDT ZSC31014 . Có bảng dữ liệu cho thiết bị đó là rất quan trọng để hiểu điều này, vì vậy cảm ơn bạn đã tìm thấy nó.
Tin tốt là có (ít nhất) 2 cách giải quyết cho vấn đề này, điều mà tôi sẽ giải thích ở cuối.
Cốt truyện dày lên, có vẻ như việc kết nối một máy hiện sóng khác nhau sẽ không khiến mạch hoạt động chính xác và có thể thấy rằng sự khác biệt duy nhất là ACK không được truyền đi.
Các dấu vết mới là hữu ích, cảm ơn, mặc dù tôi diễn giải chúng một chút khác nhau.
. dấu vết mới nhất. Tôi vẫn sẽ đề nghị điều tra rằng SCL không hoạt động cuối cùng, nhưng tôi không tin rằng nó có liên quan đến vấn đề chính.)
Có hai "trục trặc" trên SDA:
Một trục trặc ngay trước hoặc ngay sau xung ACK không phải là hiếm, khi I²C Master giải phóng quyền kiểm soát SDA để cho phép Slave thực hiện ACK và sau đó Master có thể lái lại SDA. Vì vậy, tôi bỏ qua cái đó.
Đó là trục trặc SDA sớm , trước xung SCL đầu tiên, điều này bất thường hơn. Từ biên độ của trục trặc SDA ban đầu đó (xem sau) và thực tế nó chỉ xảy ra trước xung SCL đầu tiên đó (được dán nhãn 0), nhưng không xảy ra trước các xung SCL sau đó, nơi chúng ta có thể thấy một trục trặc trên SDA (như SCL các xung có nhãn 4, 5, 6 hoặc 7), chúng tôi biết đó không phải là vật phẩm đo lường, cũng không phải là khớp nối từ SCL (ví dụ).
(Để tham khảo sau, sự cố SDA ban đầu trông giống như ít nhất 2V trong dấu vết mới nhất, do đó, với Vdd ở mức 3.6V từ các nhận xét trước đó, điều đó làm cho biên độ trục trặc của SDA ít nhất (2 / 3.6) = 0.55 x Vdd. các ngưỡng mức logic I2C có liên quan sẽ thảo luận sau.)
Bỏ qua sự khác biệt ACK, tôi tin rằng tôi thấy một sự khác biệt khác giữa hai bộ dấu vết trong ảnh chụp màn hình thứ hai đó. Biên độ của trục trặc SDA ban đầu đó có vẻ hơi khác nhau, so sánh dấu vết SDA hàng đầu được dán nhãn C1(màu vàng-ish?) Và dấu vết SDA thứ 2 được dán nhãn M3(màu xanh). Bây giờ tôi tin rằng sự khác biệt về biên độ của trục trặc SDA ban đầu đó, là điều có thể khiến vấn đề của bạn xuất hiện hoặc biến mất, như tôi giải thích dưới đây.
Thậm chí nhiều độ phân giải cụ thể hơn về trục trặc sẽ giúp ích (đó là một trong những vấn đề trong việc cố gắng xử lý các vấn đề "từ xa" - tôi không thể tự mình vận hành phạm vi!). Tôi sẽ giả sử rằng khi bạn phóng to, có vẻ như bắt đầu logic I²C bình thường "1" (nghĩa là đường cong RC ở cạnh tăng, đặc biệt là nếu bạn tạm thời làm cho pull-up yếu hơn, ví dụ như 10k) trừ khi nó không ' t đạt đến điện áp dương hoàn toàn trước khi nó được dẫn đến logic "0" một lần nữa. Đó là những gì được hiển thị trên một trang web khác được liên kết sau đó. Nếu bạn thấy hình dạng khác với trục trặc của bạn, thì phân tích sau này của tôi có thể không áp dụng.
I²C Master đang điều khiển xe buýt tại điểm trục trặc đó, giữa I²C Start và xung đồng hồ SCL đầu tiên (mà bạn đã gắn nhãn "0" mặc dù đó là MSbit). Điều đó khiến tôi nghi ngờ về hành vi MSP430, mặc dù với SCL ở mức thấp vào thời điểm đó, một trục trặc SDA không nên ảnh hưởng đến các thiết bị tuân thủ I²C, vì chúng sẽ chờ SCL tăng cao trước khi chúng đọc trạng thái SDA tiếp theo.
Vì vậy, I²C Slave có thực sự tuân thủ I²C không? Hóa ra, ZSC31014 " cầu kỳ " và ít dung sai hơn một số thiết bị I²C khác, vào đúng thời điểm mà tôi tin rằng MSP430 đang tạo ra sự cố đó!
Bảng dữ liệu ZSC31014 liệt kê 3 khu vực nơi chúng thừa nhận hành vi I²C của thiết bị là "khác nhau". Bạn cũng có thể bị ảnh hưởng bởi hai người đầu tiên trong danh sách này vào những thời điểm khác (đó không phải là một phần của phân tích này), nhưng đó là điểm thứ ba mà tôi đã đánh dấu bên dưới màu đỏ, có liên quan đến trục trặc SDA ban đầu đó:
Biên độ của trục trặc SDA sớm đó là rất quan trọng . Nếu trục trặc đó không tăng đủ để được ZSC31014 nhận ra là logic "1" trước khi nó rơi lại, thì bạn vẫn ổn - thiết bị phải thấy một điểm rơi trên SDA để phá vỡ "quy tắc" đó và nó chỉ có thể là một cạnh giảm nếu nó đã được công nhận là logic "1".
Bất cứ điều gì ảnh hưởng đến biên độ của sự cố SDA đó, như tải bổ sung của 'bộ phân tích phạm vi hoặc logic trên tín hiệu SDA, có thể đủ để ngăn chặn sự cố được ZSC31014 nhận ra khi đạt đến logic "1" và do đó không "rơi" Cạnh SDA ", điểm thứ ba trong danh sách, có thể xảy ra (vào một ngày tốt, tùy thuộc vào điện áp, nhiệt độ, v.v.). Tuy nhiên, như bạn đã tìm thấy, sự khác biệt giữa các máy hiện sóng khác nhau là đủ để có nghĩa là một số trong số chúng thêm tải đủ để ngăn chặn vấn đề, và những cái khác thì không. Thiết lập này phải rất ít!
Điều này khẳng định sự lo lắng của tôi rằng các lô cảm biến "hoạt động" trước đó của bạn, có thể "chỉ" hoạt động, vì MCU MSP430 trên các thiết lập "hoạt động" đó có thể cũng sẽ tạo ra sự cố SDA. Lý thuyết của tôi về sự khác biệt có thể có giữa các lô cảm biến, có thể giải thích hành vi khác nhau mà bạn đã báo cáo (lô "làm việc" so với lô "không hoạt động") sẽ được giải thích tiếp theo.
Thật thú vị, ZSC31014 khác với I²C tiêu chuẩn ở một khu vực khác không được đề cập trong danh sách đó từ nhà sản xuất và điều này có thể giải thích tại sao bạn dường như thấy sự khác biệt giữa các lô cảm biến.
Ngưỡng logic I²C tiêu chuẩn là (đơn giản hóa) - dưới 0,3 x Vdd đối với logic "0" và trên 0,7 x Vdd đối với logic "1" như được hiển thị trong thông số kỹ thuật của I²C :
Tuy nhiên, ZSC31014 có các ngưỡng khác nhau , 0,2 x Vdd và 0,8 x Vdd, có nghĩa là "vùng không xác định" giữa các ngưỡng đó lớn hơn các thiết bị I²C điển hình:
"Vùng không xác định" lớn hơn đó làm tăng khả năng trục trặc xâm nhập vào vùng điện áp không xác định, trong đó nó có thể được nhận dạng là logic "1" (hãy nhớ rằng, mọi thứ trên 0,2 x Vdd đều có thể được ZSC31014 nhận ra là logic "1" , vì trong khu vực không xác định, mọi thứ đều được phép - nó chỉ cao hơn 0,8 x Vdd khi nó phải được công nhận là logic "1"). Và, như đã giải thích trước đây, nếu trục trặc được ZSC31014 nhận ra là đã đạt đến logic "1", thì khi nó lại rơi vào logic "0", bạn đã phá vỡ "quy tắc" được đánh dấu màu đỏ cho hành vi I²C cần thiết bởi ZSC31014.
Do không nhận biết được các mức logic trong vùng điện áp "không xác định" đó, nên nhà sản xuất cảm biến sẽ không phá vỡ thông số kỹ thuật nếu họ tạo một lô chỉ nhận ra logic "1" khi đạt 0,7 x Vdd, nhưng tạo ra một lô khác nhận ra một logic "1" thấp đến 0,4 x Vdd chẳng hạn. Lô thứ hai giả định đó sẽ có nhiều khả năng thấy sự cố SDA là một cạnh SDA giảm, vi phạm điểm thứ ba trong danh sách của họ, nhưng không phá vỡ đặc điểm kỹ thuật của họ.
(Nhiều vấn đề tôi đã làm việc trong nhiều năm qua đã xảy ra như sau: Có hai thiết bị, không có thiết bị nào phá vỡ một đặc điểm kỹ thuật có sơ hở - nhưng một trong số đó là cầu kỳ và kém khoan dung hơn , ở điểm Một thiết bị khác cần các thiết bị được kết nối để trở nên khoan dung hơn vì hoạt động không rõ ràng của nó ! Mỗi thiết bị trong số hai thiết bị đó đều giao tiếp tốt với phần lớn các thiết bị khác, nhưng không đáng tin cậy (hoặc hoàn toàn thất bại) khi kết nối với nhau.)
vậy, bạn có thể làm gì? Tôi nghĩ về hai lựa chọn:
Không sử dụng MSP430 - sử dụng MCU khác không tạo ra trục trặc SDA sớm đó. Tuy nhiên tôi hy vọng bạn đã đầu tư nhiều thời gian vào phần mềm và sẽ không muốn chuyển mã sang MCU khác, nếu điều đó có thể tránh được.
"Bit-bang" giao thức I²C trên MSP430, thay vì sử dụng mô-đun phần cứng I²C tích hợp. Bằng cách đó, bạn có toàn quyền kiểm soát các tín hiệu I²C và có thể ngăn chặn sự cố đó xảy ra. Tuy nhiên, rõ ràng sẽ có một số công việc để tạo các thói quen I²C của riêng bạn, gỡ lỗi chúng và mã kết quả có thể lớn hơn so với khi sử dụng mô-đun phần cứng MSP430 I²C, đây có thể là một vấn đề nếu bạn thiếu không gian Flash.
Sau đó, tôi đã tìm kiếm các vấn đề MSP430 I²C và tôi thấy rằng sự kết hợp này của MSP430 + ZSC31014 là một vấn đề đã biết, do sự cố SDA ban đầu từ MSP430! Xem chủ đề này trên diễn đàn TI E2E MSP430:
Diễn đàn TI E2E: MSP430 xung trục I2C gây rắc rối cho chip ngoại vi I2C
Cách giải quyết đề cập ở đó, là để thay đổi địa chỉ ZSC31014 I ² C để SDA là cao vào thời điểm khi trục trặc tích cực có thể xảy ra, và vì SDA được làm bằng cao thì dù sao, không có thực tế trục trặc trên SDA:
Cách giải quyết của chúng tôi là định cấu hình chip ZSC để có địa chỉ với bit 6 được đặt (ví dụ: chúng tôi hiện đang sử dụng 0x42) - điều này biến xung trục trặc thành một bit "cao" sạch đẹp cho thời lượng của bit địa chỉ 6, bị loại bỏ của các cạnh rơi có vấn đề.
Cách giải quyết tương tự có hiệu quả ngược lại với gợi ý trong biểu dữ liệu ZSC31014, trong hộp màu đỏ mà tôi đã đánh dấu. Họ nói rằng một trục trặc SDA phải được ngăn chặn nếu bit đầu tiên (là MSbit) của địa chỉ I²C ZSC31014 là 0 - vì vậy đừng biến MSbit của địa chỉ I²C thành "0", thay vào đó là "1" đặt bit 6 trong địa chỉ I²C 7 bit!
Do luồng chủ đề của diễn đàn TI E2E và bảng dữ liệu ZSC31014 đều tập trung vào địa chỉ I²C, nên có lẽ sự cố SDA không xảy ra hoặc không xảy ra sự cố trong quá trình gửi dữ liệu khác trên xe buýt. Bạn sẽ cần phải điều tra rằng.
Do đó, bỏ qua cách giải quyết đầu tiên của việc sử dụng MCU khác, hai cách giải quyết (thực tế hơn) là:
- Bit-bang xe buýt MSP430 I²C bằng cách viết mã của riêng bạn, để bạn không tạo ra trục trặc đó trên SDA, hoặc
- Thay đổi địa chỉ ZSC31014 I ² C để bit 6 của địa chỉ 7-bit của nó được thiết lập, có nghĩa là SDA đã cao khi trục trặc nếu không sẽ xảy ra, vì vậy không thực tế trục trặc xảy ra trên SDA khi ZSC31014 được đề cập (giả định rằng một trục trặc SDA hoặc không xảy ra sau các I²C khác Bắt đầu các sự kiện trong khi truyền dữ liệu hoặc nếu xảy ra, ZSC31014 không bị "đảo lộn").
Mong rằng sẽ giúp!
