[lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit set after debugger break

[Mark Lakata]

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

[Zachary Smith]

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.

Post by Mark Lakata
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
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
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
https://lists.nongnu.org/mailman/listinfo/lwip-users

[Mark Lakata]

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

Post by Zachary Smith
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.
ETH_DMAITConfig(ETH_DMA_IT_AIS | ETH_DMA_IT_RBU, ENABLE);
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
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.

Post by Mark Lakata
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
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
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
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

[jblackarty]

<html><head><title>Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit set after debugger break</title>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
</head>
<body>
<span style=" font-family:'Courier New'; font-size: 9pt;">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.<br>
<br>
</span><table bgcolor="#ffffff">
<tr>
<td width=10 bgcolor= #0000ff><br>
</td>
<td width=880><span style=" font-family:'courier new'; font-size: 11pt;">Hi Zachary,<br>
&nbsp;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.<br>
<br>
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-&gt;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.<br>
<br>
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 &lt;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 &nbsp;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. &nbsp;Someone out there surely has done this in the right method...&nbsp;<br>
<br>
thanks for any more hints,<br>
Mark<br>
<br>
<br>
<span style=" font-size: 9pt;">On 9/12/2012 4:27 PM, Zachary Smith wrote:<br>
I am using STM32F217 and I'm sure the Ethernet MAC is the same.&nbsp;<br>
You are likely correct in thinking the problem is the RBUS interrupt flag. &nbsp;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.&nbsp;<br>
<br>
You have to enable the RBU interrupt and clear it if it happens. &nbsp;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.&nbsp;<br>
<br>
enable the RBU interrupt:&nbsp;<br>
ETH_DMAITConfig(ETH_DMA_IT_AIS | ETH_DMA_IT_RBU, ENABLE);&nbsp;<br>
<br>
ISR: clear the flag:&nbsp;<br>
if(ETH_GetDMAITStatus(ETH_DMA_IT_RBU) != RESET)&nbsp;<br>
&nbsp; &nbsp; ETH_DMAClearITPendingBit(ETH_DMA_IT_RBU | ETH_DMA_IT_AIS);&nbsp;<br>
<br>
Then reception will be in the suspended state until you resume reception by writing to the DMARPDR (receive poll demand) register. &nbsp;The manual says the DMA will start checking for available descriptors again when you write to this register with any value:&nbsp;<br>
ETH-&gt;DMARPDR = 0;&nbsp;<br>
<br>
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. &nbsp;My Ethernet driver always does the resume reception command after reading from a receive descriptor. &nbsp;That way the rx descriptors are read and then reception resumed.&nbsp;<br>
<br>
Hope that helps.&nbsp;<br>
<br>
<br>
<br>
On 9/12/2012 4:35 PM, Mark Lakata wrote:&nbsp;<br>
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).&nbsp;<br>
<br>
However, if I stop the program momentarily with the debugger, or hit a breakpoint, the lwIP stack slows down a lot. &nbsp;The ping time goes from &lt;1ms to 300-500 ms typically, sometimes &gt; 2000 ms. It is easy to reproduce, including the original ST demo code:&nbsp;<br>
&nbsp; 1. run demo code&nbsp;<br>
&nbsp; 2. count to 5&nbsp;<br>
&nbsp; 3. do a ping from another computer&nbsp;<br>
&nbsp; 4. hit 'break' in the debugger from IAR EWARM&nbsp;<br>
&nbsp; 5. hit 'run' right away&nbsp;<br>
&nbsp; 6. do another ping&nbsp;<br>
<br>
<br>
I think it is related to this problem, discusses in an earlier thread:&nbsp;<a href="http://lists.nongnu.org/archive/html/lwip-users/2012-05/msg00111.html">http://lists.nongnu.org/archive/html/lwip-users/2012-05/msg00111.html</a>&nbsp;<br>
<br>
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.&nbsp;<br>
<br>
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).&nbsp;<br>
<br>
Any ideas?&nbsp;<br>
<br>
thanks,&nbsp;<br>
Mark Lakata&nbsp;<br>
<br>
<br>
<br>
_______________________________________________&nbsp;<br>
lwip-users mailing list&nbsp;<br>
<a href="mailto:lwip-***@nongnu.org">lwip-***@nongnu.org</a>&nbsp;<br>
<a href="https://lists.nongnu.org/mailman/listinfo/lwip-users">https://lists.nongnu.org/mailman/listinfo/lwip-users</a>&nbsp;<br>
<br>
<br>
_______________________________________________&nbsp;<br>
lwip-users mailing list&nbsp;<br>
<a href="mailto:lwip-***@nongnu.org">lwip-***@nongnu.org</a>&nbsp;<br>
<a href="https://lists.nongnu.org/mailman/listinfo/lwip-users">https://lists.nongnu.org/mailman/listinfo/lwip-users</a>&nbsp;</td>
</tr>
</table>
</body>

