Hello jblackarty
I'am interested in your port of the stack on the STM32F207 i
currently use 1.3.2.
Did you port 1.4 to the STM32F207 ?
If so can you share you port / project ?
I am using IAR version 6.4.1 but soon going to update to the latest
release.
Thanks in advance,
Ruben van der Kraan
On 13-9-2012 4:40, jblackarty wrote:
I have
to say that ST's demo example works bad. I don't know what
exactly they did wrong (incorrect lwip configuration, driver,
peripherials/clocks initialization or something else), but I
experienced problems with ping regardless of debugging. With my
own port it works ok now. Even after processor continue run
after breakpoint hit. Because my driver handles buffers overflow
(RBU). My device is STM32F207.
|
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
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users |
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
|