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.

TMS320F28377D: SDFM Mode 2 clocking from MCU

Part Number: TMS320F28377D
Other Parts Discussed in Thread: AMC1306E05

Hello

Recently we have found out that there are some problems with Mode 2 (Manchester code) of the F2837xD SDFM.

As far as i understood from the errata, the main two problems are Noises and Integer (CPU SYSCLK / F_sdclk ), where F_sdclk is frequency of SD clock.

We have no noise in our scheme.

And the clock source for SDFM module (AMC1306E05) is MCU's ePWM output. In this case we have exact integer value of (SYSCLK / F_sdclk).

But since the SDFM is clocked by MCU itself, there should be no drift between SYSCLK and F_sdclk.

Is it a safe way to use Manchester-encoded data?

  • Hi there,

    And the clock source for SDFM module (AMC1306E05) is MCU's ePWM output.

    Can you clarify? In Manchester mode there is no clock output from the MCU to the AMC device. The clock and data are encoded together.  

  • Disregard my previous question, you want to clock the AMC1x device using PWM, but use Manchester mode for data transfer, correct? Are you using the SD1_C1 pin for some other function?

  • you want to clock the AMC1x device using PWM, but use Manchester mode for data transfer,

    That's right

    Are you using the SD1_C1 pin for some other function?

    No, clock pins of the MCU are either floating (NC) or used for another purposes.

    Why do we have such scheme:
    some time ago we were using uncoded AMC1303M DS-Modulator. That one is generating clock by itself, but we had some troubles with EMI, and clock/data edges and etc. Somehow we got it to work.

    But in the next design we decided to try Manchester coded AMC1306E. We wanted to examine how clocking rate will affect overall quality of our measurement circuit. We connected its CLKIN to PWM, so that we could change clock freq manually and ended up with 16.666 MHz (EPWMCLK/TBPRD = 100 MHz / 6). We had good results and never seen any "wierd" behaviour. And at that moment there was no information in the errata.

    Also, i think i should mention, that we use Sinc3 with OSR = 64, and take data from the SDFM output at 32 kHz rate (that's our control ISR frequency). 

  • Thanks for the background on the question.

    Is it a safe way to use Manchester-encoded data?

    Using the PWM to clock the AMCx device will expose you to the issue described in the errata given that the AMCx clock will always be an integer multiple of the Manchester clock source. You would have to use an alternate clock source for the AMCx device if you want to use Manchester mode.

  • Well if i understand the errata correctly, "almost integer" is dangerous because in fact clocking of MCU and some external oscillator for DS-modulator cannot be absolutely equal in practice. Thus, clocks are drifting (or better say "sliding"). That's why the internal Manchester decoding algorithm breaks.

    But if we clock DS-modulator from the MCU, the clocks never drift, because they are clocked, in fact, from the same source (SYSCLK).

    Or do I make a mistake somewhere?

  • If PWM is used to clock the SD-modulator, SD-Cx will be integer multiple of SYSCLK. This condition would match what is mentioned in errata. We strongly recommend you to consider mode 0 instead of mode 2 because of these problems.

    Regards,

    Manoj

  • Ok, thanks.

    I am sure, that there is a reason, why integer multiplies are forbidden. And that reason is in algorithm of mancherster frequency detection inside SDFM. And the algorithm breaks when DS-modulator and CPU are clocked from different sources, because the clocks are drifting along each other.

    But, well, ok. Thanks.