[Ruben van der Kraan]

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

Post by jblackarty
Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit set after
debugger break 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
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.
ETH_DMAITConfig(ETH_DMA_IT_AIS | ETH_DMA_IT_RBU, ENABLE);
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
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.
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
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
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
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

[jblackarty]

<html><head><title>Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit set after debugger break</title>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
</head>
<body>
<span style=" font-family:'Courier New'; font-size: 9pt;">I'm using lwip 1.4.0. But my port is for GCC and I didn't even tried to make it easy modifiable to other compilers. Also it's not complete yet. &nbsp;I'll share it later. But I see you solved issue. My congratulations :)<br>
<br>
</span><table bgcolor="#ffffff">
<tr>
<td width=10 bgcolor= #0000ff><br>
</td>
<td width=567><span style=" font-family:'courier new'; font-size: 9pt;">Hello jblackarty<br>
<br>
I'am interested in your port of the stack on the STM32F207 i currently use 1.3.2.<br>
Did you port 1.4 to the STM32F207 ?&nbsp;<br>
If so can you share you port / project ?&nbsp;<br>
<br>
I am using IAR version 6.4.1 but soon going to update to the latest release.&nbsp;<br>
<br>
Thanks in advance,<br>
<br>
Ruben van der Kraan<br>
</td>
</tr>
</table>
<a style=" font-family:'courier new'; font-size: 9pt;" href="https://lists.nongnu.org/mailman/listinfo/lwip-users"><br></a></body>

[Zachary Smith]

Just to clarify...
You say the RBU flag is being cleared and then the DMARPDR register is
written to restart reception. When the RBU flag is asserted it means
all the DMA buffers have filled and are "owned" by the CPU. So you must
read from at least one of the descriptors and give it back to the DMA
(set own bit) before writing to the DMARPDR register to restart
reception. Are you doing that?
-Zach

Post by Mark Lakata
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

Post by Zachary Smith
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.
ETH_DMAITConfig(ETH_DMA_IT_AIS | ETH_DMA_IT_RBU, ENABLE);
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
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.

Post by Mark Lakata
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
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
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
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

[Mark Lakata]

Thank you Zach. That gave me the resolve to see if I needed to rewrite
the ST demo code, and sure enough, it looks like their code is crap. It
shouldn't surprise me, this is not the first time I've encountered bad
ST demo code. They assumed that one interrupt equals exactly one
packet, but that is not the way it works. The interrupt just means at
least one packet is available. I kept the ISR the same (with a counting
semaphore), but I drain out all available rx packets in the receiving
input task, and cleaned up the error handling in low_level_input. This
works great now with debugger breaks. In fact, it works even better than
before for transferring larger amounts of data (ie their demo webpage
images load faster now too).

-Mark


These 3 functions go in ethernetif.c

// from the sample code for the STM32F4x7 ethernet FreeRTOS/lwIP demo.

