Tôi đang cố gắng đưa ra một PCB sử dụng STM32F407 và LAN8720A Ethernet PHY và dường như tôi không thể nhận được bất kỳ khung Ethernet nào - mặc dù tôi không gặp vấn đề gì khi truyền khung.

Thiết lập phần cứng

Tôi có một tinh thể 25 MHz trên STM32F4, điều khiển pin đầu ra xung nhịp 25 MHz vào LAN8720A, ở chế độ REF_CLK_OUT - và đưa đồng hồ 50 MHz trở lại STM32F4 như một phần của giao diện RMII.

Các jack / từ tính là một phần chung. Đây là biểu dữ liệu:

Phần mềm

Tôi đang sử dụng STM32CubeMX cập nhật mới nhất để tạo System Workbench cho dự án STM32 có chứa FreeRTOS, lwIP, cộng với các trình điều khiển ngoại vi ETH. Tôi chưa thực sự chạm vào bất kỳ mã nào được tạo - vì vậy ngăn xếp lwIP được khởi tạo bên trong ngăn xếp FreeRTOS.

Thí nghiệm

Với lwIP của bo mạch của tôi được cấu hình cho IP tĩnh 10.0.0.2 và khóa USB-to-ethernet trên máy tính của tôi được định cấu hình cho IP tĩnh 10.0.0.1, tôi kết nối trực tiếp hai thiết bị bằng cáp Ethernet và bo mạch của tôi cố gắng kết nối đến một dịch vụ trên cổng 80 của máy tính. Tôi nắm bắt được sự tương tác giữa bo mạch của tôi và máy tính bằng Wireshark (chạy trên máy tính và được liên kết với bộ chuyển đổi USB sang Ethernet).

Do vấn đề không có khung nhận được, chúng tôi không bao giờ vượt qua công cụ ARP này: Như bạn có thể thấy, Stmicroe (bảng của tôi) có thể gửi các gói ARP - được nghe bởi máy tính của tôi - nhưng dường như không bao giờ nghe thấy phản hồi từ máy tính của tôi , vì nó tiếp tục nổ tung các gói ARP.

Cả hai thiết bị đều được cấu hình với mặt nạ 255.255.255.0 và cả hai đều được cấu hình với địa chỉ cổng 10.0.0.1 (máy tính). Tôi đã nghe nói về các bảng ARP bị vặn và máy tính bỏ qua các gói ARP, nhưng tôi không thể tưởng tượng được bảng sẽ bỏ qua các gói ARP được máy tính của tôi xử lý cụ thể - để đáp ứng các yêu cầu mà bảng đưa ra ở nơi đầu tiên.

Vì vậy, tôi đi sâu vào tập tin ethernetif.c của lwIP và nhận thấy HAL_ETH_GetReceivedFrame_IT(&heth)có lỗi. Hàm đó trả về lỗi vì (heth->RxDesc->Status & ETH_DMARXDESC_OWN)== 0, thay vì 1. Tôi hiểu điều đó có nghĩa là bộ đệm DMA hiện được trang bị cho thiết bị ngoại vi MAC và chưa nhận được gì.

Hơn nữa, tôi đã xác minh rằng HAL_ETH_IRQHandler không bao giờ được gọi.

Một vấn đề với PHY?

Tại thời điểm này, tôi đã nghi ngờ chính PHY của mình là đáng trách.

Để điều tra thêm, tôi đã gắn Saleae Logic Pro 16 của mình vào tất cả các tín hiệu có liên quan và nhận thấy có rất nhiều lưu lượng trên cả TX0 / TX1, cũng như các dòng RX0 / RX1. Đây là một bản ghi lưu lượng RX với đồng hồ đầu vào 25 MHz:

RX_ERR toàn bộ thời gian thấp, trừ khi tôi cố gắng thu được đầu ra xung nhịp 50 MHz (rõ ràng là một thách thức với một thiết bị như Saleae): trong trường hợp đó, RX_ERR bị mờ rất cao đối với một vài gói (thực sự là một dấu hiệu tốt - pin dường như đang hoạt động).

Bước tiếp theo

