• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 100 subscribers
  • Views 1207 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MessageQ_open Hangs on C6678EVM

Parshant Chowdhary
Intellectual 320 points
Other Parts Discussed in Thread: SYSBIOS

1464.VideoPhyTest_evmc6670.rar

0412.VideoStream.rar

Hi,

Please find attached 

1. VideoStream.rar: Contains core 0 code. This code defines two task TraceThread and L2thread.
   --L2Thread: Recv packet from socket and write on Core 1 messageQ.
   --TraceThread: Reads data on the message queue and send it on socket.
2. VideoPhyTest_evmc6670 : Core 1 code. This code will create a phythread on core 1.
   -- Core 1 reads data from its message queue and dump data back to TraceThread(Core 0) message queue.

All queues use the same heap define in Shared memory region(DDR3). 

Issue:
 --L2thread when trying to open messageQ of Phythread
             }
   System_printf(" Bind Succesfully\n");
            do
                   {                
                           System_printf("L2Thread going to sleep\n");
                        (hangs)-->status = MessageQ_open(SOCKINMSGQ, &phyQueueId);
                           System_printf("status:%d\n",status);
                        TSK_sleep(500);                 
                        System_printf("L2Thread is awake\n");
                }while(status < 0);
        System_printf("Phy Message Queue open Successfully\n");

 ---Phythread also hangs when open messageQ of TraceThread
       

                     while (MessageQ_open(SOCKOUTMSGQ, &txQueueId)< 0)
                        {
                                System_printf("PhyThread going to sleep");
                                TSK_sleep(500);
                                System_printf("PhyThread is awake");
                            }

