TI E2E Community
64 byte packets Flooding and Burst causing NDK Halting
I am using EVM DM648 with NDK2.0. I am using the helloworld application which comes with the board. The application is configured in the ALEBYPASS/PROMISCUOUS MODE. The throughput of the application is very much close to the benchmarks supplied with the boards documentations. The problems is that when i send a burst of 64byte packets the board starts dropping packets abruptly. This is natural and no problem with me. But after sometime when i increase the no. of packets in the burst the board halts and i have to restart the board to make it continue transmitting/receiving the packets. I can live with the dropping of packets but cannot with the halting and restarting of the board by re-powering it. This behaviour is also sometimes experienced with 128byte packets. The board works fine with the packet sizes above 128 bytes. Can you please help me?
Mark Deppwhen i increase the no. of packets in the burst the board halts
Where is the PC when this happens? Are you in the UTL_halt function?
If so, let's try to back trace. Can you put a break point into the UTL_halt function? Does the break point hit that function when this problem occurs?
If so, once the break point is reached, try to find where UTL_halt was called from. You can see this by going to the address contained in the register "B3". If you put the value stored in B3 into the dis/assembly window, you should see where halt was called from.
It may be another abort function. If so, you will need to put a break point there, in addition to the UTL_halt one, and then try to reproduce the problem again.
At this point, once the break point is hit, using the same method to back trace via the contents of B3, you would hopefully see the actual line of code that the abort is happening from.
Once that is known, it should give some more insight into the cause of the problem.
I have uploaded two snapshots in the previous post.
I did as you said by re-generating the problem several time then checking the B3 value to get where the PC is.
In 99% of the cases it was in the C$L1: Function but once it was in the NIMUPacketServiceCheck: Function.
The value of B3 was E00C55E8 all the time except it was E007DF0A when it pointed to NIMUPacketServiceCheck:
Can you reach to any conclusion?
You help is very much appreciated.
Mark DeppIn 99% of the cases it was in the C$L1: Function
The "C$L1" is not a function but a label. If the B3 register is taking you back to C$L1, can you scroll up in the dis/assembly window until you see an actual function name?
Once we know for sure where you are at in the 99% case, then we can try to pinpoint the place where it's failing and the cause.
I REGENERATED THE PROBLEM AND YES YOU WERE RIGHT IT WAS IN "UTL_HALT". HOWEVER I TRIED MANY TIMES TO CHECK THE REGISTER B3 VALUE FOR PC VALUE. THE FUNCTIONS LEADING TO UTL_HALT HOWEVER WERE SYS_ABORT, C$RL0, C$RL1 AND LOCK. I CANNOT GET ANY FUNCTION CAUSING THE PROBLEM BECAUSE IT LEADS TO UTL_HALT FROM C$RL0: BUT DOESN'T STOPS AT BREAKPOINT AT C$RL0:
Please Tell What is wrong.
You are using the standard OMAPL138 board? (i.e. not custom hardware?)
If so, would it be possible for me to try to reproduce this on my end? I have an OMAPL138 board at my desk and I think at this point will be easier for me to take over the debug.
I'm not sure if you have proprietary code in your application or not, if so then you should not post that here as these are public forums. If you do not want to post your project on the forum then we can share it by becoming "friends" on the forum. Once we are friends, you can attached files for me to see.
However, if you are using custom hardware, I won't be able to debug this ...
P.S. I'll send you a friend request now ...
Thank you so much for your reply. I have accepted your friend request, and would really like to further strengthen our co-operation in understanding and solving problem such as one i m already stuck in.
I told you in my 1st post on this thread that I have EVMDM648 Lyrtech board also that i m using standard NDK2.0 HelloWorld code. With Board working in switch mode.
You can download the source code from TI Download Site. Link is http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/index.html
This is good news. I just wanted to make sure that the hardware, etc was exactly the same. This will make it easier for me to reproduce the problem you are seeing.
In one of your previous posts you said:
Mark DeppThe application is configured in the ALEBYPASS/PROMISCUOUS MODE.
So, I think you have modified the helloWorld application? Is that true?
If you have modified it, then I will need to know the exact modifications in order to reproduce the issue. The easiest way to communicate the changes to me would be for you to simply zip up and attach your version of the helloworld example to this post.
Also, I would need to know how you are sending the 64 byte packet bursts to the DSP? Is there a Windows or Linux app that you are running to do this?
Lastly, please let me know how your board is connected (with respect to the network). Are you plugged into a router? A switch?
I connect the board to a hardware device IXIA IxLoad ( http://www.ixiacom.com/products/ixload/index.php ) on a Gigabit Link, there is no switch or router involved in it. Then the hardware device IXIA Ixload send the 64 byte packet burst to the DSP at full throughput. There is no Windows/Linux app or software involved. This is the standard HelloWorld application of NDK version 2.0 which I use. However I do made the modifications to configure it to the switch mode/ ALE BYPASS mode. You install the NDK 2.0 on your system and then configure it in to ALE BYPASS mode the way I did. I have sent you a PDF file describing how I did it so that you will be on the same page.
I hope that you will be able to reproduce the problem and also figure out where i am wrong, and correct me.
Thanks for the pdf file.
Unfortunately I don't have that hardware available to me. This will make it hard to reproduce. Do you know of any other way I could reproduce this 64 byte burst test that you are running?
Basically the board halts when i send excessive no. of small sized packets(64 or 128byte) in a single burst. You can reproduce the problem easily after building the project.
You can simply use any tool(hardware/software) to send excessive/large no. of packets(64 byte or 128 byte) to the board. You can try by creating a senario in which large no. of ARP packets are sent to the board, this will recreate the problem.
I hope this clarifies the situation.
i am waiting for your reply.
Please give me a yes or no.
I apologize for the lack of response. I'm working on trying to reproduce your problem. I found a tool that will allow me to send a packet burst. I haven't tried it yet but it sounds promising. I will let you know as soon as I have more information.
Thanks for your patience.
I've been following the instructions you sent in the pdf. The instructions are good. However, the step for making the updates to the csl_emac.c file (in step 5) is not completely clear.
There appears to be a block in your version of the code that I don't have (see screen shot - there is a curly brace surrounding the code - what does it belong to? A different if statement?)
I'm also suspecting that I have a different version of the files than you do. I suspect that because the line numbers you state in the pdf do not match for the files that I have.
Can you attach your updated csl_emac.c file? Or better yet, attach the entire updated helloWorld project? This would make things go quickest for me. (I have limited time for each forum question, so the less time spent doing set up, the sooner I can get to debugging the real problem).
P.S. Below is the code in my version of csl_emac.c ... see, I don't have the block that is shown in your code:
/* * If this is the last frag, the forward pointer is (void *)0 * Otherwise; this desc points to the next frag's desc */ if (PktFrags == 1) pDescThis->pNext = 0; else pDescThis->pNext = pdc->pDescWrite;
pDescThis->pBuffer = pPkt->pDataBuffer + pPkt->DataOffset; pDescThis->BufOffLen = pPkt->ValidLen;
if (pPkt->Flags & EMAC_PKT_FLAGS_SOP) pDescThis->PktFlgLen = ((pPkt->Flags& (EMAC_PKT_FLAGS_SOP|EMAC_PKT_FLAGS_EOP)) |pPkt->PktLength|EMAC_DSC_FLAG_OWNER); else pDescThis->PktFlgLen = (pPkt->Flags&EMAC_PKT_FLAGS_EOP) |EMAC_DSC_FLAG_OWNER;
/* Enqueue this frag onto the desc queue */ pqPush(&pdc->DescQueue, pPkt); PktFrags--; } }
Another thing. While Googling around on the web about the ALE bypass, I saw some old forum posts in which some customers were having a lot of problems getting the DM648 into this mode.
Would you mind if I posted your PDF instructions to the forum so that others can benefit from this?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.