Strugling with porting Eth drivers for STM32H563ZI

My current project can be found here - GitHub - BjornArend/FreeRTOS-PLUS-TCP-H563: Attempt at porting Eth drivers for FreeRTOS-plus to work on STM32H563ZI (I have excluded most of the general code that stm32cubeide generates)

My project currently builds fine and runs without any errors being reached.

-My problem is that when using a static IP the function vApplicationIPNetworkEventHook is called with eNetworkUp which creates the client socket and attempts to send data to it but this does not happen. The board does not show up on the network and I am unable to ping it.

  • When using DHCP it creates the DHCP socket and reaches the DHCP state of eWaitingOffer (never gets further than this) but I haven’t seen the DHCP request on Wireshark. Eventually DHCP fails and reverts back to static IP yet never calls vApplicationIPNetworkEventHook with eNetworkUp so sockets task never gets created.

I fear that when porting the H7 drivers for the H5 I may have used the wrong registers and am now stuck on what other debugging I could do to see what I did wrong.

@arend

Where is the network interface implemented in your project? This should interface the +TCP stack with your ethernet drivers. Example

Hey there,

Its currently under - Middlewares/Third_Party/FreeRTOS-Plus-TCP/source/portable/NetworkInterface/STM32Hxx/NetworkInterface.c - in the github repository its in the same path just remove Middlewares and Third_Party.

The ethernet drivers I tried to port are under STM32H5xx_Hal_Driver.

Just to add to my original comment once vApplicationIPNetworkEventHook with eNetworkUp is called (only happens with static IP) i print out the addresses and they all look correct yet my board still doesn’t show up on the network.

The phy is LAN8742a which i see is supported.

Your protable folder doesn’t contain NetworkInterface folder.

Apparently you do not have network connctivity at all. If your PHY and MCU is generally supported, check the variable network paramters ie RMII vs. MII wiring and PHY address.

I see that now, sorry about that I must have uploaded the incorrect folder, however, in my project I have the NetworkInterface.c file that you shared earlier. I have updated the repository to the correct folder.

I will have a look at that now,

Also just to add on I have tested this hardware with an LWIP application that ran perfectly, i now just need an RTOS and well LWIP doesn’t work well.

I have solved one of the problems which was that my TX buffers were too large and causing a timeout. However this has not solved my over all problem of no network connectivity. when using Debug printf this is what comes out of the terminal.

prvIPTask started
PHY ID 7C130
xPhyReset: phyBMCR_RESET 0 ready
+TCP: advertise: 01E1 config 3100
prvEthernetUpdateConfig: LS mask 00 Force 1
Its working
prvIPTask started
PHY ID 7C130
xPhyReset: phyBMCR_RESET 0 ready
+TCP: advertise: 01E1 config 3100
prvEthernetUpdateConfig: LS mask 00 Force 1
Autonego ready: 00000004: full duplex 100 mbit high status
Link Status is high
IP Address: 192.168.0.80rn
Subnet Mask: 255.255.255.0rn
Gateway IP Address: 192.168.0.1rn
DNS server IP Address: 8.8.4.4rn
FreeRTOS_connect: 1024 to c0a800ebip:12345
Socket 1024 → c0a800ebip:12345 State eCLOSED->eCONNECT_SYN
ARP for c0a800ebip (using c0a800ebip): rc=0 00:00:00 00:00:00
Connect[c0a800ebip:12345]: next timeout 1: 500 ms
Network buffers: 60 lowest 59
Heap: current 3176 lowest 3080
TX descriptors 1/8
ARP for c0a800ebip (using c0a800ebip): rc=0 00:00:00 00:00:00
Connect[c0a800ebip:12345]: next timeout 2: 500 ms
TX descriptors 2/8
ARP for c0a800ebip (using c0a800ebip): rc=0 00:00:00 00:00:00
Connect[c0a800ebip:12345]: next timeout 3: 500 ms
TX descriptors 3/8
Connect: giving up c0a800ebip:12345
Move from eCONNECT_SYN to eCLOSE_WAIT
Socket 1024 → c0a800ebip:12345 State eCONNECT_SYN->eCLOSE_WAIT
FreeRTOS_connect() stopped due to an error
FreeRTOS_closesocket[1024 to c0a800ebip:12345]: buffers 60 socks 0

Does xNetworkInterfaceOutput get called to send data on the wire? If yes, do you see any data going out on the wire in the Wireshark capture?

1 Like

Hi there,
sorry I have been busy with another project. Yes xNetworkInterfaceOutput does get called. I don’t see anything on wireshark however that is because the function gets stuck at:

configASSERT( pxDescriptor->xDataLength <= sizeof( Tx_Buff[ 0 ] ) );

Can you suggest how large to make my RX and TX buffers?
The buffer does populate but the code does not pass that point.

