Saya mencoba memunculkan PCB yang menggunakan STM32F407 dan LAN8720A Ethernet PHY, dan sepertinya saya tidak dapat menerima frame Ethernet - meskipun saya tidak memiliki masalah dalam mentransmisikan frame.

Pengaturan perangkat keras

Saya memiliki kristal 25 MHz pada STM32F4, menggerakkan pin keluaran clock 25 MHz ke LAN8720A, yang berada dalam mode REF_CLK_OUT - dan menggerakkan jam 50 MHz kembali ke STM32F4 sebagai bagian dari antarmuka RMII.

Dongkrak / magnet adalah bagian generik. Inilah datasheet:

Perangkat lunak

Saya menggunakan STM32CubeMX pembaruan terbaru untuk menghasilkan System Workbench untuk proyek STM32 yang berisi FreeRTOS, lwIP, ditambah driver periferal ETH. Saya belum benar-benar menyentuh salah satu kode yang dihasilkan - sehingga tumpukan lwIP diinisialisasi di dalam tumpukan FreeRTOS.

Eksperimen

Dengan papan lwIP saya yang dikonfigurasi untuk IP statis 10.0.0.2, dan dongle USB-to-ethernet di komputer saya yang dikonfigurasi untuk IP statis 10.0.0.1, saya menghubungkan kedua perangkat secara langsung dengan kabel Ethernet, dan papan saya mencoba menghubungkan ke layanan pada port 80 komputer. Saya menangkap interaksi antara papan saya dan komputer menggunakan Wireshark (berjalan di komputer, dan terikat ke konverter USB-to-Ethernet).

Karena masalah frame yang tidak diterima, kami tidak pernah bisa melewati hal-hal ARP ini: Seperti yang Anda lihat, Stmicroe (papan saya) dapat mengirim paket ARP - didengar oleh komputer saya - tetapi sepertinya tidak pernah mendengar respons dari komputer saya , karena terus mengeluarkan paket ARP.

Kedua perangkat dikonfigurasikan dengan mask 255.255.255.0, dan keduanya dikonfigurasikan dengan alamat gateway 10.0.0.1 (komputer). Saya pernah mendengar tentang tabel ARP yang kacau dan komputer mengabaikan paket ARP, tapi saya tidak bisa membayangkan papan akan mengabaikan paket ARP yang secara khusus ditujukan kepadanya oleh komputer saya - sebagai tanggapan atas permintaan yang dibuat oleh papan di tempat pertama.

Jadi, saya selami file ethernetif.c lwIP dan perhatikan bahwa HAL_ETH_GetReceivedFrame_IT(&heth)itu mengembalikan kesalahan. Fungsi itu mengembalikan kesalahan karena (heth->RxDesc->Status & ETH_DMARXDESC_OWN)== 0, bukan 1. Saya menafsirkannya berarti bahwa buffer DMA saat ini dipersenjatai untuk perangkat MAC, dan belum menerima apa pun.

Selain itu, saya telah memverifikasi bahwa HAL_ETH_IRQHandler tidak pernah dipanggil.

Ada masalah dengan PHY?

Pada titik ini, saya menduga PHY saya sendiri yang harus disalahkan.

Untuk menyelidiki lebih lanjut, saya melampirkan Saleae Logic Pro 16 saya ke semua sinyal yang relevan, dan melihat ada banyak lalu lintas di TX0 / TX1, serta jalur RX0 / RX1. Berikut adalah penangkapan beberapa lalu lintas RX dengan clock input 25 MHz:

RX_ERR rendah sepanjang waktu, kecuali jika saya mencoba untuk menangkap output clock 50 MHz (yang jelas-jelas menantang dengan perangkat seperti Saleae): dalam hal itu, RX_ERR secara bertahap dipotong tinggi untuk beberapa paket (yang sebenarnya merupakan pertanda baik - pin tampaknya berfungsi).

Langkah selanjutnya

Saya sudah mencoba secara manual mengaktifkan interupsi ETH dengan memanggil HAL_NVIC_EnableIRQ(ETH_IRQn);setelah tcpip_init()dipanggil dalam MX_LWIP_Init()tugas, dan itu tampaknya tidak memperbaiki masalah. Saya tidak sepenuhnya yakin interupsi rutin Ethernet bahkan seharusnya dipanggil - itulah hal yang menantang dengan memunculkan desain baru; Saya berjuang untuk menentukan perilaku sistem yang tepat, jadi saya kemudian dapat menentukan perbedaan pengaturan saya.

Meskipun saya telah menggunakan STM32 / STM32CubeMX / FreeRTOS sebelumnya, saya belum pernah menggunakan periferal Ethernet STM32, dan satu-satunya pengalaman saya dengan hal ini adalah pada sistem Linux tertanam kustom, yang sepertinya selalu bekerja di luar kotak. Ini wilayah baru bagiku!

Saya yakin ada kotak centang bodoh di suatu tempat atau Ethernet_EnableReceive()fungsi magis yang saya lupa panggil, tetapi saya tidak dapat menemukan dokumentasi yang menyarankan perlunya mengaktifkan hal-hal itu secara eksplisit, dan tulisan yang saya lihat di internet semuanya karena tidak berhubungan masalah.

Jika ada yang punya ide, saya ingin bantuan!

Tambahan: Menyingkirkan FreeRTOS

Hanya untuk menghilangkan hal-hal, saya telah menghapus komponen proyek FreeRTOS, kembali ke proyek bare-metal. Di loop utama saya, saya menelepon MX_LWIP_Process(). Metode ini harus menghilangkan kebutuhan akan interupsi, tetapi tidak memperbaiki masalah; Saya masih tidak dapat menerima bingkai. Ini membuat saya berpikir ada sesuatu dalam kode ETH HAL yang dihasilkan oleh STM32CubeMX.

