2024-02-05 11:27 AM - edited 2024-02-05 11:54 AM
I am not a hardware tech, but am familiar with some bit-fiddly work in software. Still, I am new to modern firmware development, and could likely use a pointing finger.
I've been tasked to write firmware with these two components.
The board is built, and I have a schematic for it.
Using STM32CubeIDE, I've connected the pins according to what I see in the schematic.
I also set up LWIP and FreeRTOS, in an effort to reduce much of the bit twiddling down to a more familiar environment for myself... again, using the STM32CubeIDE Pinout and Configuration tool. I enabled DHCP, to get this to fetch its own IP address, but that's about it. If it helps, I'm using version 1.14.1 of STM32CubeIDE.
As mentioned in the subject header, the MCU is an STM32F107VC chip, and the ethernet component is actually a 3-port switch (the KSZ8863FLL). I can control this over an MII interface.
I also have an STLink/V2 programmer-debugger, which allows me to step in the code... a rather valuable feature, frankly. I'll have the ability to read logging later this week, when that part comes in.
I have an ethernet cable plugged into one of the ports on the switch, and the other end is plugged into another switch in my local area network (which serves DHCP).
When I start, the ethernet component seems (at least within code) to set up properly... I see no errors or timeouts.
But:
Here's part of the schematic (that details the ethernet bits). ETH_MII_RX_ER is going through a 10k 0603 resister into ground, and ETH_MII_PPS_OUT is not used.
And, on the KSZ8863FLL:
- Trey
Solved! Go to Solution.
2024-03-22 05:16 AM
The problem appears to be related to hardware, as replacing the KSZ8862FLL with a KSZ8862MLL seems to allow one of the ports to work now, according to the hardware fellow I am working with.
2024-03-22 05:16 AM
The problem appears to be related to hardware, as replacing the KSZ8862FLL with a KSZ8862MLL seems to allow one of the ports to work now, according to the hardware fellow I am working with.