I see that the value 1536 is used in the existing NetworkInterface. Can you try that?

I gave that a try, this now caused a new issue where the TX buffers timeout printing this to the terminal.

emacps_send_message: Time-out waiting for TX buffer

I am going to re-port the drivers on Monday most likely. I rushed through it because our custom board was arriving and I needed to write test software on it.

If I make any progress or need some more help I will let you know…

You can look at my draft here if you want help. I tried to include just about every currently available capability of HAL drivers. Haven’t yet decided if it’s worth finishing entirely though.

1 Like

Thank you so much, Ill get to testing this now. Quick question, am I understanding correctly that your code uses the standard ST generated ethernet drivers while the NetworkInterface.c integrates them with FreeRTOS_Plus_TCP?

That is what I generally do. I don’t take on the problem of writing the ethernet drivers too. You should try and use the drivers to talk to the hardware while you use the NetworkInterface.c to:

  1. Setup the driver correctly using APIs.
  2. Move data to and from the vendor driver to the +TCP stack.

We will keep an eye out on this thread - let us know if you face any issues.

- Aniruddha

Sorry for not getting quick responses back to you. I still seem to be having issues with connectivity using FreeRTOS_Plus. While the code given by @HTRamsey seems to work ALOT better than my attempt, I still see no transmissions on wireshark. I have connected my pc, router and board to a switch, this setup has been working to monitor packets when using LWIP.

Here are my current terminal logs:
With DHCP enabled:

FreeRTOS_AddEndPoint: MAC: 00-10-c0-b0-63 IPv4: c4ip
prvIPTask started
vIPSetDHCP_RATimerEnableState: Off
prvCloseDHCPSocket[63-c4]: closed, user count 0
PHY ID 7C130
xPhyReset: phyBMCR_RESET 0 ready
+TCP: advertise: 01E1 config 3100
Autonego ready: 00000004: full duplex 100 mbit high status
HAL_ETH_RxAllocateCallback: failed
vDHCPProcessEndPoint: enter 0
DHCP-socket[63-c4]: DHCP Socket Create
prvCreateDHCPSocket[63-c4]: open, user count 1
prvInitialiseDHCP: start after 250 ticks
vDHCP_RATimerReload: 250
vDHCPProcessEndPoint: exit 1
vDHCPProcessEndPoint: enter 1
vDHCPProcess: discover
vDHCPProcessEndPoint: exit 2
HAL_ETH_RxAllocateCallback: failed
pxEasyFit: ARP c0a80001ip → c0a800f2ip
HAL_ETH_RxAllocateCallback: failed
HAL_ETH_RxAllocateCallback: failed
ipARP_REQUEST from c0a80001ip to c0a800f2ip end-point 0ip
vDHCPProcessEndPoint: enter 2
vDHCPProcess: discover
vDHCPProcess: timeout 10000 ticks
vDHCPProcess: discover
vDHCPProcess: timeout 20000 ticks

after this it timesout and the board is not seen on the network

With DHCP disabled:

FreeRTOS_AddEndPoint: MAC: 00-10-c0-b0-63 IPv4: c4ip
prvIPTask started
PHY ID 7C130
xPhyReset: phyBMCR_RESET 0 ready
+TCP: advertise: 01E1 config 3100
Autonego ready: 00000004: full duplex 100 mbit high status
HAL_ETH_RxAllocateCallback: failed
HAL_ETH_RxAllocateCallback: failed
pxEasyFit: ARP c0a80065ip → c0a8006fip
HAL_ETH_RxAllocateCallback: failed
HAL_ETH_RxAllocateCallback: failed
ipARP_REQUEST from c0a80065ip to c0a8006fip end-point a0a0ac8ip

Again the board is not seen on the network.

The RxAllocateCallback function does complete 4 times before it starts failing and giving that error.

Any idea where I went wrong?

Again, have you made sure that the communication between your MCU and the PHY works? Is the PHY address and the protocol type (MII vs RMII) matching your hardware? You can hook into the PHY interface and try to determine if you see anything meaningful.

1 Like

Here are some more examples. Check out the H7 as the registers are identical to H5, although the H5 and H7 HAL drivers are out of sync so there are some small differences. Ignore the H5 as I never got around to buying an H5 unfortunately. Additionally, there are a couple people in the comment section of my draft PR that have gotten H5 to work, maybe their repos are public and you can check them out. Also, make sure your memory map is set up correctly and prefer to use BufferAllocation1. I have a modified BufferAllocation that you can use in my ETH_Test repo.

1 Like

Morning, I have have just implemented your version of the buffer management and well I somehow managed to turn my serial terminal into a very basic wireshare that shows every ARP sent on the network. Im fairly certain I know how I messed this up and should be able to fix it.