Ethernet Stack restart

shaanktn wrote on Thursday, May 04, 2017:

Hi all,
I am in a scenario where I need to restart/reinit the Ethernet stack. I have STM32Fxx driver and code, Is there any built-in function to do the same ? I will be setting the new IP and related params before this reset. MAC ID will be same, so I believe I don’t have to recreate the IP task. HAL_ETH_Start/Stop is not helping much there. I am able to get my required functionality done with just FreeRTOS_SetIPAddress() and others params, but not reliable, few times I get issue(for which I am thinking of reset now) as I have multiple tasks and control is sliced to other tasks also. The issue is after I try to set new IP, I see the timeout for ping requests(nothing from stack will be responsive), I don’t see any assert/hang. Is there any other way to read the device IP other than FreeRTOS_GetIPAddress()?. Any input on phy/stack reset related will be helpful.

Thanks,
Shaank

shaanktn wrote on Monday, May 08, 2017:

I am receiving the “ETH_DMA_IT_RO” status in IRQ handler, even if I reset it, not helping. It toggles back to same. What are the possibilities for this and how can I resolve this ?

heinbali01 wrote on Monday, May 08, 2017:

Hi Shaank,
The latest version of the STM32F4 driver is not on /Labs yet, but you can download it here

I am receiving the “ETH_DMA_IT_RO” status in IRQ handler,
even if I reset it, not helping. It toggles back to same.
What are the possibilities for this and how can I resolve this ?

You’re getting this error:

    /*
     * Bit 4 ROS: Receive overflow status
     * This bit indicates that the receive buffer had an
     * overflow during frame reception. If the partial 
     * frame is transferred to the application, the
     * overflow status is set in RDES0[11].
     */
    #define ETH_DMA_IT_RO    ((uint32_t)0x00000010)  /*!< Overflow interrupt */

My feeling says: that should never occur!
Are you supplying internal SRAM to the DMA, both for the descriptors as well as for the network buffers? Do you give proper memory, or have the descriptors been corrupted?
Are you using any external (S)DRAM at all?
Ethernet is fast, the DMA must transport data at 10 MByte per second. Do you have concurrent DMA transports? Can you play with their priorities?
I will answer your earlier question later on. Hein

shaanktn wrote on Monday, May 08, 2017:

Hey Hein,
I use external SDRAM for my firmware. Anyways its not the throughput/performance issue is problem for me it looks like, I have multiple threads being sliced(2ms) in my platform, doing different activities like write to flash/read/display/ etc. So when new config is being downloaded, I feel it takes the ticks away from emac task for a while. I have reduced the emac task priority and its been sliced by my task scheduler. Will that cause the problem for stack?
Bwn, first qn is more of front end observation, we can ignore now !
Thanks,

heinbali01 wrote on Tuesday, May 09, 2017:

I am in a scenario where I need to restart/reinit the Ethernet stack.
I have STM32Fxx driver and code, Is there any built-in function to do
the same ? I will be setting the new IP and related params before this
reset. MAC ID will be same, so I believe I don’t have to recreate the
IP task.

That is right, both the IP-task as well as the EMAC task ( prvEMACHandlerTask ) will keep on running.
The EMAC does not need a reset. If you want to change the MAC-address ( which you do not want to ), you can write the new MAC address into some registers.
You could do that every time when xNetworkInterfaceInitialise() is called by calling prvMACAddressConfig().

HAL_ETH_Start/Stop is not helping much there.

Right, the EMAC settings haven’t change so the EMAC is not the problem.

I am able to get my required functionality done with just
FreeRTOS_SetIPAddress() and others params, but not reliable, few times
I get issue (for which I am thinking of reset now) as I have multiple
tasks and control is sliced to other tasks also. The issue is after I
try to set new IP, I see the timeout for ping requests (nothing from
stack will be responsive), I don’t see any assert/hang. Is there any
other way to read the device IP other than FreeRTOS_GetIPAddress()?.
Any input on phy/stack reset related will be helpful.

