I’m trying to run FreeRTOS PLUS TCP on ST32F409 + PHY(DP83848I). I am in a state where vApplicationIPNetworkEventHook_Multi is called and eNetworkEvent == eNetworkUp.
I naively believed that in this state, all ST peripherals were guaranteed to be correctly configured and PHY initialized. But I was overtaken by disappointment.
The first thing I noticed is that the DHCP protocol does not work. I disabled DHCP, set everything to static. I tried to ping my device from Windows. I watched what was happening using wireshark. and discovered that when I call ping, windows generates an ARP request that my device does not process.
Why doesn’t the FreeRTOS PLUS TCP device respond to an ARP request? Clearly something is not configured. I remind you that vApplicationIPNetworkEventHook_Multi is called and eNetworkEvent == eNetworkUp.
so you are saying that your device does not process any incoming network packets? Have you traced the control flow so far that you can at least determine how far those packets go through the stack? Ie do inbound packets generate an Rx interrupt, if yes, do they look like on the wire? If ok, you should be able to monitor where they get dropped? Or could it be the case that your system encounters a fault, so aside from missing network packets, nothing else works anyways? Does your xTicks counter increment?
Hello @mml, if you have not used FreeRTOS+TCP before it might be a good idea to use a pre-configured example in windows simulator.
If you have a prior experience with +TCP, then what @RAc suggested above should be able to help you narrow down the issue. Currently, we only have the information that the device doesn’t process any packet. The cause can be anything from a faulty configuration, buggy code to a broken PHY. Stepping through the code and adding breakpoints should help.
Let us know what you figure out.
Thanks,
Aniruddha
Неllo @kanherea! I have already tried using FreeRTOS+TCP on the Windows simulator. What I tried worked. Now the task is to work on my target board.
I’m sure I didn’t configure ST enough.
Hello @RAc !
Yes, today I’ll start debugging by setting breakpoints from top to bottom in order to find what is not being called.
But I have questions that bother me right away.
The only thing I did was I wrote a function
void HAL_ETH_MspInit(ETH_HandleTypeDef* heth)
{
GPIO_InitTypeDef GPIO_InitStruct;
if(heth->Instance==ETH)
{
__HAL_RCC_ETH_CLK_ENABLE();
__HAL_RCC_GPIOC_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();
__HAL_RCC_GPIOB_CLK_ENABLE();
/**ETH GPIO Configuration
PC1 ------> ETH_MDC
PA1 ------> ETH_REF_CLK
PA2 ------> ETH_MDIO
PA7 ------> ETH_CRS_DV
PC4 ------> ETH_RXD0
PC5 ------> ETH_RXD1
PB11 ------> ETH_TX_EN
PB12 ------> ETH_TXD0
PB13 ------> ETH_TXD1
*/
GPIO_InitStruct.Pin = GPIO_PIN_1|GPIO_PIN_4|GPIO_PIN_5;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_7;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
GPIO_InitStruct.Pin = GPIO_PIN_11|GPIO_PIN_12|GPIO_PIN_13;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF11_ETH;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
}
HAL_NVIC_SetPriority(ETH_IRQn, APP_ETH_PRIO, 0);
HAL_NVIC_EnableIRQ(ETH_IRQn);
}
and wrote
#define ipconfigUSE_RMII (1)
in FreeRTOSIPConfig.h
I’m worried that I’m nowhere:
-
Neither did the DMA initialization. I don’t know if I should do this or if +TCP does it itself?
-
I don’t know if +TCP supports my PHY(DP83848), or do I need to add something?
-
ST’s HAL library can work with ETH via polling, interrupts or DMA. Which method does +TCP choose and how to set it?
-
I have not configured ETH descriptors anywhere. It does
+TCP during initialization or should I do it? Or does +TCP operate in a mode where ETH descriptors are not used at all?
Your PHY is very widely used and has been around for a long time, so I would be surprised if you would not find a pre existing driver that suits your needs.
One thing you should be aware of, though, is that “+TCP supports my PHY” is wrong wording. First of all, as you figured out yourself, the PHY also has wiring properties that must be adjusted (MII vs. RMII and PHY address). Also, +TCP is a middleware layer that needs to be adapted to the target hardware individually, and the available drivers are normally not part of the +TCP code base but voluntary contributions.
Unless your target is, say, an evaluation board manufactured by ST, you very likely have to make some degree of adaption to the suite. If your board is a custom (self made) one, you also face the possibility of hardware bugs. If you have bought the board from a third party, there are very likely sample applications for that board, please reach out to the manufacturer.
Edit: That very combination of MCU and PHY is very very common, I have worked with that combo in at least two customer installations, however both running lwip as the network middleware. If you really get stuck trying to get your software to work, an option would be to try existing FreeRTOS/lwip sample apps (there are quite a few around) and if that works, compare the deltas in the PHY and ETH drivers. I would not recommend switching to lwip altogether, though.
Today’s debugging showed that there are no problems with receiving packets from the line. The packet is safely delivered to the IP layer, where it passes all the necessary checks and is identified as an ARP packet. The ARP processing function is called. The request is processed safely and the returned response is generated.
This concludes my debugging for today. Probably tomorrow I will discover that there is a problem with the transmission.
Regarding my four questions about initializing peripherals. I made sure that the +TCP library did all the necessary initialization itself and fully. If this were not so, the receiving direction would not work.
Board of our design, not purchased.
Yes. No packets are transmitted to the line.
In file FreeRTOS_IP.c, in the vReturnEthernetFrame function, the code
if( xIsCallingFromIPTask() == pdTRUE )
{
iptraceNETWORK_INTERFACE_OUTPUT( pxNetworkBuffer->xDataLength, pxNetworkBuffer->pucEthernetBuffer );
( void ) pxInterface->pfOutput( pxInterface, pxNetworkBuffer, xReleaseAfterSend );
}
is executed and Wireshark shows that nothing went into the line.
well, since the board is your own design, you may be looking at a bug in the hardware… or a faulty PHY?
I had to correct the configuration of the TX pins.
All! I solved the problem with running +TCP on my board. I am very glad that I chose the wonderful +TCP library. It freed me from a huge amount of work about setting up ST peripherals. Moreover, everything works on FreeRTOS principles.