ping issue when lwip ported on stm32f765z
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-28 12:10 AM
hello,
i have ported lwip stack on out custom board build around stm32f765z controller. After porting board is able to get dynamic ip assigned by dhcp server. to check the connectivity i pinging the board from a windows pc which is also in the same network. i am always getting random ping responses sometimes a response is available sometimes time out. i am not getting ping response consistently. can somebody plz elaborate where could be the issue as checked low_level_input() function and its able to copy the data from eth buff to dma.
- Labels:
-
Ethernet
-
STM32F7 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-28 12:53 AM
Use wireshark to monitor the network traffic.
I suspect your board is overrun by irrelevant traffic on the network.
I tend to use Cortex A systems for network-related applications.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-28 12:57 AM
hi
thanks for ur ans. i can see the network traffic other than the arp activity for the board. the same example works fine in evaluation board in the same network so how the network traffic is affecting my board while the evaluation board works fine. can u plz shed some light how to debug whether its a stack issue or some other.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-28 2:08 AM
> i am always getting random ping responses sometimes a response is available sometimes time out. i am not getting ping response consistently.
This is not a very exact description of the problem.
Admittedly, the problem is a bit complex, but I see no way around analyzing and debugging / instrumenting your application.
> .. whether its a stack issue or some other.
Stack issues (overflows) tend to crash your application, ending in the hardfault handler.
Not sure what your application is based on. Cube is notorious for using busy-waits and a rigid framework.
I suggest you instrument your application, and check where the runtime is lost in cases without answer or delayed answer.
Either use a profiling tool of your toolchain, or with toggling GPIOs at function entry/exit and measure with a cope or logic analyzer.
Inter-relate this with the wireshark traces.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-02-28 2:13 AM
thanks i l try as per your suggestion and let u know
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2019-07-20 2:32 PM
> I suspect your board is overrun by irrelevant traffic on the network.
One more misconception of Ethernet related principles. That was true in old times with network hubs. Nowadays with network switches there are no truly irrelevant (unicast to other devices) frames and very little "irrelevant" (broadcast) traffic on a typical network. It ranges from a few frames per minute on a home network to few tens of frames per minute on an office network.