Tôi đã thử kích hoạt ngắt ETH theo cách thủ công bằng cách gọi HAL_NVIC_EnableIRQ(ETH_IRQn);sau khi tcpip_init()được gọi trong MX_LWIP_Init()tác vụ và điều đó dường như không khắc phục được sự cố. Tôi không hoàn toàn chắc chắn rằng thói quen ngắt Ethernet thậm chí còn được gọi là - đó là điều khó khăn khi đưa ra một thiết kế hoàn toàn mới; Tôi đang vật lộn để xác định hành vi đúng đắn của hệ thống sẽ là gì, do đó tôi có thể xác định cách thiết lập của mình khác nhau như thế nào.

Mặc dù tôi đã sử dụng công cụ STM32 / STM32CubeMX / FreeRTOS trước đây, tôi chưa bao giờ sử dụng thiết bị ngoại vi Ethernet của STM32 và trải nghiệm duy nhất của tôi với công cụ này là trên các hệ thống nhúng nhúng tùy chỉnh, dường như luôn hoạt động ngoài hộp. Đây là lãnh thổ mới đối với tôi!

Tôi chắc chắn có một hộp kiểm ngu ngốc ở đâu đó hoặc Ethernet_EnableReceive()chức năng ma thuật mà tôi quên gọi, nhưng tôi thực sự không thể tìm thấy bất kỳ tài liệu nào đề nghị cần kích hoạt rõ ràng nội dung đó và các bài đăng tôi thấy trên internet đều không liên quan các vấn đề.

Nếu bất cứ ai có ý tưởng, tôi muốn giúp đỡ!

Phụ lục: Loại bỏ FreeRTOS

Chỉ để loại bỏ công cụ, tôi đã loại bỏ thành phần dự án FreeRTOS, quay trở lại một dự án kim loại trần. Trong vòng lặp chính của tôi, tôi gọi MX_LWIP_Process(). Phương pháp này sẽ loại bỏ sự cần thiết của các ngắt, nhưng nó không khắc phục được vấn đề; Tôi vẫn không thể nhận được khung. Điều này khiến tôi nghĩ rằng có một cái gì đó trong mã ETH HAL được tạo bởi STM32CubeMX.

Giải pháp

Chỉ trong trường hợp ai đó vấp phải câu hỏi này trong tương lai, vấn đề hóa ra là lật chân RXD0 và RXD1. Đây là lý do tại sao tôi có thể thấy lưu lượng truy cập trên máy phân tích logic của mình, nhưng nó không được giải mã bởi MCU của tôi.

Như ai đó đã chỉ ra, từ tính tôi sử dụng là không đối xứng và không nên được sử dụng cho tự động MDI-X. Tôi chưa có vấn đề gì. Tôi dự đoán một trong hai điều đang xảy ra: - từ tính không thực sự hoạt động theo hướng khác, nhưng vì mọi thứ tôi sử dụng tự động MDI-X, bo mạch của tôi về cơ bản vẫn cố định trong cấu hình hoạt động, trong khi thiết bị khác bật cáp định hướng tín hiệu của nó để phù hợp. - từ tính cung cấp tính toàn vẹn tín hiệu phù hợp với các lần chạy Ethernet ngắn, nhưng phân tích dài hạn sẽ cho thấy tốc độ giảm gói cao hơn hoặc các sự cố trong thời gian dài hơn.

Thành thật mà nói, tôi không rõ tại sao nó lại quan trọng ở phía nào của máy biến áp 1: 1, do đó, bên ngoài các ứng dụng PoE, tôi không chắc tại sao thiết kế đối xứng và không đối xứng lại quan trọng.

Bạn đã cài đặt wireshark trên PC và như bạn nói bạn sử dụng bộ chuyển đổi USB sang LAN. Tôi không chắc chắn tại điểm vật lý nào Wireshark chụp các gói trong thiết lập của bạn và do đó, đây là một câu hỏi hay nếu các gói bên ngoài thực sự xuất hiện trên mạng vật lý . Tôi khuyên bạn nên kết nối một PC khác với giao diện mạng và xem liệu các PC này có thể giao tiếp với nhau so sánh đầu ra của Wiresharks trên chúng không.