/**
* Should allocate a pbuf and transfer the bytes of the incoming
* packet from the interface into the pbuf.
*
* @param netif the lwip network interface structure for this ethernetif
* @return a pbuf filled with the received packet (including MAC header)
* NULL on memory error
*/
static struct pbuf * low_level_input(struct netif *netif)
{
struct pbuf *p, *q;
u16_t len;
uint32_t l=0,i =0;
FrameTypeDef frame;
u8 *buffer;
__IO ETH_DMADESCTypeDef *DMARxNextDesc;

p = NULL;

/* Get received frame */
frame = ETH_Get_Received_Frame_interrupt();

if (frame.descriptor && frame.buffer) {
/* check that frame has no error */
if ((frame.descriptor->Status & ETH_DMARxDesc_ES) == (uint32_t)RESET)
{

/* Obtain the size of the packet and put it into the "len"
variable. */
len = frame.length;
buffer = (u8 *)frame.buffer;

/* We allocate a pbuf chain of pbufs from the pool. */
p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);

/* Copy received frame from ethernet driver buffer to stack
buffer */
if (p != NULL)
{
for (q = p; q != NULL; q = q->next)
{
memcpy((u8_t*)q->payload, (u8_t*)&buffer[l], q->len);
l = l + q->len;
}
}
}

/* Release descriptors to DMA */
/* Check if received frame with multiple DMA buffer segments */
if (DMA_RX_FRAME_infos->Seg_Count > 1)
{
DMARxNextDesc = DMA_RX_FRAME_infos->FS_Rx_Desc;
}
else
{
DMARxNextDesc = frame.descriptor;
}

/* Set Own bit in Rx descriptors: gives the buffers back to DMA */
for (i=0; i<DMA_RX_FRAME_infos->Seg_Count; i++)
{
DMARxNextDesc->Status = ETH_DMARxDesc_OWN;
DMARxNextDesc = (ETH_DMADESCTypeDef
*)(DMARxNextDesc->Buffer2NextDescAddr);
}

/* Clear Segment_Count */
DMA_RX_FRAME_infos->Seg_Count =0;
}
return p;
}

static void ethernet_watchdog(void) {
/* When Rx Buffer unavailable flag is set: clear it and resume
reception */
if ((ETH->DMASR & ETH_DMASR_RBUS) != (u32)RESET)
{
/* Clear RBUS ETHERNET DMA flag */
ETH->DMASR = ETH_DMASR_RBUS;

/* Resume DMA reception. The register doesn't care what you
write to it. */
ETH->DMARPDR = 0;
}
}

void ethernetif_input( void * pvParameters )
{
struct pbuf *p;

for( ;; )
{
if (xSemaphoreTake( s_xSemaphore,
emacBLOCK_TIME_WAITING_FOR_INPUT)==pdTRUE)
{
while ((p = low_level_input( s_pxNetIf )) != 0) {
if (p != 0) {
if (ERR_OK != s_pxNetIf->input( p, s_pxNetIf))
{
pbuf_free(p);
p=NULL;
}
}
}
}
ethernet_watchdog();
}
}

Post by Zachary Smith
Just to clarify...
You say the RBU flag is being cleared and then the DMARPDR register is
written to restart reception. When the RBU flag is asserted it means
all the DMA buffers have filled and are "owned" by the CPU. So you
must read from at least one of the descriptors and give it back to the
DMA (set own bit) before writing to the DMARPDR register to restart
reception. Are you doing that?
-Zach

Post by Mark Lakata
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_DMsARxDescChainInit()
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

Post by Zachary Smith
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.
ETH_DMAITConfig(ETH_DMA_IT_AIS | ETH_DMA_IT_RBU, ENABLE);
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
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.

Post by Mark Lakata
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
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
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
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

[Zachary Smith]

great, glad you got it working.

