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

McASP RPS, etc

Flamingo
Expert 2290 points

If I'm running Xmit and Rcv synchronously off the xmit clocks, frame sync, does it matter what I set the fields in RCLKCHK to? If so, and my xmit clocks are all derived from AUXCLK, then I don't understand the RPS description, which seems to suggest that RPS is the divider *from the McASP system clock (SYSCLK2?), but it doesn't describe what "check prescalar" means. It seems that it will be used to determine a receive clock error, but I'm not sure how.

I suppose I'd like know 1) do I care if I'm running synchronously and 2) how is it used (whether I care or not).

 

  • 0
    TI__Guru 62975 points

    Flamingo,

    RPS and other settings in RCLKCHK are used to sanity check your receive reference clock (See SPRUFM1 Section 2.4.7.6).  I believe that it applies even if you are sourcing your clock internally.

    -Tommy

  • 0 in reply to tlee
    Expert 2290 points

    Yes, but in the case of the other fields, I understand the comparison that is being made. In this case, my xmit clocks are divided down versions of AUXCLK, but the description wants me to provide a prescaler for the system clock. The only system clock associated with McASP is SYSCLK2, which on my system is 150 MHz (300/2). My AUXCLK (from wich all my xmit clocks are derived) is 24 MHz. So, what specific check is made with RPS to determine if there is a failure. If the "system clock" it is referencing is the 150 MHz clock and the available dividers are powers of two (1 through 256), then none of those is going to define my 24 MHz clock. So, first question: is system clock = SYSCLK2? second question, what is sysclk/rps compared to and which sense of the comparison causes a reported error?

  • 0 in reply to Flamingo
    TI__Guru 68920 points

    Flamingo,

    First, the clock check circuits are there to provide you with the ability to sense a disturbance on an input clock and take action quickly in cases where it makes sense.  It's an optional feature - you can use McASP happily without ever turning on the RXCLKCHK function.

    A typical use case would be when your receive clock is being generated by a clock recovery PLL and maybe this has become unstable due to poor signal quality.   Or maybe the input has changed and data is coming in with a different sample rate.  The clock check circuit is just one way to detect this change, and it's built into the McASP so it can be useful in the sense of providing software that's not too tied to external devices.

    Ok so that much said, to understand RPS you should probably look at  Figure 33 of http://focus.ti.com/lit/ug/sprufm1/sprufm1.pdf.

    What this circuit is doing is just taking the external McASP AHCLKR and measuring 32 of these periods against an internal reference clock.

    In this case the internal reference clock is SYSCLK2 with an optional prescaler.  You need the prescaler to keep the counts within the range of 8-bit counters when the AHCLKR input is much slower than SYSCLK2. 

    This RPS would be useful in case AHCLKR is something like 12MHz but SYSCLK2 is 150MHz. 

    If you work the math in this scenario, a 12MHz input clock has a period of  83ns.   A 150MHz SYSCLK2 clock has a period of 6.67ns.

    32 AHCLKR periods would be nominally 32 * 83ns = 2.656us = 398 * 6.67ns.

    In other words, the counter running at SYSCLK2 would overflow 8 bits during the course of 32 AHCLKR periods, since the count would get to 398 which is more than 255.

    The solution would be to set the RPS to /2, in which case the normal count would be 398 / 2 = 199.

    Now, you might set RMAX and RMIN to 199 -/-5%  - so you could be notified if the input clock ever changed by more than 5% off nominal.

    In other words RMIN is 189 and RMAX is 207.   As long as the input clock AHCLKR stays close to 12MHz then you should get RCNT values close to 199 (with RPS set at /2) and no error.  But if the clock changed to 24MHz abruptly, then RCNT would peg at 255 and this would compare as greater than RMAX, and you could get an error interrupt or decide to mute in hardware.