• State Resolved
  • Locked Locked
  • Replies 20 replies
  • Subscribers 97 subscribers
  • Views 3120 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.

[Primus, McASP] Unexpected Frame Sync Error

Naoki Kawada
Guru 19890 points
Other Parts Discussed in Thread: DA8XX

Hello,

I have asked the questions about the detail of McASP Unexpected Frame Sync Error from my customer.
I'm sorry to have troubled you so much, but this is very critical issue, so I hope you could answer very soon. 

     First of all, please let me explain some backgrounds.
My customer is using some McASPs in their system. And they has a trouble with McASP2 (Rx) Frame Sync Error. As for other receive McASP ports, there is no unexpected frame sync error. The audio samples captured from McASP2 finally go to McASP0 Tx. So this error can result in pop noise in their system.
In order to fix the problem, my customer need to know the details of unexpected frame sync error.
     McASP2 has been configured to be clock slave (both bitclock and frame sync are input to DA810). These clock transition time is around 25-30ns. Datasheet says, upto 10ns is recommended for any clock transition time. I know this is not good, but unfortunately, It is difficult for them to have faster transition. Also, the direction of clocks can't be changed to have faster clock transition, i.e, McASP2 can not be a clock master in their system. Please note, the device revision is Rev.D. (In the previous revision, McASP is very sensitive in noise, but this issue has been revised on Rev.C or later. So, this errata should not be applicable)

    As for McASP unexpected frame sync error mechanism, I've understood as below.

  • McASP Rx starts to capture audio sample with bit clocks when detecting active frame sync.
  • McASP Rx is working on the current frame. McASP Rx expects the next frame sync just after McASP receives the number of pre-configured bit clocks. At the completion of receiving bit clocks, If McASP could not find the next frame sync, the unexpected frame sync error can happen.
  • The unexpected frame sync error is also expected if something noise (or glitch) is in the active clock transition on either bit clock or frame sync. The transition between VIL and VIH should be always monotonic.

Is my understanding correct, right ? Under the above understanding, I (My customer) have some questions:

  • Q1: I seem Datasheet (see, McASP Electrical Data/Timing) says that the active edge of frame sync is detected around Vref and it will be latched with the next active bit clock. So, the detection logic is not actually edge detection, i.e., McASP is detecting an active frame sync edge and after that validating the its level. Is my understanding correct ?
  • Q2: My customer is trying to find glitches on bit/frame clock, but they have not been able to capture that with oscilloscope yet. Do you have any idea to capture the glitch ? For example, using oscilloscope with a trigger of AMUTE output (error signal of unexpected frame sync error), using embelope mode, etc.. Any idea would be helpful. Also, which part of waveform should be focused on ? The transitions of bitclock and frame sync ?
  • Q3: Unexpected frame sync error is happening on McASP2 only. Do you think McASP2 is especially noise sensitive ?
  • Q4: How much level of glitch is allowable to get McASP2 worked without unexpected frame sync error ?
  • Q5: Is there any noise filter in McASP to make incoming McASP clock clean ? 

If you have any questions, please let me know.

