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.

Compiler/TM4C1294NCPDT: Is there way to generate jitter clock for PSU for reduced EMI

Part Number: TM4C1294NCPDT

Tool/software: TI C/C++ Compiler

Hi

(a) I was wondering if there way for TM4C to generate jitter-able clock output to keep EMI low, for example, +/-5% variation on say 300KHz or 1MHz (for SEPIC PSU). 

(b) I'm going to use 16MHz XTAL into TM4C and boost system clock to around 100MHz or so (it early stage). I like to add small jitter again to keep EMI low. Bear in mind the USB will be connected to embedded Window 10 module. What the best way to do this?

Thank in advance for your consideration. 

  • the answer depends on a lot of other factors, like how the waveform is to be generated, what kind of resolution do you need, ...

    typically you do it via a pwm / ccp block. say that you run your clock at 80Mhz and want 8-bit pwm resolution, that leads to an output frequency of 80M/256 = 300Khz, give or take. you can alter the top. if pwm is used, your resolution is limited to 2/256 = 1%, assuming 50% duty cycle. or you can toggle the ccp pins.

    other ways are also possible. but you have to figure out first what approach you want to take.

  • Hello Richard,

    I think Danny's comments are on point regarding your (a) question. In general timer/PWM is used for that, though if it would work for you would depend on your requirements.

    For the (b) point, I am not really following your train thought. Are you wanting to inject jitter into the 16MHz or 100MHz signal...? The wording is unclear on that. All I can glean is you want to keep EMI low, so along that train of thought, have you done tests and found unsatisfactory results or are you trying to design the board well to ensure low EMI?
  • I decided to give it a try and see how much time it would consume to "randomize" a 32-bit period variable.

    here is the strategy I had:

    		pr +=lfsr32()?(+1):(-1);
    		if ((pr >= PR_MEAN + PR_DELTA) || (pr <= PR_MEAN - PR_DELTA)) pr = PR_MEAN;
    

    PR_MEAN = 1000 and PR_DELTA = 50.

    On a LM3S / Keil, it took anywhere from 10 - 30 ticks to execute that strategy.

    I used a typical LFSR-32bit algorithm, of unknown quality, so I had to guard against the possibility of bias. if you are confident in your randomizing strategy, you may get away with the "if" statement all together.

    Not bad a 5-min work.

  • Thank Danny for this, I believe this is what I'm looking for Timer clock to jitter the PSU frequency as to reduce EMI, which spread spectrum. Again I appreciate for this nice work :-).

    I'm designing the schematic and layout later on for low EMI solution, one method is having random jitter on 16MHz clock into TM4C would mitigate EMI issue later on. I have not found IC clock device that done that yet, but I used it in the past (9 years ago). The PPL within TM4C would follow the 16MHz jittered clock to 80 or 100MHz so I need to take care not to have too much jitter that might impact USB operation (which I'm concerned about).

    I have not tested TM4C for low EMI, I have not seen proof that it is low EMI device which is the reason for this precaution.

    R. 

  • Hello Richard,

    Not sure exactly how low you need to be on EMI, but if for example you are wanting to test it against EU standards and such, the TM4C with proper hardware design will pass such tests. If you have some extra requirements outside of the usual international standards, then I'd suggest perhaps first testing one of our well designed dev boards like the DK-TM4C129X and see if the results are sufficient for your needs.

    In general for designing your schematic and layout to minimize EMI, you should very religiously follow our Design Guidelines document. This is the best way possible to minimize EMI, and many customers have had great success when following it: http://www.ti.com/lit/an/spma056/spma056.pdf

  • " one method is having random jitter on 16MHz clock into TM4C would mitigate EMI issue later on."

    that sounds different from using TM4C to generate a jittery clock OUTPUT.

    if you are looking to minimize EMI on clock INPUT, many of the oscillators produce (clipped) sine wave output, for that purpose.

    or we totally mis-understood you?

  • I'm SO glad that this attempt to, "Jitter the 16MHz, Input MCU Clock" has received notice.

    Does this not complicate & confound ALL Timing Efforts - throughout all aspects - of poster's MCU?

    And - have there not been reports of  "certain" MCUs "Requiring time to Regain PLL "Lock" - when the input frequency is "disturbed?"      What then?     (poster marches quickly/confidently - into the "unknown!")

    Generating the (external) Sepic Supply's clock - via changes to an MCU's Timer Values (NOT its PWM (duty-cycle) values) is easy & agreed - "Hopping the MCU's Clock Input" (may) prove a vastly, "Different Story."

    Reducing EMI is a noble objective - but ONLY if the "original design objectives" are (somewhat) maintained! (usually a stable - and known - System-Clock Frequency IS required...)

  • Hmmm interesting point......I guess the PPL rely on certain stable reference for stable system clock, ie from 16MHz jitter XTAL to (say) stable 100MHz via PPL or so, which may defeat the low EMI purpose. This has not occurred to me and would be wasted effort if this is the case. I guess the 16MHz XTAL would be more noisely on PCB layout than internal 100MHz due to much smaller footprints.

    I lack real proof that TM4C on certain PCB (4-6 layers) is a low EMI which is why I put in precaution solution and then use BOM variant to fit or not to fit EMI mitigation solution. Even though TI claim there no issue with it based on customer however my experience that they would naturally tend keep thier achievement secret under NDA as they not willing to share invested time and money with other.
  • Meeting "Regulatory Agency" requirements is not always "easy" - and almost never "quick!"

    As earlier written - "frequency hopping" this MCU's HF clock input may well place you in, "uncharted" (surely sparsely charted) territory.     Now it (may) work - would it not prove "Quick/Dirty" to, "Yank the external xtal from your targeted MCU's "LPad" - and then "cobble in" your "hopping device?"      (and then, "Stand far back" - (12" cinder-block wall)  between you & this "hopping MCU" (just may) suffice)

    Do realize - any/all of your "System Clock Based" calculations will be challenged - and regular/repetitive "reads of SysClock frequency" may "Fail @ the very next "hop!"

    Twas me - I'd test that your MCU ... "Can STILL perform" (even) when "hopped up."      If it can - then & only then would I visit a "reduced cost" EMI lab - and see, "Where you stand."

    Note that, "even if - and especially if" - you can "Coerce the MCU into EMI compliance" - the impact of your Sepic Supply's EMI addition - must be considered.    (how Brutal if (that) causes EMI failure!)

    (is this guidance not the equal of those (earlier posts) - awarded Green?)

  • Hello Richard,

    richard payne said:
    Even though TI claim there no issue with it based on customer however my experience that they would naturally tend keep thier achievement secret under NDA as they not willing to share invested time and money with other.

    I don't want to (and can't) speak for TI as a whole, but for our group specifically that is untrue. Our design guidelines are based on the designs for our own hardware boards which have passed through EMI testing including the latest tests from the updated EU standards which are the most stringent to date. We are very open about sharing what precautions you need to take to ensure that our TM4C devices will not cause any customers issues with EMI testing per international standards such as those mandated by CE compliance.

    Again if you need proof... purchase one of our EVM's and see for yourself.

  • Hello Ralph,

    I know you to be caring & truthful - surely you, "believe that which you list, here." That said - would not your (and the firm's case) be substantially strengthened - by simply, "Presenting those latest test results" - especially those performed under updated EU standards?

    It is (sometimes) possible to, "Just squeak by" such test - and other times - to pass w/"flying colors!" Clearly the publication of such test results would do much to reduce this poster's (and others') concerns.

    It should be noted that the MCU - by itself - is never tested - it is the client's "integrated work product" - which expands upon the Eval board - and argues (even more loudly) for the disclosure of those, "Passing EMI Test results."     The listing of the passing, "spectral analysis" provides the "best proof" - does it not?

  • Hello cb1,

    I haven't heard of a case that we share the actual test results. As of late, we do release DoC's like: www.ti.com/.../sszq113.pdf which was recently released/updated to reflect the latest testing done.

    I understand that presenting the test results would ease the burden of proof, but our DoC is still pretty clear. The device with proper design will pass. That is the best guarantee we can give, given that, as you know, we are not in the business of personally designing boards for customers.
  • Beyond, "easing the burden of proof" - such test results often serve a highly useful purpose - that being the identification of, "spectral areas" demanding "special consideration."

    While every case (usually) proves unique - forewarned is forearmed - and the publication of such test results can be expected to, "Aid your client-users..."