• State Resolved
  • Locked Locked
  • Replies 24 replies
  • Subscribers 102 subscribers
  • Views 2309 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

C674x: McBSP problem

Kaka
Guru 24520 points

Hi TI Experts,

My customer faced the McBSP problem. I summairzed the phenomoen as below.

[Phenomenon]
They transmit and received the Audio data by using McBSP with TDM mode. But their system sometimes unexpected shift the time slot after power-up.
i.e. If their system happned this phenomenon, C6742 transmitted the audio data on 13 timeslot even thouhg they have set the timeslot as 12.

So, please let me confirm the following question.
[Question.1]
Have you ever observed this phenomenon?
[Question1-2]
If yes, would you please teach us the cause of this issue? And please let me know the solution in order to improve this.

[Question.2]
Is there a potencial that this phenomenon(timeslot ***) will occur by some noise or glitch on BLCK except for bit ***?
[Question.2-1]
If yes , would you please teach me the mechanism for this?

If you need more information, please let me know. I will get it from my customer.
Best regards.
Kaka

  • 0
    Guru 24520 points
    Would you please help us?

    Best regards.
    Kaka
  • 0 in reply to Kaka
    TI__Guru** 115380 points
    Kaka,

    Can you please provide more details on which driver and OS are you using? Are you testing on the TI hardware or custom hardware.
    how are the clocking, BCLKs and framesyncs setup? Is the CPU or EDMA moving the data into the MCBSP FIFOs. Does this issue occur only at power up or does this condition recover after some time? Is this observed only at room temperature or at higher temp conditions? Also, what is connected to the other side of the MCBSP is it an AIC or ADC interface. Can you share any scope shots when this event occurs.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Guru 24520 points
    HI Rahul,

    Thank you for your response.
    I do not have answer for your some of questions. I will confirm them to my customer.

    > Are you testing on the TI hardware or custom hardware.
    [Kaka]
    Customer hardware.

    >how are the clocking, BCLKs and framesyncs setup?
    [Kaka]
    They have input the 24MHz to DSP and they used this clock for BCLK.
    Just in case, I attached the registers of McBSP as below.
    SPCR: 0x003100B1
    PCR: 0x00000080
    RCR: 0x00141F00
    XCR: 0x00141F00
    MCR: 0x00000000
    SRGM: 0x20000001

    >Is the CPU or EDMA moving the data into the MCBSP FIFOs
    [Kaka]
    Thay used the EDMA moving the audio data.

    >Does this issue occur only at power up or does this condition recover after some time?
    [Kaka]
    If this issue occurred after power up, it kept to occur until restart their system.

    If you have more questions, please let me know.
    Best regards.
    Kaka
  • 0 in reply to Kaka
    Guru 24520 points

    By the way, would you please provide answer for our questions?
    Aslo what kinds of signals which you requested? please point out them.

    Best regards.
    Kaka

  • 0 in reply to Kaka
    TI__Guru** 115380 points
    Can you confirm that the EDMA write accesses to the DXR use the write synchronization event, XEVT, provided by the McBSP. Similarly, an EDMA read of the DRR is synchronized by the internal REVT signal from the McBSP? Is the EDMA init and first transfer done after the MCBSP setup is complete?

    Please check the correct MCBSP software initialization sequence required in chapter 5 of the document provided below:
    www.ti.com/.../spra488c.pdf


    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Guru 24520 points

    Hi Rahul,

    Thank you for your response.
    My customer correspond to the following issue.


    So, please let me confirm the following question.
    Does the sequence in the document (spra488c.pdf file) avoid this issue?

    If you have any questions, please let me know.
    Best regards.
    Kaka

  • 0 in reply to Kaka
    TI__Guru* 81005 points
    Kaka-san
    We will check with the wiki author, but our understanding is that the sequence in the device TRM is correct and for this device we have not heard of any other customer facing similar issues.
    Have we confirmed that your customer is using the sequence from the C6742 TRM , McBSP chapter?
  • 0 in reply to Mukul Bhatnagar
    Guru 24520 points

    Hi Mukul,

    Thank you for your response.
    >Have we confirmed that your customer is using the sequence from the C6742 TRM , McBSP chapter?
    No, they did not implement the initialization sequence on TRM. Now, we request them to do.
    Also, Rahul provided us the new document. So, I would like to know whether it is the same as that sequence on TRM before I will provide it to my customer.
    Best regards.
    Kaka

  • 0 in reply to Kaka
    TI__Guru* 81005 points
    Hi Kaka-san
    The wiki seems to have originated in 2008 , before this device came.
    mcbsp init doc that you are pointing to is from 2004. These are too old.

    We have McBSP on several devices and have perfected our documentation over the years - so i have no reason to believe that the TRM is in correct.
    So it is best for customer to follow the sequence int he TRM and after that if they still see issue , we can discuss.

    I found another post on another device that sounds similar to your customer problem
    e2e.ti.com/.../228538
    Here the guidance was that it can still be a signal integrity issue , but looks like it ultimately had something to do with sequence, register settings.

    So best would be to first ensure that they are following the TRM sequence from c6742 documentation.

    Regards
    Mukul
  • 0 in reply to Mukul Bhatnagar
    Guru 24520 points
    Hi Mukul,

    Thank you for your confirming.
    I got it.
    If my customer cannot resolve this issue even though they follow the sequcence on TRM, please discuss with you.

    Best regads.
    Kaka
  • 0 in reply to Mukul Bhatnagar
    TI__Guru*** 125430 points
    The proper document for C674x is the C674x TRM:

    http://www.ti.com/lit/spruh79

    The issue mentioned in the wiki is covered in Section 24.2.12.2 Special Case: External Device is the Transmit Frame Master. It gives a specific initialization sequence for this case. Please follow it precisely.
  • 0 in reply to Brad Griffis
    Guru 24520 points
    Hi Brad,

    Thank you for your comments.
    I have already informed this information to my customer.
    So, if they will face this issue even though following this sequence, please discuss again.

    Best regards.
    Kaka
  • 0 in reply to Kaka
    Guru 24520 points
    Hi Mukul, Rahul,

    I got two questions from my customer. Please let me confirm them.
    [Question.1]
    Is there anyway to detect whether this issue happen on C6742?

    [Question.2]
    Is there any timing to do the McBSP initialization on c6742 init sequence?
    According to them, if the sequence inserted in first initialization, C6742 did not run. When it was inserted in last initialization , C6742 worked.
    So, they would like to know whether there is any timing to do this sequence on c6742 initialization .

    Best Regard.
    Kaks
  • 0 in reply to Kaka
    TI__Guru*** 125430 points
    Kaka,

    I have resolved many channel swapping issues over the past decade. If this is a "startup channel swap" (as opposed to random run-time swapping), then this is without a doubt related to not properly following the procedure listed in Section 24.2.12.2 Special Case: External Device is the Transmit Frame Master.

    Can you confirm that this issue only happens at power-up? In other words, it either powers up in a correct state and remains in that state indefinitely, or it powers up in a bad state and remains in that state indefinitely? That's what it sounded like from your initial post, but I want to be certain on that point. The solutions vary substantially depending on whether it is startup or run-time swapping, so I want to be sure.

    Assuming this is an issue with startup swapping, kindly have them post their init code here for review and I'll help them fix it.

    Best regards,
    Brad
  • 0 in reply to Brad Griffis
    Guru 24520 points
    Hi Bard,

    Thank you for comment. I answer for your questions.
    My customer said that this issue happened only at power-up. Also I will try to get the init code for their application. If I get this, I will sent you with private message.

    By the way, would you please answer for custmer question as below?
    [Question.1]
    Is there anyway to detect whether this issue happen on C6742?
    [Question.2]
    Is there any specific initialization sequence of C6742?

    Best regards.
    Kaka
  • 0 in reply to Kaka
    Guru 24520 points
    Hi Brad,

    I got more question from customer.
    [Question]
    Does this same issue also happen at recive data?

    Best regards.
    Kaka
  • 0 in reply to Kaka
    TI__Guru*** 125430 points

    1. Yes it can happen on 6742.

    2. There is a specific Init sequence. I have mentioned it twice already.

    3. No, this does not impact receive.

  • 0 in reply to Brad Griffis
    Guru 24520 points
    Hi Brad,

    Thank you for your response.
    For question no.1 and no.2, I would like know the following point of view.

    Question.1
    Can C6742 detect this issue by itself?
    If yes, would you please teach us the solution.

    Question.2
    I have already known that McBSP init sequence on TRM, but they would like to know whether there is the specified init sequence of C6742 device.
    For example, first set the clock, second set the memory peripherals finally set the other peripherals.

    Best regards.
    Kaka
  • 0 in reply to Kaka
    TI__Guru*** 125430 points
    The issue does not occur if the init sequence is followed precisely. There's nothing more I can do to help short of seeing some code.
  • 0 in reply to Brad Griffis
    Guru 24520 points
    They worried about the swapping of channel by noise for devcie on running device. They have alredy known that if there is noise on McBSP clock, channel swapping was occurred at their previous system. So, they would like to know the way to detect channel swapping issue.
    Can C6742 detect this issue?

    Also sorry for some confusion. The other issue happened by the init sequence of C6742. They said that if the init sequence of McBSP is first at the C6742 init sequence, the C6742 did not run even though the power supply for C6742 was good. If that sequence of MaBSP is last at the C6742 init sequence, the C6742 run. So, my customer would like to know the specific sequence for C6742 device.

    Also they tried to provide the init sequence, so if I get it please check this.

    Best regards.
    Kaka
  • 0 in reply to Kaka
    Guru 24520 points
    Hi Bard,

    I make other post for init sequence as below.
    e2e.ti.com/.../560542

    So, please provide your comment for the way of detection the channel swapping issue.

    Best regards.
    Kaka
  • 0 in reply to Kaka
    TI__Guru*** 125430 points

    Kaka said:
    They worried about the swapping of channel by noise for devcie on running device. They have alredy known that if there is noise on McBSP clock, channel swapping was occurred at their previous system. So, they would like to know the way to detect channel swapping issue.

    Is there any evidence to support that noise is causing channel swapping?  Why are they worried about this?  Based on what you've said so far, that doesn't sound like an issue:

    1. You said their issue relates to startup channel swapping.  If this was somehow noise related then it could happen at any time.

    2. Noise would potentially cause an extra BIT (not an extra WORD).  So in that scenario my expectation is that a single sample could be corrupted, i.e. improper data could be sampled if an extra edge was observed.  However, at the next frame sync the data would be realigned relative to the frame sync.

  • 0 in reply to Brad Griffis
    TI__Guru* 81005 points
    Hi Kaka-san
    On your query
    Question.1
    Can C6742 detect this issue by itself?
    If yes, would you please teach us the solution.

    If you are talking about detecting a channel swap via some error flag/interrupt/status mechanism - the answer is no, there is nothing in the McBSP or EDMA IP that will indicate to the CPU about this condition.

    As Brad recommended, please try to share the initialization sequence - for us to be able to efficiently help further and provide more details on the sequence dependency that you are talking about in this thread and the other e2e post.

    Regards
    Mukul
  • 0 in reply to Mukul Bhatnagar
    Guru 24520 points
    Hi Mukul-san,

    Thank you for your response.
    I got it. I will inform your comment to my customer.
    If I get more questions, please let me confirm them.

    Best regards.
    Kaka