Larutan

Untuk berjaga-jaga jika seseorang menemukan pertanyaan ini di kemudian hari, masalahnya ternyata adalah pin RXD0 dan RXD1 yang terbalik. Inilah sebabnya mengapa saya dapat melihat lalu lintas pada penganalisis logika saya, tetapi itu tidak diterjemahkan oleh MCU saya.

Seperti yang ditunjukkan seseorang, magnet yang saya gunakan asimetris, dan tidak boleh digunakan untuk auto-MDI-X. Saya belum punya masalah. Saya mengantisipasi salah satu dari dua hal yang terjadi: - magnet tidak benar-benar berfungsi dalam orientasi lain, tetapi karena semua yang saya miliki menggunakan auto-MDI-X, papan saya pada dasarnya tetap dalam konfigurasi yang berfungsi, sementara perangkat lain menyala kabel mengarahkan sinyalnya agar sesuai. - magnetics memberikan integritas sinyal yang sesuai dengan jangka pendek Ethernet, tetapi analisis jangka panjang akan menunjukkan tingkat penurunan paket yang lebih tinggi atau masalah pada jangka yang lebih lama.

Sejujurnya, tidak jelas bagi saya mengapa akan menjadi masalah di sisi mana transformator 1: 1 filter garis dipasang, jadi di luar aplikasi PoE, saya tidak yakin mengapa desain simetris vs asimetris akan berpengaruh.

Anda telah menginstal wireshark pada PC, dan seperti yang Anda katakan Anda menggunakan adaptor USB-to-LAN. Saya tidak yakin pada titik fisik mana Wireshark menangkap paket-paket dalam pengaturan Anda, dan karenanya merupakan pertanyaan yang bagus jika paket keluar benar-benar muncul di jaringan fisik . Saya sarankan Anda menghubungkan PC lain dengan antarmuka jaringan, dan melihat apakah PC ini dapat berkomunikasi satu sama lain dengan membandingkan output Wireshark pada mereka.

Output wireshark Anda tidak menunjukkan masalah apa pun, PC mengumumkan tiga kali bahwa itu ada di jaringan lokal dan memiliki alamat IP 10.0.0.1 (jika akan menerima balasan ke salah satu dari 3 permintaan ARP ini maka OS akan muncul dengan konflik alamat IP).

Kemudian, papan Anda terus bertanya Siapa yang memiliki 10.0.0.1? Beritahu 10.0.0.2 dan PC balasan dengan 10.0.0.1 adalah pada ... . Pertanyaannya adalah mengapa itu terjadi dalam lingkaran:

1. board tidak secara fisik menerima paket respons yang dikirim oleh PC;
2. board mengharapkan sesuatu yang lain, atau paket yang diterima rusak, dan itu membuang paket itu.

Jadi, sebagai langkah pemecahan masalah berikutnya, ambil PC lain dengan antarmuka Ethernet "normal", instal Wireshark di atasnya, konfigurasikan jaringannya dengan cara yang sama seperti yang Anda lakukan untuk naik, dan cobalah telnet 10.0.0.1 80 dan lihat bahwa muncul di Wireshark pada kedua mesin. Dengan cara ini Anda akan memastikan bahwa PC dengan adaptor USB-to-Ethernet berfungsi dengan baik.

Langkah Anda selanjutnya akan tergantung pada hal-hal yang Anda lihat di Wireshark ini.

Memperbarui:

Saya menerima paket, jika pin RXD0 / D1 tidak menunjukkan aktivitas, benar?

Tidak benar. Anda ingin berpikir bahwa papan Anda menerima paket. Anda melihat ada beberapa perubahan pada level sinyal input PHY, tetapi mereka tidak selalu mewakili paket yang valid. Fakta bahwa RX_ERR tidak beralih tidak langsung meyakinkan saya bahwa PHY bekerja dengan baik pada acara yang masuk, atau informasi yang masuk membuat paket yang tepat.

Bagaimanapun, terserah Anda, teori pemecahan masalah saya sederhana - Anda harus memastikan di tingkat yang lebih tinggi di mana Anda menghadapi masalah, dan kemudian menggali bagian masing-masing dari desain. Menggali semua bagian dan mencurigai semuanya tidak ada gunanya. Akan sangat beruntung jika Anda menemukan masalah dalam menyebarkan fokus; Anda sudah mencoba menyederhanakan perangkat lunak, jika tidak berhasil Anda kemungkinan besar akan mulai mengganti chip.

Saya tidak berpikir langkah pemecahan masalah saya sangat rumit untuk memastikan bahwa PC lain dapat berkomunikasi dengan PC dengan dongle dan membuktikan saya salah atau benar, dan dengan demikian memastikan bahwa Anda benar menggali jauh ke dalam mencurigai PHY board, MAC dan perangkat lunak yang bekerja pada mereka.

Maaf untuk menghidupkan kembali topik ini. Saya tidak bisa lulus tanpa menyebutkan pengalaman saya.

Saya telah menggunakan HR911105A ini (RJ45 dengan magnet) dengan salah satu proyek saya.

HR911105A: Sekilas, satu hal yang menarik perhatian saya adalah koneksi antara LAN8720 dan RJ45 sesuai skema Anda.

Karena saya melihat bahwa koneksi terlihat crossover. Meskipun sistem yang terhubung sebagian besar menggunakan MDI-X dan karenanya mendeteksi pasangan Receive / Transmit, akan lebih baik untuk memberikan koneksi yang kurang membingungkan seperti itu:

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

Pin #4 and Pin #5(jadi resistor pull-up 49.9R) akan bagus jika terhubung ke 3V3_ANdalam skema Anda sementara sisi lain harus digabungkan ke GND melalui kapasitor (0,1uF atau 0,022uF).