The TI E2E™ design support forums will undergo maintenance from July 11 to July 13. If you need design support during this time, open a new support request with our customer support center.

  • State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 271 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.

TMS320C28346: McBSP MDXB state after frame end

Patrick Ruf
Genius 4950 points
Part Number: TMS320C28346

Hi,

We use the McBSP interface in the following transmit way:

- Normal Clock Mode (mcbspReg->SPCR1.bit.CLKSTP=0)
- No companding (mcbspReg->XCR2.bit.XCOMPAND=0)
- No transmit multichannel selection (mcbspReg->MCR2.bit.XMCM=0)
- Use internal clock (25MHz from 150MHz Low speed clock)


Question:
What does the MDXB pin after all bits of a frame have been transmitted? Does it stay at the level of the last transmitted bit or does it go into high impedance state?

Thanks and best regards,
Patrick

  • 0
    TI__Guru* 79090 points

    Patrick,

    As you likely have seen the McBSP section isn't clear on this aspect :( I would suspect that it would go back to its default high impedance state once the transfer is complete.  Are you observing some behavior that is causing issues in your system?

    Best,
    Matthew

  • 0 in reply to MatthewPate
    Genius 4950 points

    Matthew,

    We have seen on the receiver side that the receive data signal is changing after the frame should have finished. It is not an issue so far but we have been curious why this happens. Our configuration is as follows:

    1. McBSP Transmitter (first TMS320C28346)
    2. LVDS driver
    3. LVDS receiver
    4. McBSP Receiver (second TMS320C28346)

    So I suspected that MDXB must go in to high impedance state and that crosstalk between the clock of the McBSP Transmitter (MCLKXB) and MDXB is the cause of the state change seen on the Receiver side.

    Regards,
    Patrick


  • +1 in reply to Patrick Ruf
    TI__Guru* 79090 points

    Patrick,

    Thanks for the background, I was also trying to understand how the state of the pin would get sensed, since we are technically post transmission and the output clock should be static.

    From the above you're thinking that the MCLKXB from one MCU is noise coupling onto the other MCLKXB and then latching this data?

    I'm not sure if this will help, but the GPIOs themselves have a internal PU.  I would check on the respective GPIO used for MDXB, but we could try to enable the PU (in the GPIO control register space GPIOPUDIS I think).  That would at least get the pin in a known state when in High Z.  Another alternative would be to put a PD/PU external.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Genius 4950 points

    Matthew,

    Thanks for your answer. I like the idea of activating the internal pullup resistor on MDXB. With the pullup this signal should be in a more defined state and crosstalk from MCLKXB onto this signal should be more unlikely in the case that MDXB is going into high impedance state after frame ends. I will report back as soon as I have news. But this could easy take two or more weeks as this is firmware related and it is holiday time. Please leave this thread open until then. Thanks.

    Regards,
    Patrick  

  • 0 in reply to Patrick Ruf
    TI__Guru* 79090 points

    Patrick,

    Sounds good, I think the thread should stay open for at least 30days with no activity before it closes.  In any case I can re-open as needed.

    Best,
    Matthew

  • 0 in reply to MatthewPate
    Genius 4950 points

    Matthew,

    We activated the internal pullup resistor on MDXB. No crosstalk from MCLKXB onto MDXB has been seen after this firmware change so far.
    To me that clearly shows that MDXB goes into high impedance state after it has finished sending out all bits of the frame. It does this even when transmitting without multichannel selection.

    Best regards,
    Patrick