• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 99 subscribers
  • Views 897 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.

DM814x McBSP TX/RX at different FS rates at the same time.

Zhigang Liu
Prodigy 150 points
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

Hi:

We are using DM8148 McBSP port to connect to two seperate audio chips, one for RX and one for TX, they are working at different FS rate.

Since McBSP has seperate FS and CLK lines, so we can connect that way.

But when we are writing the drivers, we found we can only get RX and TX data going if we enable SRG. and there is only one SRG that we can either set to use RX FS or TX FS, but not both at the same time.

Please help us since we might need to change our hardware design if this is the case for McBSP on DM8148.

regards

--Zhigang

  • 0
    Prodigy 150 points

    To be more specific, can we bypass SRG and set McBSP in true slave mode for both TX and RX from DM8148 side?

  • 0
    TI__Intellectual 975 points

    Zhigang, to clarify your questions: 

    In OMAP-L138, while holding the sample rate generator in reset, you were able to set CLKR_int and FSR_int via the CLKR and FSR pins as inputs.

                    -You need to replicate this functionality in DM8148!

     

    The OMAP-L138 datasheet contains a block diagram(Figure 26-2) that indicates how the CLKR_int and FSR_int are generated

                    -This is not present in the DM8148 datasheet!

                    -On DM8148 when you try to use CLKR and FSR as inputs (w/SRG in reset) the McBSP doesn’t receive anything.

                                    -If the SRG is taken out of reset then the McBSP receives properly!

     Hence we have two questions:

    1.      On DM8148 how do we control CLKR_int and FSR_int externally? Is it done the same way as on OMAP-L138 or a different way?
    2.      Is there a block diagram that displays how the CLKR_int and FSR_int signal are generated with the SRG?

     

    Zhigang, is this correct representation of your issue?

    DaVinci team, does this problem make sense to you?

  • 0 in reply to Ketan_Patel
    Prodigy 150 points

    Yes.

    We had McBSP driver working under L138 (DSP side), SRG bypassing is fine and true slave mode is supported.

    And when we port the same driver to DM8148 (DSP side), we meet this issue about SRG.

  • 0 in reply to Zhigang Liu
    TI__Guru*** 125430 points

    Please provide a dump of your McBSP registers for analysis. 

    Hopefully you noticed that the OMAPL138 and DM8148 have different implementations of the McBSP, i.e. the registers are not the same.

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    Please also provide the PINCNTL registers that correspond to the McBSP pins you're using.

  • 0 in reply to Brad Griffis
    Prodigy 150 points

    Here is the McBSP register dump:

    F510    1716    0000    0000
    0000    0000    0000    0000
    02C0    0000    0000    0000
    0000    0000    0240    0000
    0000    0000    0040    0000
    901F    0000    007F    0000
    0001    0000    0001    0000
    0007    0000    0000    0000
    0001    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0037    0000
    0000    0000    0000    0000
    0000    0000    0008    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0112    0000    0000    0000
    478F    0000    0800    0000
    0808    0000    0080    0000
    0000    0000    0084    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000

    Starting address is 0x47000100, which we assume is the start of register  DRR_REG (100h).

    Here is the register map in TRM:

    100h DRR_REG McBSP Data Receive Register Section 17.3.14
    108h DXR_REG McBSP Data Transmit Register Section 17.3.15
    110h SPCR2_REG McBSP Serial Port Control Register 2 Section 17.3.16
    114h SPCR1_REG McBSP Serial Port Control Register 1 Section 17.3.17
    118h RCR2_REG McBSP Receive Control Register 2 Section 17.3.18
    11Ch RCR1_REG McBSP Receive Control Register 1 Section 17.3.19
    120h XCR2_REG McBSP Transmit Control Register 2 Section 17.3.20
    124h XCR1_REG McBSP Transmit Control Register 1 Section 17.3.21
    128h SRGR2_REG McBSP Sample Rate Generator Register 2 Section 17.3.22
    12Ch SRGR1_REG McBSP Sample Rate Generator Register 1 Section 17.3.23
    130h MCR2_REG McBSP Multichannel Register 2 Section 17.3.24
    134h MCR1_REG McBSP Multichannel Register 1 Section 17.3.25
    138h RCERA_REG McBSP Receive Channel Enable Register Partition A Section 17.3.26
    13Ch RCERB_REG McBSP Receive Channel Enable Register Partition B Section 17.3.27
    140h XCERA_REG McBSP Transmit Channel Enable Register Partition A Section 17.3.28

  • 0 in reply to Zhigang Liu
    TI__Guru*** 125430 points

    Was this a functional or non-functional configuration you gave me?  What specific register changes are needed to make things work/break?

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    Are you trying to do some kind of TDM filtering?  Incredibly I've never actually used MCR as a non-zero value!  It looks like you're setting up for 32-channel TDM where only a single channel is enabled.  Though I also see that the receiver is setup to receive 3 16-bit words and the transmitter is setup for 2 16-bit words.  It looks a little strange to me.

    Please provide high level details on what you're trying to accomplish so I can make sure you're going about this the right way.

  • 0 in reply to Brad Griffis
    Prodigy 150 points

    currently I only work on RX side only. TX side is set but never used.

    The key observation for me is that.

    1. I always run a command (using SPI) to enable my external chip, and verify that the chip started McBSP on RX side with FS and CLK and Data.

    2. Then I do two things:

        2.a  When SPCR2_REG is set as 02c0, like in the dump, I can call receive function to receive data on the RX side.

        2.b When SPCR2_REG is set as 0200, (put SRG in reset), I can call receive function but it will stuck since data was never ready on McBSP RX side.

    As for config. our RX device use 48 bits per frame and 48KHz FS and about 1.6MHz CLKR.

    For TX it is different, but my driver is currently working on RX only, we need touched TX side.

  • 0 in reply to Zhigang Liu
    Prodigy 150 points

    Here is a register when it is not working (only the one in red is changed):

    0000    0000    0000    0000
    0000    0000    0000    0000
    0200    0000    0008    0000
    0000    0000    0240    0000
    0000    0000    0040    0000
    901F    0000    007F    0000
    0001    0000    0001    0000
    0007    0000    0000    0000
    0001    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0000    0000    0037    0000
    0000    0000    0000    0000
    0000    0000    0008    0000
    0000    0000    0000    0000
    0000    0000    0000    0000
    0137    0000    0000    0000
    478F    0000    0800    0000
    0808    0000    0080    0000
    0000    0000    0084    0000
    0000    0000    0000    0000

  • 0 in reply to Zhigang Liu
    TI__Guru*** 125430 points

    Are you able to reliably receive data in the case where you have FRST = GRST = 1?  In other words, are you sure the received data is correct and are you able to continuously receive it for long periods of time?

    Can you please provide the PINCNTL values for the McBSP pins?

    Looking at your registers I would make the following changes:

    • Make SRGR2[GSYNC]=0.  That feature is for generating FSX (output) to have the same phase as FSR (input).
    • Make MCR2 = MCR1 = 0.  The "multichannel feature" was for things like cell phones 10 years ago doing TDM communications, i.e. there would be 32 channels of data flying through the air and you would pluck out one of them.  In your case it sounds like you want all 3 input samples and every output sample, so there's not a reason to use this feature.  Since I've not ever used this feature it's not clear if this could be related to your issues.
  • 0 in reply to Brad Griffis
    Prodigy 150 points

    Thanks. We did the register changes and RX seems working now.

    We will do more test and TX side later.

    Thanks again for your help.