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/66AK2G12: McASP: Run McASP as RX only with no TX clocks

Part Number: 66AK2G12

Tool/software: TI-RTOS

Hello,

I am trying to run McASP1 on the K2G as a receiver only.  I have a clock going to the RX clock and frame sync, but no connection to the TX clock lines.  I've made significant progress on this, but I'm not seeing any repeated traffic on the port. My application is based upon the McASP example projects.

I also have McASP0 set up passing audio without issue.  The hope is to run McASP0 with 4 serializers in RX, 12 in TX, and McASP1 with 8 serializers in RX for a total of 12 input pins and 12 output pins.

In order to run the McASP RX State machine off of the RX clock pins, I had to set the ASYNC bit (which is located in the TX State machine registers).  In order to set the ASYNC bit, I had to start up the TX state machine.  In order to start the TX state machine, I had to set up an extra serializer as TX and set up the TX clocks using the internal clock.  In order to prevent TX underrun, I had to delete the TX channel before I start the transfers.  So, now everything compiles and starts up.  The LPSCs are on, the clocks are running, and I'm just curious what else I might need to check.  

It's worth noting that I have Linux running on the other core.  I have set aside the EDMA channels in the device tree, but I am not confident in my setup on the DSP end for the DMA.  I have the structures to reserve the channels, but I am not sure what shadow region corresponds to which core.  So it's possible that the callback is not getting called because the EDMA event is not making it through.  I'll be looking into that next week, but I just thought I'd ask you all to see if anyone had any ideas (or knows if this is even possible).

Cheers,

Jeff

  • Hi Jeff,

    I've notified the RTOS team. They will post their feedback directly here.

    Can you share which TI RTOS SDK version are you using?

    Best Regards,
    Yordan
  • Yordan,

    Thank you for your reply, I look forward to hearing what they have to say.

    This has been attempted on RTOS SDK 4.2.0.9 and RTOS SDK 4.3.0.5.

    Jeff
  • Jeff,

    This is more of an IP level question than a software question. what may help is if you confirm if you are using synchronous mode or asynchronous mode. In the sync mode the RX clock is derived from TX clock so I am fairly certain that in sync mode this is not supported.

    I will let my HW/design colleagues comment on whether this is supported in async mode.

    Regards,
    Rahul
  • I can confirm that it does not work in Sync Mode, hence the workaround to enable setting ASYNC. This makes perfect sense and is clearly stated in the datasheet.

    The aim is to use Async mode to run the RX state machine only. The reason for this was an error in PCB layout where we only attached clock signals to the RX clock lines. The TX clock lines are disconnected. This will be fixed in the next revision, but we need to try to get this hardware functional.

    Jeff
  • I have been working a little more on this issue and have found some things. First, I think it's necessary for me to share a little more of what I'm trying to do.

    I need to do 24 channels in and 24 channels out via the McASP. We made a mistake routing the clocks, so we can only use McASP1 for Rx. The original plan was to use 8/8 Rx/Tx on McASP0 and 4/4 Rx/Tx, but due to the hardware error, I need to do 4/12 Rx/Tx on McASP0 and 8/0 Rx/Tx on McASP1.

    It appears that 12/4 on McASP0 is not possible due to FIFO size limitations. In the McASP driver, the #define for the DMA ratio has a comment that gives a formula: (this ratio * num_serializers* mcasp word_size) <= Afifo_size_in_bytes (256), which limits the DMA ratio to 1 with 8 serializers. So, assuming this is true, I can only do 8 serializers per direction. Can anyone confirm this for me?

    I have been unable to get the McASP1 to run continuously in Asynchronous mode. The driver reports no errors, but there are no receive events after priming. The hardware events are getting set up in the same manner as for McASP0. In fact, most of the configuration is copied directly from the McASP0 side of the code.

    I will be setting the application up as a standalone app (running without linux running) soon to verify the problem still exists.

    Jeff
  • As I suspected, when run as a standalone app, the same problems appear. The McASP0 side of things works as expected, but the McASP1 side of things seems to stop after 3 receive interrupts.
  • Hi Jeff,

    Have you confirmed that the pin mux settings are letting the McASP1 RX data in through the pin mux?

    Regards,
    Mark
  • Hi Mark,

    Sorry for the delayed response. I have been working on other parts of this product and have not had time to verify this. I will post my findings as soon as I get the chance to test.

    Jeff