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,

    Mark Depp
    when 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.

    Steve

  • In reply to Mark Depp:

    Steve

    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.

    Thanks

    Regards

    Mark

  • In reply to Mark Depp:

    Mark,

    Mark Depp
    In 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.

    Steve

  • In reply to Steven Connell:

    Steve

    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.

    Mark

  • In reply to Mark Depp:

    Mark,

    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 ...

    Steve

    P.S. I'll send you a friend request now ...

  • In reply to Steven Connell:

    Steven

    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

     

    Regards

    Mark

  • In reply to Mark Depp:

    Hi Mark,

    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 Depp
    The 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?

    Steve

  • In reply to Steven Connell:

    Steven

    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.

    Regards

    Mark

  • In reply to Mark Depp:

    Hi Mark,

    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?

    Steve