• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 98 subscribers
  • Views 2669 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.

Issue with McASP driver?

Blair MacDonald
Intellectual 610 points

I'm working on a project with the C6748 that is sampling using the McASP and having an issue with the deiver under TI-RTOS, I think. The idea is pretty standard, sample until a buffer is full then process the buffer while continuing to sample. The McASP is clocked externally so I'd like to use the power control system to handle sleeping the core or at least dropping the internal clock rate while sampling and then turn it up for processing and back down again. When I try this the driver seems to hang. I've tested the system at all the clock rates I want to use, 100 MHz, 200 MHz and 300 MHz and it works fine as long as I don't change it. The code terminates in the abort loop as soon as I try to change the clock rate and a buffer becomes ready for processing.

Any suggestions?

Blair

  • 0
    TI__Mastermind 26780 points

    Blair,

    Please provide a lot more details...

    Which version of TI-RTOS?

    Is this a custom board, or a TI EVM?

    Which McASP driver?  Is this your own, or one from TI or a third party?

    What is at the other end of the McASP?

    Which “power control system”?

    Which internal clock rate are you changing?

    Is the external master clock left constant?  Is the external rate a multiple of the internal clock rate you are changing?

    How are you changing the frequency?  And are you adapting for the changed frequency within the driver or other software components?

    Which “abort loop” gets triggered?

    ...

    Thanks,
    Scott

  • 0 in reply to ScottG
    Intellectual 610 points
    Thanks for getting back to me Scott. The version of TI RTOS is 2_00_01_23, The board is a TI eval board at the moment, a LCDKC6748, the driver is the TI one that ships in the BIOS PSP package, a TI ADC is on the other end of the McASP, the power control system is the power control module from TI-RTOS for the C6748, trying to change the core clock rate from PLL0, the external master clock is left constant, attempting to use the power modult to change the setpoint for frequency using the Power_changeSetpoint function.

    It looks like a timeout is detected within the driver, which may be normal behaviour as I may be trying to do something that should not be done, but I can't find any documentation that says so. The idea is to leave the core clock to the megamodule and peripherals at 100 or 200 MHz while sampling then turn it up to 300 or 400 MHz while processing. Eventially we may try sleeping the core, but there are other things we still need to do in idle at the moment. Ive tested the system at all the clock rates I want to use and it works fine. It only seems to have problems when I try and move from one clock rate to another. At all times the McASP external clock remains constant. I havent done any compensation for the internal core clock in the driver as it did not look like it was needed if I keep the external McASP clock constant.

    Thanks,
    Blair
  • 0 in reply to Blair MacDonald
    TI__Mastermind 26780 points

    Blair,

    Thanks very much for the additional details!

    Can you please point me to the driver in the 2_00_01_23 installation?  I’m not finding it. :O/

    You say “I havent done any compensation for the internal core clock in the driver as it did not look like it was needed if I keep the external McASP clock constant”.  

    If the port is clocked externally, and you don't need to change any register configuration for different CPU frequencies, then generally you wouldn't need a notification to the driver.

    I'm wondering if maybe there is some attempted ADC activity while the scaling operation is occurring? While scaling PLL0 it has to be put into bypass.  I'm wondering if maybe the port is made active while running at the bypass frequency and this is triggering the timeout?

    Is the driver made fully idle during the setpoint transitions?  If not, maybe it needs to register for Power_PENDING_CPU_SETPOINTCHANGE and Power_DONE_CPU_SETPOINTCHANGE notifications to keep idle during the setpoint change.

    Can you please point me to your driver?

    Thanks,
    Scott

  • 0 in reply to ScottG
    Intellectual 610 points
    Scott:

    Sorry for taking so long to get back to you. The driver is part of the BIOS PSP package, not the TI-RTOS release. It is in the install directory at C:\ti\biospsp_03_00_01_00\drivers\mcasp. All I had to do was link to it and the EDMA driver and I had instant access to the McASP. As far as I can tell the driver has no knowledge of the power control system and is not regestering for the Power_PENDING_CPU_SETPOINTCHANGE or the Power_DONE_CPU_SETPOINTCHANGE notifications, but I have not had a thourough look.

    As for bypassing the PLL while scaling, I was assuming that the power module handled this. If not it definately could cause my issues.

    Blair
  • 0 in reply to Blair MacDonald
    TI__Mastermind 26780 points

    Blair,

    OK, thanks, I’ll hunt it down and look at it later today.  In the meantime…

    Is it possible the ADC is activating the McASP while the setpoint transition is progressing?

    If the driver is not registering and getting notifications from the power manager, one other thing you could try is closing the driver before doing the setpoint change, and then reopening it after.  I don’t know if this is feasible for your end application, but it could rule out the question of McASP activity during the transition.

    And regarding “As for bypassing the PLL while scaling, I was assuming that the power module handled this.”… yes PWRM handles this.  And depending upon the transition, it will also bypass PLL1 when necessary.  My point was that if your driver or peripheral becomes active while the PLL is bypassed, then that might be the reason for failure.

    Regards,
    Scott

  • 0 in reply to ScottG
    Intellectual 610 points
    Scott:

    In our application, the McASP is the master and provides all the clocks to the ADC so there would be no unexpected data from the ADC. The McASP could still get data arriving while the PLL is bypassed as the sampling is continuous. Since the McASP is clocked externally for sample clock generation, can its internal circuitry run fast enough while the PLL is bypassed? The basic idea of what we want to do is to turn the clock down, while continuously sampling, stay in this mode until a buffer is ready then turn the clock up (still continuously sampling) and process the buffer.

    Blair
  • 0 in reply to Blair MacDonald
    TI__Mastermind 26780 points

    Blair,

    OK, thanks.  I think allowing McASP activity while the PLL is bypassed is probably the issue.  The McASP has separate clocks for the module itself, and for doing TX/RX.  The Module Clock is derived internally, either from PLL0 or PLL1, as shown below:

    So I think the only way to allow the McASP to stay active while scaling PLL0 is to select PLL1 as the module clock.  And then don’t allow scaling of voltage while changing the PLL0 frequency.  You could either disable voltage scaling, or set the PLL1 setpoint to have a voltage as high as that needed for the maximum PLL0 frequency to be used.  The downside here is that you won’t get power savings from a reduced voltage.

    As an experiment, can you try sourcing the module clock from PLL1 (via CFGCHIP3), and disabling voltage scaling (set “Power.scaleVoltage = false;” in the app .cfg file) to see if the timeout goes away?

    Thanks,
    Scott

  • 0 in reply to Blair MacDonald
    Intellectual 610 points
    Scott:

    Does the frequency scaling built into the power module just change PLL0 if you do not change the peripheral setpoint?

    Blair
  • 0 in reply to Blair MacDonald
    TI__Mastermind 26780 points

    Blair,

    PLL0 and PLL1 are scaled independently.  But there is a shared voltage, which is kept as high as necessary for the frequencies chosen for PLL0 and PLL1.

    Looking at my previous response, sorry,  I see I confused things with regard to needing to disable voltage scaling.  The PWRM module will always send out notifications for voltage changes.  But a PLL will only be bypassed if that PLL’s frequency is being changed.  (Not when there is any voltage change.)  So I think the important thing to configure is that the McASP module clock is derived from PLL1 when you are scaling PLL0.  Can you try that?

    Thanks,
    Scott

  • 0 in reply to ScottG
    Intellectual 610 points
    I certainly will give that a try. One question though, when using the power module to scale PLL0's frequency how do I prevent PLL1 from scaling? Is it by just changing the CPU domain setpoint and not the peripheral setpoint?
  • 0 in reply to Blair MacDonald
    TI__Mastermind 26780 points

    Yes, just by changing the CPU domain setpoint, and not the peripheral domain setpoint.

  • 0 in reply to ScottG
    Intellectual 610 points
    OK this seems to be working now and I am able to change the setpoint in my own version of the idle routine and I get some significant power savings so it seems to work as advertised, thanks.

    One thing I'm seeing is that I get the system aborting when I make changes to the McASP setup structures with no indication of what the error is. I've single stepped through and found that the error happens when calling GIO_reclaim with the following call GIO_reclaim(outStream,(Ptr*) &xmt, &size, NULL). I'm guessing it has something to do with my McASP setup, but it seems to work when I had the word width set to 20 bits and fails when it is set to 32 bits. Any suggestions on how to debug this?

    Thanks,
    Blair
  • 0 in reply to Blair MacDonald
    TI__Mastermind 26780 points

    Blair,

    OK, thanks for reporting back.  I'm glad to hear it is working, along with significant power savings!

    For the new problem with GIO_reclaim()… no, nothing obvious comes to mind regarding the 20->32 bit change, or any specific suggestions for debug.  If as you debug into this you have questions, please open a new forum thread for those.

    Thanks,
    Scott