I am trying to get the FreeRTOS TCP/IP stack going on a STM32F745 with a LAN874A phy on a custom board. I’m using the latest network interface drivers at:
I’m going from my PC (192.168.1.33) through a switch (192.168.1.10) to the device (192.168.1.125).
Everything seems to come up OK to a point:
PHY ID 7C130
xPhyReset: phyBMCR_RESET 0 ready
+TCP: advertise: 01E1 config 1000
prvEthernetUpdateConfig: LS mask 00 Force 1
Autonego ready: 00000004: full duplex 100 mbit high status
PHY reg dump
reg 0 1100
reg 1 782D
reg 2 0007
reg 3 C131
reg 4 01E1
reg 5 C1E1
reg 6 006F
reg 7 2001
reg 8 4000
reg 9 FFFF
reg 10 FFFF
reg 11 FFFF
reg 12 FFFF
reg 13 0000
reg 14 0000
reg 15 0000
reg 16 0041
reg 17 0002
reg 18 60E0
reg 19 FFFF
reg 20 0000
reg 21 0000
reg 22 0000
reg 23 0000
reg 24 9B9D
reg 25 0000
reg 26 0000
reg 27 000A
reg 28 4000
reg 29 00C8
reg 30 0000
reg 31 1058
Network buffers: 96 lowest 96
Link Status is high
IP Address: 192.168.1.125
Subnet Mask: 255.255.255.0
Gateway IP Address: 192.168.1.1
DNS server IP Address: 188.8.131.52
Network buffers: 96 lowest 95
and I am getting gratuitous ARPs being sent out every 20 seconds as seen via wireshark. I see that the transmit interrupt does get called when the ARP gets sent out, so interrupts running.
Now, when I try to ping the device from the PC I get no response. There is output from the PHY visible on the oscilloscope at the RXD0/RXD1 inputs to the STM32. I verified that the GPIO pins are setup correctly for the part for ethernet ( alternate function 11 ) and that the hardware is correct. I NEVER see a receive interrupt. It is enabled. Also, the MAC filter is set to receive broadcast messages.
I’m looking for ideas on what I could be missing here…I have run out of them !
Thanks ! Mark
And you enabled
ipconfigREPLY_TO_INCOMING_PINGS in your
Yes, it is enabled.
I’m mainly puzzled by the lack of any ethernet receive interrupts, when there is clearly data coming into RXd0/RXD1
Errm… yes. I’ve reread your post and noticed the missing ETH RX interrupt
And that you checked the MAC (filter) setup. RX DMA is surely also armed properly.
Did you just try a TCP connection or sending UDP packets to the device ?
This might start with an ARP request to the device which should then ARP reply.
I think the provided drivers are pretty good and working but as far as I know they rely on HAL. Maybe post the (cube) version you’re using.
I don’t use cube/HAL and can’t really help with it, unfortunately.
Thanks Hartmut. Right now I’m just trying a TCP connection.
Binding socket to port 10000
Socket 10000 -> 0ip:0 State eCLOSED->eTCP_LISTEN
Heap: current 1128 lowest 1128
Network buffers: 96 lowest 95
Although I don’t think it has anything to do with my present problem ( no DMA receive interrupts ), I’m wondering about the “heap” memory. is 1128 enough ?
Well, it depends Which heap is it and is (this) heap used for something.
It’s the heap used by FreeRTOS. I have configTOTAL_HEAP_SIZE set to 46K in FreeRTOSConfig.h.
The funtion that calls this debug print of the current heap is in vPrintResourceStats() in FreeRTOS_IP.
I should also mention I’m using heap_4
Then there is not much left to dynamically create FreeRTOS resources (tasks, queues, etc) in case you need that (later).
configUSE_MALLOC_FAILED_HOOK will easily show you if you run out of heap.
1128 bytes left sounds very minimal. I also suspect that your pvPortMalloc is failing. Like Hartmut said, have you enabled
configUSE_MALLOC_FAILED_HOOK and defined
It is possible to run the FreeRTOS+TCP stack on a CPU with 64 KB of RAM, but you will have to configure it to get a small RAM footprint. Like you might want to disable the use of TCP sliding windows (
#define ipconfigUSE_TCP_WIN 0).
By the way, the official repo of FreeRTOS+TCP is here:
That is where the pull requests are being done, and also a lot of testing.
If it helps, here you find a STM32F7 project that works fine. You may want to compare the initialisation in main.c.
Thanks for all the information Hein. I have plenty of SRAM available, so I increased configTOTAL_HEAP_SIZE to 200K, and added the
vApplicationMallocFailedHook() and enabled configUSE_MALLOC_FAILED_HOOK.
Thanks for the code link. I will study that and see what I can learn.
It almost seems like the MAC is not transferring the received frames to the memory locations pointed to by the DMA descriptors. An examination of those memory locations show that nothing is being written there. The descriptors themselves are located in the DTCM RAM space.
I tried playing with the configurable threshold value but that did not affect anything.
OK still no luck getting this to work. I’ve tried a number of different things…including disabling auto negotiation and just using fixed values of duplex mode and speed., physically swapping RXD0/RXD1 ( a long shot but I saw someone had that issue ), and varying configurable receive DMA FIFO threshold.
I have studied the code referenced above at
and examined the initialization. It looks basically the same as my initialization ( not surprising, since we are both using the same network interface driver ), except for the board specific items ( like ethernet pin numbers - which I have verified to be correct multiple times ). MAC and DMA configuration and interrupt registers appear to all be set correctly when I debug the running code. But the DMA buffers remain empty, and a receive interrupt never happens.
One difference between the aforementioned code and mine is that I am using FreeRTOS_TCP version 2.3, and the other is 2.2.2. But I don’t see how that could be the problem. The network interface code is the same though.
except for the board specific items ( like ethernet pin numbers -
which I have verified to be correct multiple times )
Does you board have a MII or a RMII? Unless you define
ipconfigUSE_RMII, for a
STM32F7xx it will be assumed that you have a Reduced Media-Independent Interface:
#define ipconfigUSE_RMII 1
#define ipconfigUSE_RMII 0
#endif /* STM32F7xx */
#endif /* ipconfigUSE_RMII */
because that is how the evaluation boards are set-up.
Yes, ipconfigUSE_RMII is 1, I am using a Reduced Media-Independent Interface, and the GPIO pins are set accordingly for this ( AF11 ).