I think that you won’t be able to solve that problem on the embedded side. The problem is that you change a binding of a MAC-address with an IP-address. The host that you are working on is still using the old binding.
If my reasoning is true, the following should help within Windows: start a command prompt as an administrator. Enter the command arp /d * to clean the local ARP tables.
For Linux: sudo ip -s -s neigh flush all.

Beside that, you might see some time-outs, things might not work immediately.

Another issue that may occur is that the device does not connect through TCP after rebooting. That may be caused by the fact that your ipconfigRAND32() function does not get a unique seed after booting.
When a TCP socket is bound to port 0, a random port number will be assigned. After a reboot, these port numbers should start at a different number.
Another thing that should be random is the Initial Sequence Number in a TCP connection. When the device uses the same port and the same initial sequence number, the connection is bound to fail.
Hein

heinbali01 wrote on Tuesday, May 09, 2017:

Hi Shaank,

I use external SDRAM for my firmware.

Are you providing SDRAM memory to DMA? Either as data buffer or as DMA descriptors?

If so, I would try to use internal SRAM for that purpose, and the DMA error ETH_DMA_IT_RO will disappear.

Anyway, its not the throughput/performance issue is problem for me
it looks like, I have multiple threads being sliced(2ms) in my platform,
doing different activities like write to flash/read/display/ etc.
So when new config is being downloaded, I feel it takes the ticks away
from emac task for a while. I have reduced the emac task priority and
its been sliced by my task scheduler. Will that cause the problem for stack?

The ETH_DMA_IT_RO error is not caused by tasks that are too late or too slow.

We advice the following scheme for priorities when using FreeRTOS+TCP:

Prio-4 High-priority tasks that do not use +TCP
Prio-3 prvEMACHandlerTask, deferred EMAC interrupt handler
Prio-2 IP-task ( ipconfigIP_TASK_PRIORITY )
Prio-1 Application tasks that do use +TCP

Regards.

shaanktn wrote on Friday, May 12, 2017:

Hi Hein,
Thanks for the inputs, also for thread priority scheme. Ideally its not setting IP or those API’s causing it(which I thought its that time causing the issue), inbetween if I take some time away from enet thread at some particular instance, faced the issue.
Are you providing SDRAM memory to DMA? Either as data buffer or as DMA descriptors?
Yes, I provide SDRAM to DMA and using it as DMA descriptors.
And the board starts working back after the restart.
Now I increased the ETH_RXBUFNB to 16 from 4, it works better than before. Internal SRAM is rused by for bootloader and did not try moving DMA there yet.

heinbali01 wrote on Friday, May 12, 2017:

Are you providing SDRAM memory to DMA? Either as data buffer or as DMA descriptors?

Yes, I provide SDRAM to DMA and using it as DMA descriptors.

Well, it doesn’t matter unless you see DMA overflow (ETH_DMA_IT_RO) of underflow (ETH_DMA_IT_TU) errors.

shaanktn wrote on Friday, May 12, 2017:

Hi Hein,
So you suggest moving it to internal SRAM will be the best approach ? Increasing the buffer also expected to give issues at point of time ?

heinbali01 wrote on Friday, May 12, 2017:

Only in case you still see one of these errors: ETH_DMA_IT_RO or ETH_DMA_IT_TU.
What happens if you define ETH_RXBUFNB as 2 ? Will you see under- or overflow errors?

shaanktn wrote on Friday, May 12, 2017:

When I increase it to 16 I see the ETH_DMA_IT_RO very rare. If I decrease it to 2, I see it very much easily! Between I never got ETH_DMA_IT_TU. I see it as 0x8010 (heth->Instance->DMASR in HAL_ETH_IRQHandler).

heinbali01 wrote on Friday, May 12, 2017:

Thanks for trying, now I’m convinced that the overflow error only means that there are not enough buffers. And it has nothing to do with the speed of the memory itself. Regards.

shaanktn wrote on Wednesday, May 17, 2017:

Hi,
any info regarding ETH_DMA_IT_RBU bit being set ? This should be cleared in IRQ handler ? Or I will have to check on buffers itself ?