• State
  • Replies 3 replies
  • Subscribers 83 subscribers
  • Views 110 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F28379D: AMC3306 SDFM Corrupted Data

Noah Martin
Prodigy 180 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: AMC3306M05, LMK1C1103

Hi,

We are evaluating the AMC3306M05 and we seem to be having issues with noise in our control loop when it is recovered from the TMS320F28379D MCU at certain duty cycles, or the current changes directions. We are using our ePWMs to synchronize our sensing and have a compare value set to approximate the latency of the SINC2 OSR128 filter we are using. We are using the SDFM Qualified GPIO 3 Samples option hoping to remove glitches, but it has not impacted our situation. We have looked at the data visually w/ a 500MHz Optically Isolated Probe and cannot see any substantial fluctuation in the data input to the TMS320F28379D waveform. However when the signal is filtered through the SDFM we receive a step response in the signal.

I posted this to the SDFM forum, and the observation was that the AMC3306 is working as intended. I have checked my gate signals on the switching bridge and that also does not seem to have an impact, they are seeing the step response read by the MCU SDFM Input. (See thread: https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1589906/amc3306m05-q1-sdfm-data-glitch-occuring).

How would we be able to determine if we have a glitch related to timing violations vs noise on the input of the CLK/Data? Are their any suggestions to verify the SDFM is faulted?

image.png

  • 0
    TI__Expert 4940 points

    Hi Noah,

    You have mentioned that you looked at the “data and cannot see any substantial fluctuation in the data input”. Can you also probe the clock right at the MCU pin?

    SDx_Cy directly clocks the SDFM when GPIO async is used, and ringing that cross VIH/VIL can corrupt the SDFM and cause unpredictable results. This can show up as a sudden step in the filtered output because a single extra/missing clock edge effectively “bit-slips” the decimation stream.

    Also, make sure the PWM is free-running (not a clock that can be momentarily disturbed by duty-cycle updates or sync events elsewhere).

    Best Regards,

    Masoud

  • 0 in reply to Masoud Farhadi
    Prodigy 180 points

    Hi Masoud,

    Here is the data from the SDFM DOUT. We looked before the filter of the MCU and as you can see the voltage in yellow is slowly decreasing as would suspect because the phase current is decreasing. Then when the phase changes which is providing power the glitch appears, but the DOUT data appears clean and uniform as shown in the MEAS9/10

    Image 1  Prior to Jump Cycle: Ch1 DACA PH B Current, CH4-6 Phase Currents, Ch 7 PHB Input to AMC3306M05, CH8 Data Out of SDFM

    Image 2 Jump Cycle: Ch1 DACA PH B Current, CH4-6 Phase Currents, Ch 7 PHB Input to AMC3306M05, CH8 Data Out of SDFM

    We also verified the SDFM CLK yesterday and the CLK appears to be consistent with the input to the LMK1C1103PWR. Please see the attached images of the SDFM CLK. The PWM is ePWM12 and is not correlated to the control loop or the sync'd with any other signal. I do not see any significant oscillations at 25GS/s.

    The LMK1C1103PWR when looking at the datasheets askes for additional capacitance for the number of channels, and does not use a Ferrite bead as specified. We can add this, but again as I previously stated, they do align with the phase crossover points which is where a significant portion of the CM will be generated. Above in first post is the control loop propagation traced back to the SDFM filter. I believe we are very close to the correct sampling time, but our CLA is software triggered right now, and I think it should be ePWM1INT triggered so that the control loop and all other ePWMs are in sync for this application. 

    Image 3: SD_CLKI from MCU and SD_CLKO_B from LMK1C1103

  • 0 in reply to Noah Martin
    TI__Expert 4940 points

    Hi Noah,

    Apologies for the late reply! Many team members are out of the office this time of year.

    What I understand is that you’re not seeing obvious corruption on SDx_Dy with the scope, but you do see intermittent step behavior after the SINC2/OSR128 filter, especially around switching events and current direction changes.


    The SDx_Cy (clock) can corrupt the SDFM even if DOUT looks fine. On F2837xD, the SDFM clock input (SDx_Cy) can directly clock the SDFM module (no internal synchronization in ASYNC mode). The errata explicitly warns that glitches/ringing that cross VIH/VIL on SDx_Cy can corrupt the SDFM and cause unpredictable results.

    Please probe SDx_Cy at the MCU pin (not only at the source) with the shortest ground possible and look specifically for runt pulses / ringing that crosses VIH/VIL during switching edges. This can be very narrow and still be real to the digital input. Also you  can add series termination at the clock driver and keep SDCLK away from high dv/dt nodes.

    The same errata recommends using SDFM GPIO qualification (3-sample) in noisy conditions because it filters both SDx_Cy and SDx_Dy. It also calls out that you must follow the SDFM timing requirements when using qualification datasheet table.

    So if you enabled “Qualified GPIO 3 Samples” but didn’t see improvement, double-check that qualification is actually applied to the pins used for SDx_Cy and SDx_Dy and confirm your SDCLK frequency + qualification settings satisfy the datasheet’s qualified-input timing. 

    If your “synchronize sensing with ePWM” includes using PWM FILRES to reset/synchronize the SDFM data filter, there is an errata item: a spurious data acknowledge (AFx) can occur before the filter settles. The workaround includes ensuring the CPU/CLA interrupt occurs ≥ 1.2 µs after FILRES and clearing SDIFLG appropriately.

    Best Regards,

    Masoud