Địa chỉ nô lệ I2C không được thừa nhận (đôi khi)

Tôi đang cố gắng liên lạc với FRAM được kết nối từ xa (FM24C04 từ Ramtron) bằng cách sử dụng I2C. Bộ nhớ này được nhúng trên một bảng có thể được chèn và loại bỏ bất cứ lúc nào đến / ra khỏi hệ thống (giao tiếp được chấm dứt đúng cách trước khi bộ nhớ bị xóa).

Vấn đề là: ngay sau khi lắp thẻ có chứa FRAM, đôi khi , nó không xác nhận địa chỉ.

Đo lường tín hiệu

Tôi đã đo các tín hiệu để xem những gì đang xảy ra và dường như thời gian là ổn trong cả hai trường hợp (làm việc và không hoạt động).

Truyền thông I2C đúng (đọc 3 byte):

Địa chỉ I2C FRAM không được xác nhận (địa chỉ nô lệ được gửi chính xác):

Các hành động đã được thực hiện để giải quyết vấn đề này (không thành công)

• Độ trễ được thêm vào sau khi thẻ có FRAM nhúng được chèn vào để đảm bảo rằng trình tự nguồn được tuân thủ.
• I2C dừng tạo sau khi phát hiện địa chỉ nô lệ không xác nhận

Cấu hình bus I2C

