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.

TMS320F28379D: SDFM’s wrong behavior under Manchester coding

Part Number: TMS320F28379D


Hello,

I too have observed weird behavior from the manchester decoder of SDFM.

TI has recently announced that they do not recommend using this module as a response to Moonhyun‘s question which is available if you search “SDFM weird bevahior”.

But is that it? That recommendation simply causes my company hundreds of thousands of dollars in losses.

We have designed converters using this module for years and now our clients are not accepting the designs because TI is not recommending it.

This is a production MCU not a test MCU and TI is responsible for issues such as this.

We will have to take legal actions now.

Regards

  • * we will have to take legal actions to defend ourselves now.

    We have claimed reliability and signal integrity in our deliverables. However, that post that shows TI is mentioning that they do not recommend this configuration is causing us issues.

    Now, if TI really believes that having a non-integer ratio can solve this issue, at least they should say they will recommend Manchester coding under non-integer clock ratios so that we won’t have to redo everything for our clients except for a software update.

    Voltage sensing is the core of any power converter. So having a “non-recommended” circuitry is unacceptable by all of our clients.

    Has anyone else dealt with this issue?

  • Shamsi,

    The recommendation to use Mode 0 instead of Manchester mode in new designs is intended to caution users about the noise sensitivity of a Manchester stream.  Some users are not as experienced in avoiding noise and signal integrity issues and a few have run into issues similar to the first one indicated in the advisory:

    • Any single noise event on SDx_Dy can corrupt the decoded Manchester clock and cause subsequent data to be sampled at an incorrect frequency.

    For existing designs like yours that use Manchester mode, there are workarounds available in the advisory to implement Manchester mode in a manner that that should avoid potential problems:

    • Avoid any noise on the Manchester bitstream and avoid integer multiples of SYSCLK for the selected Manchester clock source. A precision clock source for the modulator and this device must be used.
    • Ensure rising and falling edge delays (high and low pulses) are within one SYSCLK of each other in length.

    If you properly implement these workarounds, using Manchester mode should be acceptable in your application.

    Best regards

    Manoj

  • Thank you for this confirmation.

    We have implemented all the recommendations.

    Regards,