• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 669 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.

RTOS/TCI6630K2L: msgcom channel communication suddenly stop working

Gautam Shah90
Genius 3815 points

Part Number: TCI6630K2L

Tool/software: TI-RTOS

Hi,

Currently i am running an LTE system with syslib rel 3.0.7.

I am observing some issue with msgcom channel communication.

With UE attach & data, system running fine, but when i start HO, after some successful ping-pong HO msgcom channel communication is stopped.

With Further debugging i found that some time the registered interrupt function is not called or some time Msgcom_get take too much time to retrieve the pckt "around 3 to 4 ms"

Msgcom creation code

    chConfig.mode                     = Msgcom_ChannelMode_NON_BLOCKING;
    chConfig.appCallBack              = (MsgCom_AppCallBack)NULL;
    chConfig.u.queueCfg.interruptMode = Msgcom_QueueInterruptMode_ACCUMULATED_INTERRUPT;
    chConfig.u.queueCfg.accumulatorChannelType = Msgcom_AccumulatedChannelType_HIGH;
    chConfig.u.queueCfg.maxPageEntries         = 5;
    chConfig.u.queueCfg.pacingTimerCount       = 0;
    chConfig.u.queueCfg.accumulatorChannel     = ptrCfg->accChannelResponse[4].accChannel;

    gPhysicalChHandle = Msgcom_create (PDCP_UL_CHANNEL_NAME, Msgcom_ChannelType_QUEUE, (Msgcom_ChCfg*)&chConfig, &errCode);

        memset(&chConfig, 0, sizeof(chConfig));
        chConfig.mode                              = Msgcom_ChannelMode_NON_BLOCKING;
        chConfig.appCallBack                       = (MsgCom_AppCallBack)macUeOppIndChannelIsr;

chConfig.u.virtualChannelCfg.phyChannel    = gPhysicalChHandle;

iccQueue_g[UEOPPIND_QUEUE].channelHandle = Msgcom_create (TI_MAC_UE_OPP_MSGCOM_CHN, Msgcom_ChannelType_VIRTUAL, (Msgcom_ChCfg*)&chConfig, &errCode);

Same kind of behavior observed when i tried changing L2 scheduling algo from RR to QOS.

In this scenario L2 is not able to receive packet sent by L1 "Msgcom channel is the high priority interrupt channel & the receiver task is the highest priority task" .

Its confirm that L1 is transmitting packet correctly but L2 registered interrupt function is not getting called after some time.

Its also confirmed that L2 code does not calling any Hwi_disable or system_interrupt disable function when issue observed.

Please help me to resolve this issue.

Let me know if u need any further information.

Thanks & Regards

Gautam Shah 

 

  • 0
    TI__Guru**** 161600 points
    We're looking into this. Please post the TI RTOS version that you use.

    Best Regards,
    Yordan
  • 0
    TI__Mastermind 21025 points
    Hi Gautam, this is likely a configuration problem. Wherever you are making these changes, make sure you've changed everything associated with it (I'm guessing you're modifying the Linux dts file?).

    MsgCom, the Navigator's Accumulator and QOS firmware are all users of Navigator hardware queues. It is possible there is a disconnect in the configuration of queues, and that messages (descriptors) are just piling up somewhere instead of being properly forwarded. The challenge is to find the queues that are actually being used, then monitor the number of descriptors contained in them over. This should help in finding the problem. You will need to become acquainted with the Navigator User's Guide to find the Queue Manager's registers and register addresses.

    -dave
  • 0 in reply to db_woodall
    Genius 3815 points

    Hi Yordan & Dave,

    Thanks for your response.

    RTOS version we are using as : bios_6_40_04_47.

    Regarding configuration changes, i don't think i have change much regarding bios or syslib configuration. DTS file is also not changed.

    Same setup is working fine when it compiled with TDD flag.

    When same code is compiled with FDD flag we are observing these issue.

    Configuration files "dts, .cfg, .bld & .cmd are almost same for TTD & FDD setup.

    Regarding Navigator hardware queues, i will try as u suggested and will update further findings. 

    Thanks & Regards

    Gautam Shah