Post by Mark Lakata
Thank you Zach. That gave me the resolve to see if I needed to rewrite
the ST demo code, and sure enough, it looks like their code is crap.
It shouldn't surprise me, this is not the first time I've encountered
bad ST demo code. They assumed that one interrupt equals exactly one
packet, but that is not the way it works. The interrupt just means at
least one packet is available. I kept the ISR the same (with a
counting semaphore), but I drain out all available rx packets in the
receiving input task, and cleaned up the error handling in
low_level_input. This works great now with debugger breaks. In fact,
it works even better than before for transferring larger amounts of
data (ie their demo webpage images load faster now too).
-Mark
These 3 functions go in ethernetif.c
// from the sample code for the STM32F4x7 ethernet FreeRTOS/lwIP demo.
/**
* Should allocate a pbuf and transfer the bytes of the incoming
* packet from the interface into the pbuf.
*
* NULL on memory error
*/
static struct pbuf * low_level_input(struct netif *netif)
{
struct pbuf *p, *q;
u16_t len;
uint32_t l=0,i =0;
FrameTypeDef frame;
u8 *buffer;
__IO ETH_DMADESCTypeDef *DMARxNextDesc;
p = NULL;
/* Get received frame */
frame = ETH_Get_Received_Frame_interrupt();
if (frame.descriptor && frame.buffer) {
/* check that frame has no error */
if ((frame.descriptor->Status & ETH_DMARxDesc_ES) ==
(uint32_t)RESET)
{
/* Obtain the size of the packet and put it into the "len"
variable. */
len = frame.length;
buffer = (u8 *)frame.buffer;
/* We allocate a pbuf chain of pbufs from the pool. */
p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);
/* Copy received frame from ethernet driver buffer to stack
buffer */
if (p != NULL)
{
for (q = p; q != NULL; q = q->next)
{
memcpy((u8_t*)q->payload, (u8_t*)&buffer[l], q->len);
l = l + q->len;
}
}
}
/* Release descriptors to DMA */
/* Check if received frame with multiple DMA buffer segments */
if (DMA_RX_FRAME_infos->Seg_Count > 1)
{
DMARxNextDesc = DMA_RX_FRAME_infos->FS_Rx_Desc;
}
else
{
DMARxNextDesc = frame.descriptor;
}
/* Set Own bit in Rx descriptors: gives the buffers back to DMA */
for (i=0; i<DMA_RX_FRAME_infos->Seg_Count; i++)
{
DMARxNextDesc->Status = ETH_DMARxDesc_OWN;
DMARxNextDesc = (ETH_DMADESCTypeDef
*)(DMARxNextDesc->Buffer2NextDescAddr);
}
/* Clear Segment_Count */
DMA_RX_FRAME_infos->Seg_Count =0;
}
return p;
}
static void ethernet_watchdog(void) {
/* When Rx Buffer unavailable flag is set: clear it and resume
reception */
if ((ETH->DMASR & ETH_DMASR_RBUS) != (u32)RESET)
{
/* Clear RBUS ETHERNET DMA flag */
ETH->DMASR = ETH_DMASR_RBUS;
/* Resume DMA reception. The register doesn't care what you
write to it. */
ETH->DMARPDR = 0;
}
}
void ethernetif_input( void * pvParameters )
{
struct pbuf *p;
for( ;; )
{
if (xSemaphoreTake( s_xSemaphore,
emacBLOCK_TIME_WAITING_FOR_INPUT)==pdTRUE)
{
while ((p = low_level_input( s_pxNetIf )) != 0) {
if (p != 0) {
if (ERR_OK != s_pxNetIf->input( p, s_pxNetIf))
{
pbuf_free(p);
p=NULL;
}
}
}
}
ethernet_watchdog();
}
}

Post by Zachary Smith
Just to clarify...
You say the RBU flag is being cleared and then the DMARPDR register
is written to restart reception. When the RBU flag is asserted it
means all the DMA buffers have filled and are "owned" by the CPU. So
you must read from at least one of the descriptors and give it back
to the DMA (set own bit) before writing to the DMARPDR register to
restart reception. Are you doing that?
-Zach

Post by Mark Lakata
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_DMsARxDescChainInit() 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

Post by Zachary Smith
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.
ETH_DMAITConfig(ETH_DMA_IT_AIS | ETH_DMA_IT_RBU, ENABLE);
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
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.

Post by Mark Lakata
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
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
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
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

[mocambo]

Hi,
I need some time to understand this code, but works great!
It solve also the problem I found when ping continuosly the device: after
some hours lwip stop works.
I think this problem happen also when you try to connect the browser to the
device and use the default page that reload itself every second: after some
hours lwip stop works, but by now I tested only the ping.
Best Regards,
mocambo



--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p20550.html
Sent from the lwip-users mailing list archive at Nabble.com.

[kerem]

Hello Mark,

I am in process of developing STMF407 for FreeRTOS 7.4 and lwIP 1.4.0. Do
you mind sharing your port which would save me a lot of time.

Thanks,

Kerem Or



--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21483.html
Sent from the lwip-users mailing list archive at Nabble.com.

[Noam weissman]

Hi,

I have basic projects for IAR and Keil for the STM32F4x7 running on the STM3240G-EVAL

The code uses static IP, one UART ... The code uses LwIP 1.41 and FreeRTOS 7.4

The code includes a few company modules that I cannot share.

Let me know what you need and I'll try and see what I can send you

BR,
Noam.



-----Original Message-----
From: lwip-users-bounces+noam=***@nongnu.org [mailto:lwip-users-bounces+noam=***@nongnu.org] On Behalf Of kerem
Sent: ה 30 מאי 2013 15:13
To: lwip-***@nongnu.org
Subject: Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit setafter debugger break

Hello Mark,

I am in process of developing STMF407 for FreeRTOS 7.4 and lwIP 1.4.0. Do you mind sharing your port which would save me a lot of time.