Regards,
Parshant

 

  • 0
    TI__Genius 9915 points

    Prashant,

    One thing that stands out on the first look is that, you are using DDR3 memory for the heap and i just want to make sure that you are validating the memory and writeback when updating the memory.

     

    Thanks,

    Arun.

  • 0 in reply to ArunMani
    Intellectual 320 points

    Hi Arun,

    I am not doing validating the memory and writeback when updating the memory. If you see the .cfg file in the attached code, there i have disabled cache for DDR3 region. Is i still need to do the validation of memory and writeback? If it is such a case, I am not sure about the changes required for the same. Could you please give me some guidance for the same?

     

    Regards,

    Parshant

  • 0 in reply to Parshant Chowdhary
    Intellectual 320 points

    Hi,

    Any clue on the above mentioned issue. I am still debugging the same. 

     

    Regards,

    Parshant

  • 0 in reply to Parshant Chowdhary
    TI__Mastermind 32475 points

    Parshant,

    Which version of SYSBIOS and which version of IPC are you using?

    Right off the bat, I noticed that this thread is for evm6678, but your executables say evm6670.

    Are you trying to build/run for the evm6670?  Make sure the platform you specified matches your actual board otherwise its not going to work.

    Judah

  • 0 in reply to judahvang
    Intellectual 320 points

    Hi Judah,

     

    I am using the following tools

    ccs_base_5.0.3.00028

    ndk_2_20_04_26

    mcsdk_2_00_01_12

    pdk_C6670_1_0_0_12

    ipc_1_23_01_26

    bios_6_32_01_38

    I am building for C6670 EVM. By mistaken, it was mentioned C6678 in the thread. 

    Thank You for quick reply.

    I have checked ROV also and found INTR5 is generated for Core 0 and Core 1. The thread trying to open messageQ seems to be blocked on some Unknown as shown by ROV. As, I have debug its found that it lost somewhere in NameServerRemoteNotify. I have attached the code for both the cores core 0 and core 1.

    Please let me know if you need other information.

    Regards,

    Parshant

     

  • 0 in reply to Parshant Chowdhary
    TI__Mastermind 32475 points

    Parshant,

    I tried out your executables.  I notice that on Core0 [VideoStream.out] the eventId for the Ipc interrupt is set to 4.  This should be eventId 90.  Seems like something change this from the default provided by Ipc.  The default IPC Hwi vector is 5 with an event id of 90, but I see that for your executable is Hwi vector 4 with event Id 4.  The other executable [VideoPhyTest.out] is using Hwi vector 4 with the correct event Id 90.  You can see this in the Hwi module's  ROV "Basic" tab.  See attach file:

    Judah

  • 0 in reply to judahvang
    Intellectual 320 points

    Attached Binaries used for observation:

    8867.Binaries.rar

    Hi Judah,

    Thank you for the guidance.

    I have taken the observation as suggested by you but i have not seen such issue in the ROV data. I have found both core showing INTR 5 event ID 90 for IPC. Please see the file attached 

    core 0

     

    Core1

     

    Regards,

    Parshant

  • 0 in reply to Parshant Chowdhary
    TI__Mastermind 32475 points

    Parshant,

    Okay, for some reason my ROV is not showing me the right stuff.  It could be that my BIOS/IPC version is newer and doesn't match your build.

    Concerning your problem, I looked at your *.c file.  You cannot call any XXX_open() from within the main() since those require interrupts to be enabled.  In main() global interrupts are not yet enabled.  You are calling HeapBufMP_open() in TraceInit() which is being called from main().

    Judah

  • 0 in reply to judahvang
    Intellectual 320 points

    4760.VideoStream.rar

    5808.VideoPhyTest_evmc6670.rar

     

    Judah,

    Yes, I have moved the HeapBufMP_open to PhyThread task but things has not improved. I am also attaching the new code, as i have made some changes during debugging but things has not improved from last status.  

     

    Regards,

    Parshant

  • 0 in reply to Parshant Chowdhary
    TI__Mastermind 32475 points

    Parshant,

    Glad that you made those code changes.  With your new changes I was able to reproduce what you are seeing, however, I was also able to determine why the app is still spinning.  The problem is that there are some KICK registers which should be unlocked but for some reason they are locked when you get to the HeapBufMP_open.  When these registers are locked, any IPC interrupt is disabled and lost.  There was an issue in some IPC builds in which if more than 1 processor tried to write these registers at the same time, it was a problem.  I don't know if this is what you are running into but it could possibly be.  Or it could be that somewhere else in your software stack, someone is locking the KICK registers back up.  If its an IPC issue, you might try upgrading to the latest IPC 1.23.05.40 release to see if it solves your problem.  Meanwhile, you can try to work around the problem without upgrading any of your software stack by doing the following:

    Add these to Core0's TraceInit():

        volatile UInt32 *kick0 = (volatile UInt32 *)0x02620038;
        volatile UInt32 *kick1 = (volatile UInt32 *)0x0262003C;

    In Core0's TraceInit(), right after Ipc_start() before the System_printf(), I would write the kick0 and kick1 registers.  Remember that this needs to be done before any of the XXX_open() calls from either core since these open calls go through the IPC interrupt.

                kick0[0] = 0x83e70b13;      /* must be written with this value */
                kick1[0] = 0x95a4f1e0;       /* must be written with this value */

    If putting after Ipc_start() doesn't work, try it at different locations in your code.  Try it before Ipc_start() or Try it on Core1.  Only do this from one of the cores, not both.

    Judah

  • 0 in reply to judahvang
    Intellectual 320 points

    Judah,

    I have tried to make changes suggested by you on core1 as well as core0 but my HeapBufMP_open still spinning. I have tried changes on one core at a time not both, as suggested by you. I have also tried to view the "0x02620038 & 0x0262003C" in memory browser and watch expression but it showing me that value at this memory location is 0. Could you please let me know how i can ensure that value at the above address has been written correctly or not?

    Thank you for the support. 

     

    Regards,

    Parshant

  • 0 in reply to Parshant Chowdhary
    TI__Mastermind 32475 points

    Parshant,

    These are write registers.   A read of these registers will always show 0 and viewing them in CCS will also show up as 0.  I don't know if there's a way to determine if the registers are enabled or not.

    What you can try is this:  Set a breakpoint on the HeapBufMP_open() and MessageQ_open() on both cores.  Then go and manually set the values in the respective addresses through a CCS window (This is what I did).  Then remove the breakpoints from both cores and see if that works for you.

    Another things you can try is to set a Hardware watchpoint at the address "0x02620038" to see who/when this address is getting written.  This can help you determine the code that is writing this register.

    Judah