Best Regards,
Kawada

 

  • 0
    Guru 19890 points

    Additional questions ...

    • Q6: How had TI verified the fix of the errata (2.1.3 Clock Input Buffers Updated for Noise Immunity)? In other words, how much level of noise can be allowed on Rev.D device (similar question with Q4)
    • Q7: Datasheet says Vref is always 1.65 V. Do you think this is always fixed to 1.65V when DVDD is moving around its operating condition ?

    Best Regards,
    Kawada

  • 0
    TI__Mastermind 43660 points

    Hello Kawada,

    Yes, your understanding about the frame sync error is correct. For more clarity on this error, please refer below thread.

    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/382507

    1. As per datasheet, your understanding is correct.

    2. How did they confirm there is glitch on bit/frame clock ? I think, the customer can able to capture the glitch using trigger mode in the oscilloscope.

    For your other questions, i need to check with SOC team and get back to you.

    Regards,

    Senthil

  • 0 in reply to Senthilkumar Srinivasan
    Guru 19890 points

    Hi Sethil,

    Thanks for your help. 

    I'll report the current status here.
    We found that unexpected frame sync error had been disappeared with the following HW modifications:

    • I found 24mV non-monotonic waveform on ACLKR2 transition. I thought this glitch should be disappeared in DA810 internal logic (IO Buffer internal) because DA810 had 160mV input hysteresis (V HYS) in IO Buffer. But just for trial test, they tried to improve ACLKR2 transition time and it is now 10ns. As a result, the problem has been disappeared. Please note this HW modification is just trial test. so I'm not sure this is really applicable to their HW design for mass-production.  
    • They are using external clock (not xtal) for OSCIN. Its transition time was around 6ns, but they tried to improve its through-rate to be faster (now it is 3ns) because datasheet says that -- Maintaining transition times as fast as possible is recommended to improve noise immunity on input signals. As a result, the problem has been disappeared also without the improvement of ACLKR2 transition time. 

    Now, additional questions:

    • Considering the above, I'm wondering if the root cause is something noise in DA810 (internal of IO Buffer). What do you think of this ?
    • Datasheet says faster transition of OSCIN improves noise immunity on "INPUT SIGNALS". What is INPUT SIGNAL ? ACLKR2 input is also considered as INPUT SIGNAL ?
    • Do you have any other ideas to to be robust for the noise ? Minimal HW changes will be preferred if they apply your ideas to their product.

    I'll visit my customer tomorrow. So your quick response will be appreciated. 

    Best Regards,
    Kawada

  • 0 in reply to Naoki Kawada
    TI__Mastermind 43660 points

    Hello Kawada,

    First of all, they must adhere to all the design requirements like clock transition time. The workarounds that you mentioned clearly proves that if you violate the datasheet requirements, you are getting into the frame sync error. So i would suggest them to follow the design requirements provided in the data manual.

    Answering your questions,

    1. This scenario is likely due to the noise in IO buffer. I am not sure the McASP2 IO buffer is noise sensitive, but i would recommend to follow the other suggestions to improve noise immunity.

    2. Yes, faster transition of OSCIN will improves the noise immunity on ACLKR2 too.

    3. It is better to keep the clock transition time faster as mentioned in the data manual.

    Regards,

    Senthil

  • 0 in reply to Senthilkumar Srinivasan
    Guru 19890 points

    Hi Senthil,

    Thanks for your reply. I understand your comments, but please let us ask you more.

    Today I visited the customer and I could see the glitch (100mVpp or so -- relatively, big glitch I think) on ACLKR2 transition between VIL and VIL (on a set without HW modifications discussed previously). 
    Datasheet says that the typical V_hys is 160mV.  So, this glitch might be a problem.

    Well, this issue is happening on only few HW.
    Strictly speaking, I believe V_hys value should be different between the input pins. Between devices also.
    So can you define minimum V_hys for ACLKR2 ? Or, do you have any estimated value for that ?

    Best Regards,
    Kawada

  • 0 in reply to Naoki Kawada
    Guru 19890 points

    Hi,

    Sorry to ask you many things, but I would appreciate that you take into account the serious situation.

    Additional question:

    As I reported you before, OSCIN with faster transition could improve noise immunity.
    Can you briefly explain why this can happen ? My customer would need to explain the reason to their end customer in order to apply this workaround.

    Best Regards,
    Kawada

  • 0 in reply to Naoki Kawada
    TI__Mastermind 43660 points
    Hello Kawada,

    The nominal value for V_HYS is defined as 160mV in the datasheet and there is no estimated values available for its minimum value. Again i would insist them to follow the recommendations to get rid out of this issue.

    Regards,
    Senthil
  • 0 in reply to Senthilkumar Srinivasan
    Guru 19890 points
    Hi Senthil,

    Thanks for your reply.
    Ok... so you are saying 100mV glitch may be a problem, but may not be a problem because TI does not have/verify minimum value for V_HYS. Correct ?
    How about the mechanism of OSCIN transition time for noise immunity ?

    Best Regards,
    kawada
  • 0 in reply to Naoki Kawada
    TI__Mastermind 43660 points
    Hello Kawada,

    Yes, your understanding is correct.

    Regarding OSCIN transition time, i am not sure on which perspective we provided this information in the data manual. I will check with the SOC team and get back to you.

    Regards,
    Senthil
  • 0 in reply to Senthilkumar Srinivasan
    Guru 19890 points

    Hi Senthil,

    Thanks for your reply.

    My customer is now saying that there was a possibility that 100mVpp glitch was caused by attaching the oscilloscope probe to their HW... So, actually, there may not be such a big glitch on the clock transition. I'm sorry if we gave you some confusions...

    As for OSCIN transition time, I'm waiting for your response. 
    I'm sorry to have troubled you so much, but I have another question about unexpected frame sync error, especially for "Late" unexpected frame sync error :

    TRM defines Late frame sync error as below:
    =====================================
    Late: A late unexpected frame sync occurs when there is a gap or delay between the last bit of the
    previous frame and the first bit of the next frame.
    =====================================
    So, how much gap/delay between the last bit of the previous frame and the first bit of the next frame is allowed ?
    As I reported you before, having only faster clock transition of ACLKR2 can fix the problem. I'm wondering if the delay might be smaller by having faster clock transition. 

    Best Regards,
    Kawada

  • 0 in reply to Naoki Kawada
    Guru 19890 points
    I'm asking you many things on this thread. I'm very sorry for that, but what I would like you to understand is our final goal is to have logical explanations to go with workarounds (having faster transition in audio clocks and OSCIN -- HW modifications are required). The investigations they tried implies that the noise (IO buffer internal) is one of possible scenario for root cause. I would like you to explain why Primus can be robust against the noise for unexpected frame sync error by applying the current workaround.

    I'd so appreciated if you would take into account our background when you answer to our questions. Of course, I understand 10ns or faster transition is your spec and requirements for the proper device operation. But it would be great if you could explain the background for that.

    Please note, as for the question about "Late" unexpected frame sync error I mentioned in the previous post, this is just a confirmation to do further checking/debugging on their HW.

    Best Regards,
    Kawada
  • 0 in reply to Naoki Kawada
    TI__Mastermind 43660 points

    Hello Kawada,

    The OSCIN input buffer noise margin is about 300 mV. The noise margin on this input is a function the input buffer hysteresis, the slew rate of the input signal and the performance of an internal glitch catcher circuit on this input. The lower voltage of this input reduces the available hysteresis and the slow slew rate when using a crystal further reduces the noise margin. When an external clock input with faster rise/fall times is used, the noise margin improves. With 3 ns, rise/fall times, the noise margin improves to about 600 mV. This improvement is present whether the input oscillator circuit is configured in oscillator mode or external clock input mode.

    We do want fast transition times on any input clocks.  The faster a clock edge is, the more noise-immune it is; one way to look at it is that if the edge happens very quickly, then a noise spike has less of an opportunity to affect the transition region of the edge. Any input clock (not just OSCIN) is susceptible to noise if the transition times are not met, but glitches on OSCIN will cause the entire device to be susceptible, where is glitch on McASP inputs might cause issues localized to McASP only.

    Regards,

    Senthil

     

  • 0 in reply to Naoki Kawada
    TI__Mastermind 43660 points

    Hello Kawada,

    I got response for some of your earlier questions.

    Q3: Unexpected frame sync error is happening on McASP2 only. Do you think McASP2 is especially noise sensitive ?

    There is no reason to think that McASP2 is particularly noise sensitive.  Perhaps there are more noise sources on that board near ACLKR2 than other McASP pins.  Perhaps that part of the board isn’t as well grounded as others (gaps in the ground plane, etc).  There are many possible factors.

     Q4: How much level of glitch is allowable to get McASP2 worked without unexpected frame sync error ?

    The clock edges need to be monotonic, with transition times as specified in the datasheet.  We do not specify an allowable amount of noise.  There are measures in place (hysteresis, etc) to counteract the effects of noise that may occur unexpectedly, but these measures are not designed to counteract the effects of clock edges that are non-monotonic. 

    Q7: Datasheet says Vref is always 1.65 V. Do you think this is always fixed to 1.65V when DVDD is moving around its operating condition ?

    As the datasheet says, all I/O timing parameters were referenced to Vref, where Vref = 1.65V for 3.3V signals.  This refers to how our timing parameters were measured.  It is only a reference point for this specific scenario. DVDD should be set to 3.3V; the min and max spec for DVDD is made to allow for power supply variations, but the idea is always to design for the nominal spec.

    Considering the above, I'm wondering if the root cause is something noise in DA810 (internal of IO Buffer). What do you think of this ?

    Usually clocking errors like this will be due to either noise on the incoming clock itself, or ground noise, which can affect the input buffer itself.  In those cases, you may not see an apparent glitch at the pin, but the I/O buffer can experience the glitch.  It’s possible.  Regardless of whether the noise is induced onto the clock at the I/O buffer or before it hits the device pin, a faster input clock edge will improve noise immunity.

    What is INPUT SIGNAL ? ACLKR2 input is also considered as INPUT SIGNAL ?

    An input signal, in this context, is any signal driven into the DA8xx device.  If a clock is being driven into ACLKR2, then it is an input signal.

    Do you have any other ideas to to be robust for the noise ? Minimal HW changes will be preferred if they apply your ideas to their product.

    As we mentioned before, edges MUST be monotonic and under 10ns in duration.  One way to get faster edges would be to reduce the value of the series resistor on ACLKR2. Sometimes customers over-terminate and slow down their edges excessively.  If you make that resistor smaller, your edge will speed up, but they need to look and make sure that the edge still stays clean.  Those resistors are there for impedance matching; if they reduce it too much, then they could end up with reflections and a distorted waveform.  This is probably the only way to do it without actually changing the board design. If they plan to actually revise the board layout, then we can offer some other suggestions.
     
     
    Strictly speaking, I believe V_hys value should be different between the input pins. Between devices also. So can you define minimum V_hys for ACLKR2 ? Or, do you have any estimated value for that ?

    No.  In general, almost all of the input buffers are of the same design and will have similar Vhys characteristics.  The typical value is all that we can offer.

     

     Regards,

    Senthil

  • 0 in reply to Senthilkumar Srinivasan
    Guru 19890 points
    Hi Senthil,

    Thanks for your answers.
    As for our earlier questions (Q3, Q4 or something) , I understood.
    Please let me clarify OSCIN noise immunity again to understand your points correctly.
    I tried to summarize your points as below. Is my understanding correct ?
    ============
    Considering the primus design, it is important to understand that the glitches (noise) on OSCIN (external clock) can cause the entire device to be susceptible (But TI does not have any data for that) .
    In general, the faster slew rate (and monotonic waveform) on any clocks can be robust against the noise during its transition time. This is because the noise peak can be invisible as a waveform when using higher slew rate.
    The OSCIN (external clock) input buffer noise margin is typically 300 mV. This value is actually achieved by input buffer hysteresis, the slew rate of OSCIN (external clock) signal and performance of internal glitch catcher circuit. If slower OSCIN (external clock) slew rate is being used, this noise margin can be decreased. In other words, if we go with faster OSCIN (external clock) slew rate, this noise margin can be increased. For example, if we use 3ns slew rate for OSCIN (external clock), the estimated noise margin on OSCIN (external clock) can be around 600 mV. This would be able to filter out the noise from OSCIN(external clock) more. So, McASP2 might be able to work without unexpected frame sync error.
    ============

    Best Regards,
    Kawada
  • 0 in reply to Naoki Kawada
    TI__Mastermind 43660 points
    Hello Kawada,

    Yes, your understanding is absolutely right. So please ask the customer to use the input clock with faster transition time (less than 10ns) as mentioned in the datasheet.

    Regards,
    Senthil
  • 0 in reply to Senthilkumar Srinivasan
    Guru 19890 points
    Thanks, Senthil.

    I'll try to talk with my customer. If I got any update on this, I'll let you know.

    Best Regards,
    Kawada
  • 0 in reply to Naoki Kawada
    Guru 19890 points
    Hi,

    Regarding the mechanism of OSCIN noise immunity, I have answered to my customer. They are now considering this, but a new question has been raised from them... As for OSCVSS, do they need any special care for noise immunity issue ? If you have any guidelines for that, please let me know. For example, OSCVSS needs to be routed to GND as short as possible, or something like that.

    Best Regards,
    kawada
  • 0 in reply to Naoki Kawada
    TI__Mastermind 43660 points

    Hello Kawada,

    There is no specific recommendation on OSCVSS routing length. However you can keep shorter length as much as possible for noise immunity.

    Also please note, when an external crystal is used oscillator (OSCVSS) ground must be kept separate from other grounds and connected directly to the crystal load capacitor ground as shown in the device datasheet (Figure 5.6). These pins are shorted to VSS on the device itself and should not be connected to VSS on the circuit board. If a crystal is not used and the clock input is driven directly, then the oscillator VSS may be connected to board ground (Figure 5.7).

    You can also refer the below link for OSC circuit recommendations.

    http://processors.wiki.ti.com/index.php/OMAP-L13x_/_C674x_/_AM1x_Schematic_Review_Checklist

    Regards,

    Senthil

  • 0 in reply to Senthilkumar Srinivasan
    Guru 19890 points
    Hello Senthil,

    Thanks for your quick reply. Ok, I'll suggest the same to my customer.

    Best Regards,
    kawada
  • 0 in reply to Naoki Kawada
    TI__Mastermind 43660 points

    Hello Kawada,

    Please help to close this thread by clicking Verify Answer button.

    Regards,
    Senthil