Thanks,

Kerem Or



--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21483.html
Sent from the lwip-users mailing list archive at Nabble.com.

_______________________________________________
lwip-users mailing list
lwip-***@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users



************************************************************************************
This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************






************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************

[kerem]

Hello,

Thank you for your very quick response. I am using IAR 6.5.6. So any IAR
version would help better. STM3240G-EVAL is fine.

Appreciate your help


Kerem





--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21487.html
Sent from the lwip-users mailing list archive at Nabble.com.

[Noam weissman]

Hi,

I sent you directly two RAR files. I was not sure I can send 2M attachment here.

Let me know if you got it.

Noam.

-----Original Message-----
From: lwip-users-bounces+noam=***@nongnu.org [mailto:lwip-users-bounces+noam=***@nongnu.org] On Behalf Of kerem
Sent: ה 30 מאי 2013 17:10
To: lwip-***@nongnu.org
Subject: Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bitsetafter debugger break

Hello,

Thank you for your very quick response. I am using IAR 6.5.6. So any IAR version would help better. STM3240G-EVAL is fine.

Appreciate your help


Kerem





--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21487.html
Sent from the lwip-users mailing list archive at Nabble.com.

_______________________________________________
lwip-users mailing list
lwip-***@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users



************************************************************************************
This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************






************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************

[Andrew Austin]

We are using FreeRTOS 7.3 and lwip 1.4.1 and are experiencing similar
problems. The code works well for a while until the system is loaded and
then the communications slows down. Thank you for your post and we will test
your fix.



--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21575.html
Sent from the lwip-users mailing list archive at Nabble.com.

[Mark Lakata]

Here you go. Sorry, I can't help with the files, use at your own risk.
I did not write this from scratch, they evolved from pieces I found.

This was based on FreeRTOS 7.2 and lwIP ppp-new (which is basically
1.4.x) There are still some proprietary header files missing. You'll
have to clean that up.

-Mark

Post by kerem
Hello Mark,
I am in process of developing STMF407 for FreeRTOS 7.4 and lwIP 1.4.0. Do
you mind sharing your port which would save me a lot of time.
Thanks,
Kerem Or
--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21483.html
Sent from the lwip-users mailing list archive at Nabble.com.
_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

[kerem]

Files received. Thanks. I will be looking into it.

Kerem



--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21493.html
Sent from the lwip-users mailing list archive at Nabble.com.

[kerem]

Hello Mark,

Do you mind sharing lwipopts.h, freertosconfig.h files so settings would be
consistent with the rest

Kerem



--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21495.html
Sent from the lwip-users mailing list archive at Nabble.com.

[Noam weissman]

Hi Kerem,

I think I sent you the lwipopts.h as well ... no ?

I will send you the files next week. I have made small changes
to use ARP and DNS...


Have a nice weekend,
Noam.

-----Original Message-----
From: lwip-users-bounces+noam=***@nongnu.org on behalf of kerem
Sent: Fri 5/31/2013 12:25 PM
To: lwip-***@nongnu.org
Subject: Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit setafter debugger break

Hello Mark,

Do you mind sharing lwipopts.h, freertosconfig.h files so settings would be
consistent with the rest

Kerem



--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21495.html
Sent from the lwip-users mailing list archive at Nabble.com.

_______________________________________________
lwip-users mailing list
lwip-***@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users



************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************







************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************

[Mark Lakata]

Here you go. These files correspond to the ports.zip file I sent yesterday.
-Mark

Post by Noam weissman
Hi Kerem,
I think I sent you the lwipopts.h as well ... no ?
I will send you the files next week. I have made small changes
to use ARP and DNS...
Have a nice weekend,
Noam.
-----Original Message-----
Sent: Fri 5/31/2013 12:25 PM
Subject: Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit
setafter debugger break
Hello Mark,
Do you mind sharing lwipopts.h, freertosconfig.h files so settings would be
consistent with the rest
Kerem
--
http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21495.html
Sent from the lwip-users mailing list archive at Nabble.com.
_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
_______________________________________________
lwip-users mailing list
https://lists.nongnu.org/mailman/listinfo/lwip-users

[kerem]

Hello Mark,

I just noticed your have sent the files. Thanks

Kerem

Kerem Or

