Hi Zachary,
Thanks for the response. Unfortunately, it doesn't seem to help. The
ST code basically does what you say, except that the RBU interrupt was
not enabled. The RBU flag is cleared in the main task if set (not in the
interrupt), and the DMARPDR register is written to restart reception.
I modified the ST code do what you said you did, which is enable the RBU
interrupt (and AIS) and send a task message to my input handler. The
input handler will then do ETH->DMARPDR=0, for either a rx packet or RBU
error. It doesn't help. It also doesn't seem to help if I do it all in
the ISR.
As a brute force measure, I added a call to ETH_DMARxDescChainInit() to
clear up all the rx descriptors (setting the "own" bit to the DMA). That
made things better and worse. Now, sometimes I get <1 ms ping response,
and sometimes I get no response. Obviously, I'm being pretty cavalier
over writing all of the descriptors while the DMA is running, but it
was shot in the dark to see if it made a difference. It seems like this
is the right thing to do, but in a way that is thread safe with lwIP.
Someone out there surely has done this in the right method...
thanks for any more hints,
Mark
On 9/12/2012 4:27 PM, Zachary Smith wrote:
I am using STM32F217 and I'm sure the Ethernet MAC is the same.
You are likely correct in thinking the problem is the RBUS interrupt
flag. When you hit the breakpoint the Ethernet DMA probably fills up
all the RX descriptor buffers and asserts that interrupt flag and then
is not able to receive anything else until you take care of the
interrupt and then resume reception.
You have to enable the RBU interrupt and clear it if it happens. Also,
if I remember correctly, if this interrupt happens it can happen that
you don't get a normal Receive interrupt like you normally would so
you are not triggered to read from the buffers.
enable the RBU interrupt:
ETH_DMAITConfig(ETH_DMA_IT_AIS | ETH_DMA_IT_RBU, ENABLE);
ISR: clear the flag:
if(ETH_GetDMAITStatus(ETH_DMA_IT_RBU) != RESET)
ETH_DMAClearITPendingBit(ETH_DMA_IT_RBU | ETH_DMA_IT_AIS);
Then reception will be in the suspended state until you resume
reception by writing to the DMARPDR (receive poll demand) register.
The manual says the DMA will start checking for available descriptors
again when you write to this register with any value:
ETH->DMARPDR = 0;
In my case, if the RBU interrupt happens I clear the flag and then
send a msg to my TCP task to do an Ethernet input. My Ethernet driver
always does the resume reception command after reading from a receive
descriptor. That way the rx descriptors are read and then reception
resumed.
Hope that helps.
On 9/12/2012 4:35 PM, Mark Lakata wrote:
I've got my STM32F407 port for FreeRTOS 7.2 and lwIP1.40 running now,
with ping and HTTP working well (I started with the ST's demo which
was based on FreeRTOS6.1.0 and lwIP1.3.2, and merged it into the
latest code).
However, if I stop the program momentarily with the debugger, or hit
a breakpoint, the lwIP stack slows down a lot. The ping time goes
from <1ms to 300-500 ms typically, sometimes > 2000 ms. It is easy to
reproduce, including the original ST demo code:
1. run demo code
2. count to 5
3. do a ping from another computer
4. hit 'break' in the debugger from IAR EWARM
5. hit 'run' right away
6. do another ping
I think it is related to this problem, discusses in an earlier
thread:
http://lists.nongnu.org/archive/html/lwip-users/2012-05/msg00111.html
It seems that once you stop the CPU, the DMA engine gets tied up in
knots and doesn't recover, until a reset. It is related to the RBUS
interrupt flag (Receive Buffer unavailable) in the ETH_DMASR status
register. I see this bit go high forever once the problem occurs. It
does not self clear with the existing code.
I'm sure this can be fixed with a software workaround, but I haven't
found it or figured it out. I'm just starting out on lwIP and the
STM32F4x7 (first week).
Any ideas?
thanks,
Mark Lakata
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
