Forums

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

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

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

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

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

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

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

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

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

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.

Regards

Mark

Steven

i am waiting for your reply.

Please give me a yes or no.

Hi Mark,

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.

Steve

Mark,

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

Steve

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--;
        }
    }

Mark,

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?

Steve