SYS A.Ş.
Cyberpark Cyberplaza B Blok No B701, 06800
Bilkent-Ankara
Tel: [phone]
Fax: [phone]
www.esys.com.tr
www.rflo.com.tr



On Fri, May 31, 2013 at 9:45 PM, Mark Lakata [via lwIP] <

Post by Mark Lakata
Here you go. These files correspond to the ports.zip file I sent yesterday.
-Mark
On Fri, May 31, 2013 at 11:15 AM, Noam weissman <[hidden email]<http://user/SendEmail.jtp?type=node&node=21497&i=0>

Post by Noam weissman
Hi Kerem,
I think I sent you the lwipopts.h as well ... no ?
I will send you the files next week. I have made small changes
to use ARP and DNS...
Have a nice weekend,
Noam.
-----Original Message-----
From: lwip-users-bounces+noam=[hidden email]<http://user/SendEmail.jtp?type=node&node=21497&i=1>on behalf of kerem
Sent: Fri 5/31/2013 12:25 PM
To: [hidden email] <http://user/SendEmail.jtp?type=node&node=21497&i=2>
Subject: Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit
setafter debugger break
Hello Mark,
Do you mind sharing lwipopts.h, freertosconfig.h files so settings would be
consistent with the rest
Kerem
--
http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21495.html
Sent from the lwip-users mailing list archive at Nabble.com.
_______________________________________________
lwip-users mailing list
[hidden email] <http://user/SendEmail.jtp?type=node&node=21497&i=3>
https://lists.nongnu.org/mailman/listinfo/lwip-users
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
_______________________________________________
lwip-users mailing list
[hidden email] <http://user/SendEmail.jtp?type=node&node=21497&i=4>
https://lists.nongnu.org/mailman/listinfo/lwip-users

--
Mark Lakata
Senior Firmware and Software Architect
Gener8, Inc.
[hidden email] <http://user/SendEmail.jtp?type=node&node=21497&i=5>
_______________________________________________
lwip-users mailing list
[hidden email] <http://user/SendEmail.jtp?type=node&node=21497&i=6>
https://lists.nongnu.org/mailman/listinfo/lwip-users
*lwipopts.h* (18K) Download Attachment<http://lwip.100.n7.nabble.com/attachment/21497/0/lwipopts.h>
*FreeRTOSConfig.h* (11K) Download Attachment<http://lwip.100.n7.nabble.com/attachment/21497/1/FreeRTOSConfig.h>
------------------------------
If you reply to this email, your message will be added to the discussion
http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21497.html
To unsubscribe from STM32 RBUS (Receive Buffer Unavailable) bit set after
debugger break, click here<http://lwip.100.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=11154&code=ay5vckBzeXMtaW5jLmNvbXwxMTE1NHwyNjQ5OTg2OTM=>
.
NAML<http://lwip.100.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

--
View this message in context: http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21530.html
Sent from the lwip-users mailing list archive at Nabble.com.

[kerem]

ok. will look forward to it
kerem

On Friday, May 31, 2013, Noam weissman [via lwIP] <

Post by Noam weissman
Hi Kerem,
I think I sent you the lwipopts.h as well ... no ?
I will send you the files next week. I have made small changes
to use ARP and DNS...
Have a nice weekend,
Noam.
-----Original Message-----
From: lwip-users-bounces+noam=[hidden email] on behalf of kerem
Sent: Fri 5/31/2013 12:25 PM
To: [hidden email]
Subject: Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit

setafter debugger break

Post by Noam weissman
Hello Mark,
Do you mind sharing lwipopts.h, freertosconfig.h files so settings would

be

Post by Noam weissman
consistent with the rest
Kerem
--

http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21495.html

Post by Noam weissman
Sent from the lwip-users mailing list archive at Nabble.com.
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

************************************************************************************

Post by Noam weissman
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &

computer viruses.
************************************************************************************
************************************************************************************

Post by Noam weissman
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &

computer viruses.
************************************************************************************

Post by Noam weissman
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
winmail.dat (4K) Download Attachment
________________________________
If you reply to this email, your message will be added to the discussion

below:
http://lwip.100.n7.nabble.com/STM32-RBUS-Receive-Buffer-Unavailable-bit-set-after-debugger-break-tp11154p21496.html

Post by Noam weissman
To unsubscribe from STM32 RBUS (Receive Buffer Unavailable) bit set after

debugger break, click here.

Post by Noam weissman
NAML