Đầu ra wireshark của bạn không hiển thị bất kỳ vấn đề nào, PC thông báo ba lần rằng nó nằm trên mạng cục bộ và có địa chỉ IP 10.0.0.1 (nếu nó sẽ nhận được trả lời cho bất kỳ 3 yêu cầu ARP nào thì OS sẽ xuất hiện xung đột địa chỉ IP).

Sau đó, hội đồng quản trị của bạn liên tục hỏi Ai có 10.0.0.1? Nói 10.0.0.2 và PC trả lời với 10.0.0.1 là ... . Câu hỏi là tại sao nó xảy ra trong vòng lặp:

1. hội đồng quản trị không nhận được gói phản hồi vật lý được gửi bởi PC;
2. Hội đồng quản trị mong đợi một cái gì đó khác, hoặc gói nhận được bị hỏng và nó loại bỏ gói.

Do đó, như một bước khắc phục sự cố tiếp theo, hãy sử dụng một PC khác có giao diện Ethernet "bình thường", cài đặt Wireshark trên nó, định cấu hình mạng giống như bạn đã làm cho bo mạch và thử telnet 10.0.0.1 80và thấy nó xuất hiện trong Wiresharks trên cả hai máy. Bằng cách này, bạn sẽ đảm bảo rằng PC với bộ điều hợp USB-Ethernet của nó hoạt động chính xác.

Các bước tiếp theo của bạn sẽ phụ thuộc vào những thứ bạn nhìn thấy trong các Wiresharks này.

Cập nhật:

Tôi đang nhận gói tin, nếu không các chân RXD0 / D1 sẽ không hiển thị hoạt động, đúng không?

Không chính xác. Bạn muốn nghĩ rằng bảng của bạn nhận được gói. Bạn thấy có một số thay đổi về mức tín hiệu đầu vào PHY, nhưng chúng không nhất thiết phải đại diện cho các gói hợp lệ. Thực tế là RX_ERR không chuyển đổi không ngay lập tức thuyết phục tôi rằng PHY đang hoạt động chính xác trên các sự kiện đến hoặc thông tin đến tạo nên các gói phù hợp.

Dù sao, tùy thuộc vào bạn, lý thuyết khắc phục sự cố của tôi rất đơn giản - bạn phải đảm bảo ở mức cao hơn nơi bạn gặp phải sự cố và sau đó đào sâu vào phần tương ứng của thiết kế. Đào sâu vào tất cả các bộ phận và nghi ngờ mọi thứ là vô ích. Sẽ là may mắn lớn nếu bạn tìm thấy vấn đề lan rộng trọng tâm; bạn đã thử đơn giản hóa phần mềm, nếu nó không thành công, rất có thể bạn sẽ bắt đầu thay thế chip.

Tôi không nghĩ rằng bước khắc phục sự cố của tôi quá phức tạp để đảm bảo rằng một PC khác có thể giao tiếp với PC bằng dongle và chứng minh tôi sai hoặc đúng, và do đó đảm bảo rằng bạn đang đào sâu vào nghi ngờ PHY, MAC và phần mềm hoạt động trên bảng họ

Xin lỗi để hồi sinh chủ đề này. Tôi không thể vượt qua mà không đề cập đến kinh nghiệm của tôi.

Tôi đã sử dụng HR911105A (RJ45 với nam châm) này với một trong những dự án của tôi.

HR911105A: Nhìn thoáng qua, có một điều khiến tôi chú ý đó là kết nối giữa LAN8720 và RJ45 theo sơ đồ của bạn.

Vì tôi thấy rằng kết nối có vẻ chéo. Mặc dù các hệ thống được kết nối chủ yếu sử dụng MDI-X và do đó phát hiện các cặp Nhận / Truyền, nhưng sẽ tốt hơn nếu cung cấp cho nó một kết nối ít gây nhầm lẫn như thế:

LAN -> RJ45
=====================
TXP -> TD+ (Pin #1)
TXN -> TD- (Pin #2)
RXP -> RD+ (Pin #3)
RXN -> RD- (Pin #6)

Pin #4 and Pin #5(vì vậy các điện trở kéo lên 49,9R) sẽ tốt nếu được kết nối với 3V3_ANsơ đồ của bạn trong khi phía bên kia phải được ghép với GND thông qua một tụ điện (0,1uF hoặc 0,022uF).