• Một chủ (vi điều khiển STM32F205 từ ST)
• Ba nô lệ (EEPROM 24AA1025 từ Microchip, RTC DS1339C từ Maxim IC và FRAM FM24C04 từ xa từ Ramtron
• Một bộ dịch mức I2C (MAX3373E từ Maxim IC) được sử dụng để cho phép giao tiếp giữa chủ và FRAM
• Tần số bus được đặt thành 100 kHz

EDITED (2013-04-17)

Trước tiên, cảm ơn tất cả các ý kiến ​​của bạn.

Vì có rất nhiều gợi ý, đây là mô tả về các cuộc điều tra mà tôi đã thực hiện.

Sơ đồ

Hình ảnh sau đây cho thấy sơ đồ đơn giản hóa của bus I2C:

Tín hiệu I2C_SDA và I2C_SCL được kết nối trực tiếp với vi điều khiển và tín hiệu FRAM_SDA và FRAM_SCL được kết nối với FRAM. Lưu ý rằng tín hiệu SDA và SCL được kết nối với FRAM được lọc bằng cách sử dụng các ferrites BLM18 từ Murata.

FRAM được kết nối như sau:

• NC (chân 1) -> không được kết nối
• A1 (chân 2) -> GND
• A2 (chân 3) -> GND
• VSS (chân 4) -> GND
• SDA (chân 5) -> FRAM_SDA
• SCL (chân 6) -> FRAM_SCL
• WP (chân 7) -> GND (không được bảo vệ ghi)
• VDD (chân 8) -> + 5V

Mô tả thẻ FRAM

Thẻ này là thẻ "giống như ISA" chỉ nhúng FRAM.

Điều tra

Làm chậm tần số

Tôi đã chạy thử nghiệm với tần số SCL được đặt thành 50kHz và 10kHz. Tôi đo tín hiệu SCL bằng máy hiện sóng để đảm bảo rằng nó ở tần số dự kiến.

Những sửa đổi này đã không giải quyết được vấn đề. Tôi đã kiểm tra thời gian và chúng nằm trong thông số kỹ thuật của bảng dữ liệu FRAM.

Đảm bảo chuỗi công suất

@jippie.

1. Bộ dịch mức I2C được đặt ở chế độ ba trạng thái trước khi thẻ nhúng FRAM được chèn. Tín hiệu FRAM_SDA và FRAM_SCL được kéo xuống mức thấp.
2. Sau khi "thẻ FRAM" được chèn, độ trễ 100ms được thêm vào để đảm bảo nguồn điện được ổn định (ít nhất là 11ms trước điều kiện khởi động đầu tiên theo biểu dữ liệu).
3. Bộ dịch mức I2C được kích hoạt.
4. Độ trễ 1ms được thêm vào để đảm bảo bộ dịch mức I2C được kích hoạt và các dòng được kéo lên (~ 4us theo yêu cầu của biểu dữ liệu). Tín hiệu FRAM_SDA và FRAM_SCL được kéo lên.
5. FRAM được truy cập.

Tín hiệu FRAM_SDA và FRAM_SCL đã được đo sau mỗi bước.

Vấn đề vẫn xảy ra.

Điều kiện dừng / bắt đầu thay vì bắt đầu lặp lại

@gbarry.

Tôi đã cố gắng dừng lại trước khi bắt đầu lặp lại trong khi chuyển byte. Tôi đã đo chuyển byte bằng máy hiện sóng: điều kiện STOP theo sau là điều kiện START là OK.

Thật không may, giải pháp này không giải quyết được vấn đề.

Suy nghĩ

Vấn đề này chỉ xảy ra sau khi thẻ nhúng FRAM được kết nối. Tôi đã chạy một vài ngàn truy cập đọc thành công (địa chỉ nô lệ và đọc) sau khi "thẻ FRAM" được chèn và giải quyết chính xác.

Nghe có vẻ như tôi ngày càng giống như một vấn đề phần cứng. Nhưng tôi không biết liệu nó có thể liên quan đến bộ chuyển đổi cấp I2C hay các nô lệ khác trên xe buýt I2C không.

Bạn có bất kỳ ý tưởng hoặc đề nghị khác?

EDITED (2013-04-18)

Vấn đề dường như được giải quyết

Tôi đã thay thế đầu nối mô-đun FRAM và tìm cách thực hiện các phép đo trực tiếp trên FRAM. Có vẻ như tất cả đang hoạt động tốt với kết nối mới này.

Tôi sẽ làm thêm các xét nghiệm để chắc chắn rằng vấn đề xuất phát từ một mối quan hệ xấu.

Mặc dù bạn nói rằng comms của bạn đã bị chấm dứt đúng cách trước khi chèn hoặc xóa, nhưng có thể đáng để thử giải pháp này, vì có một tình huống mà bus I2C có thể gặp sự cố sau khi thiết lập lại chỉ một trong các thiết bị trên bus.

Trước khi khởi chạy phần cứng Master I2C, hãy đặt SDA làm đầu vào và kiểm tra SDA ở mức thấp.

Nếu nó thấp thì đặt chân SCL lên cao.

Sau đó, chuyển đổi chân SCL ở mức thấp và cao cho đến khi SDA tăng cao (tức là loại bỏ mọi bit còn lại mà các thiết bị ngoại vi vẫn có thể đang cố gửi). Điều này không thể mất hơn 8 chu kỳ đồng hồ - nếu nó xảy ra thì có một số vấn đề khác.

Tôi không thể đảm bảo điều này sẽ giải quyết vấn đề của bạn, nhưng nó đã giải quyết vấn đề của tôi!

Đối với FRAM:

• đầu tiên kết nối GND và Vcc;
• sau đó đảm bảo A1, A2 và WP có cấp chính xác;
• chỉ sau đó kết nối các chân dữ liệu.

Kết nối các chân khác ngoài nguồn điện trước khi chip được cấp nguồn có thể gây ra sự cố.

10k có vẻ hơi lớn đối với xe nâng của bạn và các cạnh hàng đầu của bạn trông chậm. Giảm các điện trở xuống khoảng 3k và xem nếu điều đó giúp.

Ngoài ra, tại sao điện áp tắt trôi theo thời gian?

Bất kỳ cơ hội nào khác có cố gắng nói chuyện với hội đồng đó? Tôi đã có một vấn đề như thế một lần; Tôi có thể kiếm được 60% thời gian, nhưng tôi không nhớ mình có thể thấy một vụ va chạm. Tôi nghi ngờ i2c tôi được cung cấp bằng cách nào đó được cách ly với xe buýt nội bộ thực sự. Tôi có thể chạy nó liên tục và nó sẽ giảm 30% tin nhắn. Vấn đề đã biến mất ngay khi chúng tôi bắt đầu nói chuyện trực tiếp với thiết bị (nguồn điện) mà không có "bảng nối đa năng" can thiệp.

Tôi không thấy trình tự dừng sau lỗi NAK của bạn. Tôi đoán bạn có một điểm dừng làm dừng chương trình tại thời điểm đó?

Cuối cùng, nếu bạn nghĩ bạn là người duy nhất trên xe buýt, bạn cũng có thể thử thay thế việc bắt đầu lặp lại bằng điểm dừng / bắt đầu. Tôi đã thấy các thiết bị (đặc biệt là các GPU tùy chỉnh) không biết cách xử lý RS.

[Đáp lại bình luận]: Có rất nhiều điều bạn chưa nói về bảng FRAM, như liệu đó chỉ là bộ nhớ hay toàn bộ hệ thống con. Nhưng nếu bạn có thể đặt phạm vi 'ngay trên các thiết bị dẫn của thiết bị i2c gây rắc rối cho bạn và bạn vẫn thấy những gì trong hình, thì tôi sẽ loại trừ nhiễu. I2C đủ đơn giản để nếu bạn thấy các tín hiệu phù hợp trên đầu vào, thì chip phải phát đúng trừ khi nó có vấn đề bên trong.

Cụ thể, bạn muốn nhận được về phía FRAM của shifter cấp đó. Sự phá vỡ tín hiệu có nhiều khả năng xảy ra hơn là một sự cố thường được coi là va chạm.

Tôi sẽ chỉ ra rằng một chu kỳ NAK không thể phân biệt được với một con chip đơn giản là không có ở đó. EEPROM sẽ làm điều này để cho biết họ đang bận. Tôi đã tra cứu thời gian ghi trên FRAM và nó nhanh hơn một bit dữ liệu i2c duy nhất ... vì vậy đó không phải là vấn đề.

Vì sự cố, khi nó tái tạo, là một lỗi vĩnh viễn chỉ được xóa bằng cách tháo và lắp lại thiết bị, nên đó là một trong hai điều: thiết bị đang ở trạng thái xấu mà nó chỉ phục hồi theo chu kỳ điện, hoặc có liên lạc kém.

Nếu thiết bị rơi vào trạng thái xấu mà thiết bị phục hồi theo chu kỳ nguồn, bạn có thể có một mạch bổ sung cho phép MCU của bạn tắt nguồn thiết bị. Phần sụn sau đó, khi không nhận được xác nhận từ thiết bị, có thể thực hiện quy trình khôi phục, theo đó, nó sẽ tắt chip trong một thời gian, cấp nguồn lại và sau đó thử lại.

Nếu đó là một liên hệ kém, thì có lẽ bạn phải xem độ tin cậy của đầu nối và tìm thứ gì đó tốt hơn. Nếu bạn sử dụng cùng một đầu nối để tạo thêm các bảng này, có thể có vấn đề trong trường. Trong mọi trường hợp, có thể có một quy trình của con người để xử lý tình huống. Người vận hành làm việc với thiết bị phải nhận thức được vấn đề tiềm ẩn khi lắp thẻ và có thể phải ngồi lại để vận hành đúng cách.

Thiết bị chính của bạn có thể có cách tăng báo thức cho biết rằng nó không thể nói chuyện với FRAM: đèn LED "gặp sự cố" trên bảng điều khiển và / hoặc tiếng bíp hoặc bất cứ điều gì. Hoặc ngược lại: một số ánh sáng bật lên, cung cấp cho người dùng phản hồi rằng FRAM đã được chấp nhận và giao tiếp đã được thiết lập. Nếu FRAM ở xa thiết bị chính, đèn có thể được đặt trên mô-đun FRAM: một chip I2C khác điều khiển đèn LED.

Bản chất lẻ tẻ của vấn đề cho thấy nó có thể là một vấn đề thời gian.

Bảng dữ liệu liệt kê hai bộ thời gian, một cho "Chế độ tiêu chuẩn" và một cho "Chế độ nhanh". Từ các phép đo của bạn, có vẻ như bạn đang ở trên đường viền của thời gian "Chế độ tiêu chuẩn". Tôi không thể biết từ việc lướt qua bảng dữ liệu về cách chính xác con chip được đưa vào một trong hai chế độ.

Tôi sẽ không cho rằng thiết bị của bạn ở Chế độ nhanh. Bạn có thể giảm thời gian theo hệ số 2-4 không, đảm bảo bạn đang ở trong chế độ hẹn giờ ở chế độ tiêu chuẩn cho thời gian giữ điều kiện bắt đầu, thời gian cao và thời gian thấp đồng hồ và xem vấn đề này có còn xảy ra không?

Bạn có hv a 24c04a, b, hay c không? Nếu nó là một c04a, nó là một thiết kế mạnh mẽ. Phần b có độ nhạy với các đường dốc cung cấp điện. Những gì tách rời làm bạn hv trên pin8 đến gnd? Tôi sẽ nói điều gì đó về các mức tín hiệu nhưng tôi thấy rằng bạn sử dụng một trình dịch mức. Bạn có thể muốn kiểm tra xem bạn không gặp trục trặc với SCL rằng chip sẽ hiểu là đồng hồ phụ.