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.

N2HET for spread spectrum PWM

Other Parts Discussed in Thread: TMS570LS0432, HALCOGEN

I can't find a reference guide to the N2HET instructions. The best I found was "TMS470R1x High-End Timer (HET) Reference Guide". Where is the document also covering the N2HET instructions? 

I would like to have upto 10 PWM outputs with spread spectrum of 15kHz +-10% and I'm looking for an algorithm. It also needs to distribute PWM evenly to minimize current ripple in the output stages. Lets say all 10 PWM signals are 50% duty cycle, It would be stupid to have them all on at the same time because it would cause unnessesary current ripple in the output stage. I find this quite challenging. Is there algorithms for spreadspectrum PWM available? Any Ideas how to implement N2HET spread spectrum PWM?

  • Hello Henrik,

    The N2HET instruction set is included in the N2HET chapter of our technical reference manuals. I will look for an example algorithm for generating spread-spectrum PWMs using N2HET and post it here.

    Let me know if you have trouble locating the N2HET instruction set.

    Regards,
    Sunil
  • Hi Henrik,

    This is just a hint how this could potentially be implemented.

    Assuming a left aligned PWM with only an up counter, than you could go and modulate the max value and thus the PWM period time.

    This method has the disadvantage that you would need to have to modify not only the max value, but also the compare value to keep the duty cycle steady.

    Another method would be to implement coulters which are operating on a different increment than 1 per loop.
    For example you could consider to increment a counter by 100 in each loop.
    If you now modulate the counter increment by just alittle (e.g. +- 10 increments) you would end with a PWM with a modulated period time.

    The advantage of this method would be, you just would need to have to modify the increments. Disadvantage is that you can't use a simple compare for the duty cycle and period, instead you need test for equal or greater, which should be possible with N2HET.

    However, with both methods you might end up with a jitter in your duty cycle (percentage wise).

    But let's see with which solution Sunil will come up.

  • N2HET can do multiplication - through a series of add w. shift - one of the instrutions we added going from NHET to N2HET.

    N2HET also can perform XOR /shift which should be useful to implement an LFSR for psuedo-random number generation.

    And it is now possible to implement a sort of 'subroutine' for a multiplication kernel - to keep the memory usage down.

    You can first update the branch target of the 'return' instruction of your subroutine using the remote=REMP option on a MOV,

    and setting the NEXT address to the start of the routine.

    We've got code on the forum for a completely arbitrary period/duty cycle PWM - with high-resolution on both the period and duty cycle.


    So in my mind the pieces are all there but it's a question of whether the modulation itself can be calculated on the N2HET in the time allotted.

    This is where N2HET would become valuable....   because otherwise if you do all the computation on the CPU during every period, then any timer

    could work.

    What I think we need to know then is:

       - how many PWMs

       - what center frequency

     

    And we should be able to estimate the feasibility of a self-contained N2HET program to do the job.

  • As I said in my first post I'm interested in 10 pwm outputs running at a center frequency of 15kHz.

    And as I also said, I need to keep the "power factor" fairly even over time. I can't have 10 pwm fully on and later in that cycle have them all off. That could cause high current ripple that my power rail capacitors can't take. So there must also be some logic to shift a PWM in time to spread the power more evenly.  So there are a few instructions (don't know how to approch this yet)..

    It's one more thing, I need to add a "dither" signal on each output, with adjustable frequency and adjustable amplitue (70-400Hz). It would also take a few instructions...

    It would be really good to know if it's feasible before I start, so I don't start learn N2HET in vain.

  • Henrik,

    So with a center freq of 15KHz the period is 66.7us. Let's assume 60us for a min by the time you spread-spectrum.

    From the start of a 60us period - would you have the entire 60us to compute the on/off points for the next period? Or do you need to wait say
    to mid-period or 3/4 period before you start computing the next period's on/off points (in case the CPU is recomputing the duty cycle..)

    Would a fixed sequence among your PWMs be ok? i.e. if you spread their start/end of period evenly ... by about 6us each would something that simple solve your high peak current problem?

    Do you need your duty cycle to run 0 to 100%? or can it come close - let's say instead of 0% you had a min on time of 20ns and your max on-time were period - 20ns?

    Last - can you pick an adjustment and let it run say for 2 consequitive periods to double the amount of time available for computation?

    Here's what I'm thinking off the cuff:

    If your PWM period is ~60us then your period is 6000 counts of the N2HET clock at 10ns (unless you are using an 0432/0332/RM42..).

    So in terms of resolution you've got about 13 bits.

    If it takes ~5 cycles / bit to multiply (guesstimate.. shift into carry, branch based on 0/1, add if '1'.. ) - that's 65 cycles per channel or 650 cycles for 10 channels. So there's time to compute all the periods as a fraction of a modulated period if you have the whole 60us to do the work...

    Then if you figure something like 20x10 cycles might be needed to randomize the period of each channel, and another 20x10 cycles to calculate on/off points that are staggered - you still probably have time within the ~60us window; unless you need to accept a new duty cycle input from the CPU near the end of the current PWM period and have it apply on the next period.

    If you know ahead of time that you have as a fallback:
    1) the ability to split the PWMs 5&5 across the 2x N2HETs (again assuming this isn't one of the 0432/0332/RM42's with only 1 N2HET).
    2) the ability to be flexible and update every other PWM period - thus doubling the compute time...

    Then I would be very bullish and say go for it.

    If you don't have either of the above, but have the full 60us then I'd say that it would still have a high probability of feasibility but it will take some care to split the calculations over multiple loop resolution periods in order to maintain 13 bits of resolution on your PWM. This is 2nd order type issue - just means you may have to spread your multiplication out for example do 1 bit shift/add per channel / per loop over 13 loops rather than doing all the math at once.. to keep the computation within 128 clocks / loop which is needed for highest resolution on your outputs.

    If you are going to need to take a new CPU input in the last 20% of the period and you have to make sure that this is applied on the very next output period -- then I'd start to question the feasibility unless you have some trick like the ability to split the task over 2 N2HET instances...

    Those are my thoughts on feasibility - if your use case comes out in the 'likely feasible' we can talk about how you might start off w. the N2HET IDE to prototype this.

    -Anthony
  • I have only on N2HET (TMS570LS0432) and running on 80MHz. I assume that would give about 12bit resolution and that is more than enough for my application (I can also add some resolution with the low frequence dither signal, if needed).

    There is really no hurry. I can update every other PWM period or even double that to buy time.

    A period close to 0 and 100% is good enough.

    I don't think shifting the start/end of period evenly by about 6us each would help reduce high current peaks. Lets say four consecutive signals are 50% and the six remaining are 1% then I will have almost 6 ampere ripple. If propely spread, ripple current would be close to 0 Ampare, giving thousands of extra hours for my capacitors. One approach might be to have the CPU calculate a "start slot" for each PWM once in a while or on significant changes to a duty cycle.

    Anthony, you been very helpful here and I now realise this use case is "highly feasible". If you could help me off with some code it would ofcourse be a jumpstart for me and much appreciated.

    Thanks !

    Henrik
  • Hi Henrik,

    Sorry for the delay. I have attached an N2HET program that generates a spread-spectrum PWM output on channel 0. The period varies between 3 and 5 counts, so centered around 4 loop counts. None of the periods are actually 4 loop counts wide.

    Let me know if this is useful, or if you have any questions.https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/312/6761.SSPWM.het

    Regards,

    Sunil

  • Hi,

    I think it could be useful. I have one problem though, I can't get it into the het ide without trouble. Once I have a project loaded with the suggested code the HET IDE starts to consume 40% of my CPU (64bit win8.1) and get really sluggish or unresponsive. What is wrong? I even tried to run it in windows 7 compatibillity mode without success. The het ide consumes about 60-100MB and grows over time, possible memory leak?

    Regards

    Henrik
  • Hi,

    I tried on an old win 7 computer, for some reason working much better.

    Regards

    Henrik

  • Hi Henrik,

    A colleague tried running the NHET IDE on his Win 8.1 machine and did not see any issues.

    Let me know if you have any questions about the HET code itself.

    Regards, Sunil

  • Hi Sunil,

    I've tried reinstall everything, the problem persists. The HET IDE is "idle" with a cpu load of > 40%. I have to close it from the task manager because it unresponsive. I attached a screenshot below.

    Regards

    Henrik

  • Henrik,

    There should be 2 processes related to the HET IDE.  One is HET.exe.   The other is Simulator.exe.    Make sure you stop both processes with task manager after a crash.

    Most likely it's the TCP/IP Port that is used to communicate between the two processes that is the isssue.

    The stock download tries to open a fixed port # but if some other software on your computer is using that port # it hangs.

    We have patched the executables to ask for an open port # and when you run the patched version you'll see something like this:

    Starting the simulator ....
    Simulator Constructed Frontend Interface ...
    Simulator Listening on Port 49627
    Frontend Connected to Simulator on Port 49627
    Clock is set to 9.09091 HET_NS

    Note how the Port # is displayed.  I don't see this in your screenshot - so I think you probably didn't get the patch.

    The patched .exe files are here:  https://txn.box.com/het-patches

    You need to drop them in on top of (replace) the two exe files with the same names in your installation folder.

  • I'm trying to get the patch, but box says the item I'm trying to access has either been deleted or is unavailable to me...Is there some other way I can get the patch?

    Best Regards

    Henrik
  • I had the permission on the share set incorrectly - sorry about that. Please try again.
  • The IDE is now running ok thanks to the patches. Thank you!

    I have one more question. How to get the code from het ide to halcogen? When trying from het ide I get the following error. And no, there is no hetPROGRAM[] in halcogen. het code c file.

    I tried to disable the "black box driver" and selected the hat ide generated c and h files. But...

    hal.h still contains API functions specific to the "black box driver" and my code can't be found in the generated files. 

    Section 9.1 of the het ide guide isn't of much help here! 

    What am I doing wrong?

    Regards

    Henrik

  • Henrik,

    I never use the export to HalCoGen feature of the HET IDE myself - I always pull the .h and .c file from the HET proj. to HalCoGen using the HalCoGen gui.

    The only caveat I have about this is that HalCoGen makes a copy of the .c and .h files when you perform a 'generate'.  

    So it doesn't use the .c and .h files in your het project folder directly.        This just means that if you go back to HET IDE to make a change,  and then want to see the change in the HalCoGen project running on silicon - it's not enough to just rebuild the C code you also have to copy the .c and .h over again.   Either do this manually, automate as a pre-build step in CCS, or run 'generate' again from HalCoGen.

    I don't think you're doing anything wrong w. the headers.   This is how it works unfortunately.  

    You will need to write your own host side support functions for your custom HET program anyway.   You can either insert this in the HalCoGen .h and .c files or create your own.   If you do the former, you can find /* USER CODE */ blocks surrounding the HalCoGen code you want to get rid of, and put  #if 0 in the one before and #endif in the one after, then insert your own code between the #endif and the end of the 2nd /* USER CODE */ block.

    Or you could create your own clean header and c file for your HET driver functions,  and exclude HalCoGen's own files from the build.  You'll probably want to keep the  reg_het.h from HalCoGen because this has the peripheral registers, but lose the other header that has the api's and replace that with your own.

  • Anthony,

    I think there is more trouble with the IDE. I really think you need to check this software. Despite the patch it's consuming CPU and when it crashes it's always  something with the "Qt3Support4.dll" see below.

    Felet uppstod i programmet med namn: HET.exe, version 0.0.0.0, tidsstämpel 0x527d8ac2

    , felet uppstod i modulen med namn: Qt3Support4.dll, version 4.6.2.0, tidsstämpel 0x4b7ce21a
    Undantagskod: 0xc0000005
    Felförskjutning: 0x0011fa19
    Process-ID: 0x65c
    Programmets starttid: 0x01d0ab272a18658b
    Sökväg till program: C:\Program Files (x86)\Texas Instruments\Hercules\HET\HET.exe
    Sökväg till modul: C:\Program Files (x86)\Texas Instruments\Hercules\HET\Qt3Support4.dll
    Rapport-ID: 792344aa-171a-11e5-8272-3413e8227ff8
    Fullständigt namn på felaktigt paket:
    Program-ID relativt till felaktigt paket:

    When booting windows is safe mode and run the IDE:

    I've spent hours trying to make this IDE work. Switching off firewalls, shutting down all other programs, trying different compatibillity modes, reinstalling with different compatibillity modes, running as administrator. Do you have any advise what to try next?

  • Henrik,

    Sorry - no idea what this is just by the error info. Is this Win7 or Win8? What version of Synapticad are you using (did you use the one shipped with the IDE - or did you update it?).

    Best Regards,
    Anthony
  • I missed/forgot to answer. I've tried Win7, Win 8 and even Win10. I've tried both versions of synapticad. 16.04f and 19.02c

    I've started a new thread minutes ago, asking if there is a switch to start the HET IDE without the simulator.