Re: [lwip-users] Recv UDP Problem

Listed in the errata dated October 2016 for F76x. TCP seems to be working reliably on the 746. I'm just using the driver from Cube on a Nucleo board. I need to review the cache configuration. On Sat, Nov 26, 2016 at 10:42 AM Michael Steinberg wrote: > Hey, > > the problem

Re: [lwip-users] Recv UDP Problem

Hey, the problem being discussed here is happening on an Atmel device (ATSAME70). Is the bug on the STM32F767 device already in the errata sheet? I'm currently using a 745 device, so I'm hopefully good. Apart from the cache issues I ran into nothing special. I had a look at the sheet don't

Re: [lwip-users] Recv UDP Problem

Which part? The cache theory seems a good bet but the STM32F767 was recently found to have a bug in the EMAC. We switched to an F746. On Fri, Nov 25, 2016 at 2:35 PM Robin Iddon wrote: > See page 9 > > >

Re: [lwip-users] Recv UDP Problem

See page 9 http://www.st.com/content/ccc/resource/technical/document/application_note/group0/08/dd/25/9c/4d/83/43/12/DM00272913/files/DM00272913.pdf/jcr:content/translations/en.DM00272913.pdf

Re: [lwip-users] Recv UDP Problem

> Surely the cache memory gets invalidated automatically regardless of the > source of writing to it? No, often that is not the case; if the CPU(s) write to the memory (through the cache) then the cache is valid when another thread or whatever reads back from it; if a DMA peripheral (pretty

Re: [lwip-users] Recv UDP Problem

What do you mean by cache memory? The point of DMA transfers is bypassing the cpu altogether, and since the i caches are part of the cpu, they don't witness any memory reads the DMA transfers initiate. One could potentially transfer that information to the caches from the memory bus matrix

Re: [lwip-users] Recv UDP Problem

Hi, I'm just starting the same process - migrating from m4 to m7 (eventually h7). Surely the cache memory gets invalidated automatically regardless of the source of writing to it? Many thanks, Mike (a different one!). On 25/11/2016 16:35, Michael Steinberg wrote: Hi, You were

Re: [lwip-users] Recv UDP Problem

Hi, You were reporting the same software works on m4 but fails to work reliably on m7. The most prominent difference that can cause issues between m4 and m7 is that the latter has data caches, where the former has none. Possible situation: The dma writes a frame to cached memory, the mcu

Re: [lwip-users] Recv UDP Problem

@Michael: What exactly do you mean? no so far I am using two netconns, one for each task. but good to know 2.0.0. offers that. thanks! -- View this message in context: http://lwip.100.n7.nabble.com/Recv-UDP-Problem-tp27826p27900.html Sent from the lwip-users mailing list archive at

Re: [lwip-users] Recv UDP Problem

mgirke wrote: I am having a NETCONN API, no RAW. One task for sending and one for receiving. Does that mean you are using the same netconn from two different threads? For that to work, you need 2.0.0 and enable LWIP_NETCONN_FULLDUPLEX code. Simon

Re: [lwip-users] Recv UDP Problem

, driver, Porting etc... -Original Message- From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On Behalf Of mgirke Sent: Thursday, November 24, 2016 11:32 AM To: lwip-users@nongnu.org Subject: Re: [lwip-users] Recv UDP Problem Hi, I am having a NETCONN API, no RAW. One task

Re: [lwip-users] Recv UDP Problem

So it’s a low level issue, driver, Porting etc... -Original Message- From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On Behalf Of mgirke Sent: Thursday, November 24, 2016 11:32 AM To: lwip-users@nongnu.org Subject: Re: [lwip-users] Recv UDP Problem Hi, I am

Re: [lwip-users] Recv UDP Problem

Hi, I am having a NETCONN API, no RAW. One task for sending and one for receiving. I added the taskDelay but doesn´t help. Mem and pbuf should be fine. The packages definitely go in the wire. Sending data every 20ms works fine. Receiving messages come around every second. Only appr. every 10

Re: [lwip-users] Recv UDP Problem

: Monday, November 21, 2016 3:48 PM To: lwip-users@nongnu.org Subject: Re: [lwip-users] Recv UDP Problem I don´t now what running apps you mean which are close to that problem. When I use the socket api everything works, so can it be a driver or port problem? -- View this message in context: http

Re: [lwip-users] Recv UDP Problem

It depends on what you actually do when you "use" the sockets. If you trust your port and driver, then debug your app and do a traffic capture. Is it possible your app is starving the lwIP task as Noam suggests ? Where do your messages get lost ? Are they in the wire ? Do they enter the lwIP

Re: [lwip-users] Recv UDP Problem

but adding it, is Important. BR, Noam. -Original Message- From: lwip-users [mailto:lwip-users-bounces+noam=silrd@nongnu.org] On Behalf Of mgirke Sent: Monday, November 21, 2016 2:08 PM To: lwip-users@nongnu.org Subject: [lwip-users] Recv UDP Problem Hi, I am able to receive UDP

Re: [lwip-users] Recv UDP Problem

I don´t now what running apps you mean which are close to that problem. When I use the socket api everything works, so can it be a driver or port problem? -- View this message in context: http://lwip.100.n7.nabble.com/Recv-UDP-Problem-tp27826p27828.html Sent from the lwip-users mailing list

Re: [lwip-users] Recv UDP Problem

You should probably get some ideas if you run a sniffer, as I would probably too if I see your capture file. As a first guess, I bet you are losing frames in your driver. You should first run an application you know it works (like the ones in "apps" or in the "contrib" tree) before diving into

[lwip-users] Recv UDP Problem

Hi, I am able to receive UDP messages but it only works sometimes. In my example I sent a UDP message and I get an automatic reply. But this only works every 3-6 messages. What can be the problem. I am working on a Atsame70 with RTOS and Lwip 1.4 do { if (ERR_OK ==