Quantcast
Channel: Forums - Recent Threads
Viewing all articles
Browse latest Browse all 262198

NDK stops working in case of a big bidirectional traffic.

$
0
0

Hi All!

This thread was created as a replacement of     http://e2e.ti.com/support/embedded/bios/f/355/t/223029.aspx?pi239031349=4.    I was told by our local TI distributor that due to the fact that the previous thread was marked as answered it doesn't get enough attention.

Brief description of the problem:
Network Development Kit (NDK) working on DM648 stops receiving packets in case of significant bidirectional traffic and does not recovers until restart.

In our project, we digitize analog signal and send it to a PC via Ethernet. The traffic is about 150 Mb/s - 200 Mb/s. Also, the board and the PC exchange commands and status messages. While testing the system we noticed that it stops communicating in a few hours. Later we reproduced the problem on TMS320DM648DVDP bought from TI company using slightly modified example project provided by TI (helloWorld).  With help of hping tool we were able to reproduce the problem faster, without waiting for a few hours.

Configuration:

CCS 5.1.1.00031

bios_5_42_00_07

ndk_2_20_06_35

ethss_dm648 from ndk_2_0_0. According to TI's advice all "printf" were removed

The project was taken from

ndk_2_0_0\packages\ti\ndk\example\network\helloWorld

This project originally was for CCS 3.3 so I had to convert it to use with CCS 5.1.

I did the following changes in the pfoject:

- an IP address is set statically

- dtask_udp_hello demon and its creation were commented out

- A MainTask thread was created

MainTask sends UDP packets (1000 bytes). The stream is about 150 Mb/s. We also reproduced the problem with 80 Mb/s. 

The evaluation module DM648 DVDP is directly connected to a PC. To have more control on the PC we use Free BSD UNIX now. On the PC's side we use hping in flood mode to send packets to the board, netstat to see what is going on on the net and normal ping to test if the board responds (when hping works in flood mode it reports nothing). hping can provide a very big amount of packets and it makes the problem appears faster. Usually we start hping in two threads to use both CPUs of the PC and create maximum traffic. In this case the problem appears within minutes.

There is no application on the PC which would receive data from DM648.  

As we understand the situation now, it is necessary that packets were sent in both ways from DM648 and to DM648. The problem happens with both 100 Mb and 1Gb connections.

How to reproduce the problem:

1. Connect the board and the PC directly with a cable. All modern cards don't require cross cable anymore.

2. Set desired IP addressed on the board and PC.

3. Run the project as it is on the board.

4. Run ping on the PC to watch the state of the board.

5. Start two terminals on the PC and in each run hping –flood –udp 192.168.1.100   (where 192.168.1.100 is the board's IP address)

The board will stop responding to the ping within a few minutes. After another few minutes, when the timeout expires in the route table on the board, the application will not be able to send data and sendto function will return 64.


Investigation:
Investigating this problem we found out that there is no Rx interrupts and emacDequeueRx function is not called.

Previous communication with TI:
I have placed the information about this problem on TI's e2e forum: http://e2e.ti.com/support/embedded/bios/f/355/t/223029.aspx?pi239031349=2   in 24th of November. This thread was created by another engineer who has a similar problem but on the other processor.

Then there was a short discussion with Steven Connell from TI and a pause till 23rd of January.

In 23rd of January Steven told me that he was ready to try to reproduce the issue and asked about the details. 

In 7th of February Steven wrote the following:

Hi Victor,

I just wanted to update you.  We are able to reproduce this issue and are seeing it on different hardware platforms.  We are currently debugging the issue and will let you know as soon as we have something ... thanks again for your patience.

Steve

Since that moment we haven't received any updates about the status of the issue.

Also I tried to communicate with TI's support  [Service Request# 1-926930884] but they advised me to continue to use e2e.

We are running out of time, our project is behind of the scheduler and we need at list to know what to expect:
1. Is TI working on it?
2. Is it software or hardware problem?
3. Is it going to be fixed and when?

Best Regards
Victor Ivanov


Viewing all articles
Browse latest Browse all 262198

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>