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
breakp
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 receiv
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.
Title: 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 e
n der Kraan
On 13-9-2012 4:40, jblackarty wrote:
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 in
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
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 tha
great, glad you got it working.
On 9/13/2012 11:50 AM, Mark Lakata wrote:
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 dem
Title: Re: [lwip-users] STM32 RBUS (Receive Buffer Unavailable) bit set after debugger break
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. I'll share it later. But I see
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 s
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-bre
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.
__
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
ok. will look forward to it
kerem
On Friday, May 31, 2013, Noam weissman [via lwIP] <
ml-node+s100n21496...@n7.nabble.com> wrote:
> 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
14 matches
Mail list logo
