HR resolution PWM?

Hello Jack,

I have forwarded your question to one of our N2HET experts. They should get back with you shortly.

Jack,

Please try the HET code here:

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/312/1856.pwm_5F00_3Phase.het

It may not be exactly what you are looking for but it gives PWMs with HR resolution both for period and duty cycle.  It's setup for 3 phase, complementary w. deadband - which you might not need but you can adapt from this.

-Anthony

Hello Anthony,

thanks a lot for providing this code example - that is quite complex ;-)

One question has arisen when my colleague studied your code - does the remote parameter of the instuction SUB at the line 82 contain the correct value? Should there be the PERSET label instead of PERPIN, should not?

SUB   {src1=T, src2=R, dest=NONE, rdest=REM, data=0, hr_data=0, remote=PERPIN, next=BUFDCA} ; Write Half Period Compare to PERPIN

SUB   {src1=T, src2=R, dest=NONE, rdest=REM, data=0, hr_data=0, remote=PERSET, next=BUFDCA} ;

Many thanks for your explanation in advance,

Best regards, Jiri

If our understanding is correct the instruction at the line 82 is modifying data of the ECMP  instruction at the line 64:

SUB   {src1=T, src2=R, dest=NONE, rdest=REM, data=0, hr_data=0, remote=PERPIN, next=BUFDCA} ; Write Half Period Compare to PERPIN 

PERPIN  ECMP   {en_pin_action=ON,  reg=T, pin=PEROUT, action=CLEAR, data=0, hr_data=0, cond_addr=PERSET, hr_lr=high, next=PWMPINS}; 

We think the code at the line 82 should modify the MOV64 instruction at the line 65:

PERSET  MOV64 {en_pin_action=ON,  reg=T, pin=PEROUT, action=SET,   data=0, hr_data=0, cond_addr=PERCLR, remote=PERPIN, comp_mode=ECMP, next=BUFPER};

Are we wrong? May you clarify why?

Many thanks in advance,

Best regards, Jiri

Hi Jiri,

Actually  for this application the PEROUT pin is just something I did for debug purposes, so that you could see that the PWM period was indeed adjustable in increments of +/- 1 HR clock.

However, the ECMP at line 64 (PERPIN) would be needed even if there were no pin action because there are housekeeping tasks to be done at the period and half-period boundaries.

PERPIN is one of those 'self modifying' lines of N2HET code.  There's a couple paths through this sequence:

PATH a)  PERPIN -> PERSET -> BUFPER -> CURPER ..... PHASEA .... PHASEB .... PHASEC ... -> PWMPINS  - This path is taken at a full period boundary.   All the switching points are calculated during the execution of this path.

PATH  b) PERPIN -> PERCLR -> HPUPDATES ... -> PWMPINS - This path is taken at a half-period boundary.  There's a little house-keeping that is done during the half period.  It's been a while so I forget exactly why this is, but it's necessary to clear the ECMP instructions at this point in the period.

There might actually be a latent issue here I hadn't seen before but need to analyzer further...

PATH c) PERPIN -> PWMPNIS -> taken when there isn't a period or half period match ...

 just do the ECMP for each pin..

Ok to come back to your question,  that happens on path "A" which is:

a)  PERPIN -> PERSET -> BUFPER -> CURPER ..... PHASEA .... PHASEB .... PHASEC ... -> PWMPINS

Now, the calculation of the half period is done during "CURPER" and it's code.  So writing to PERSET or PERCLR here would not make sense,  the PERPIN instruction has already been updated to the correct next 'action' we just need to change it's compare value.   This is why I'm writing directly to PERPIN.

If we were to update PERSET or PERCLR then we'd need to do the math first, then run the update instruction.  But that's a little more complicated, because you'd need keep some status around that reminded the HET whether to do PERSET or PERCLR *after* doing the math.  

No reason it couldn't be done, but I just found it a good tradeoff to write the code the way it is now in terms of working within the cycle count and the instruction memory budgets.  Might have needed to duplicate a lot of the 'math' code if there were different paths through it, and that would run the instruction count up.

Back to the 'latent issue' ... This code worked fine on the simulator but when I ran it on hardware the first time, it stopped after a minute or so and I found there was a boundary conditon on the counter rollover.  That would have taken *forever* to run on the HET IDE simulator, but happened relatively quickly on the real silicon.  Now;  I fixed that so this code should work on silicon, but  I am wondering now if there's not a boundary condition that could occur if the value of '0' that is written to the ECMP actually might be within the window of the half period during rollover.   I think the idea of this code was to suppress the actions that got pushed from 1st half into 2nd half of the period in case the deadband completely obliterated a pulse high or low.      But "0' might not always be 'in the past' given the counter rollover and so there might still be a latent issue.  Maybe it would have been better to read the current period value and write *it* to the compares instead of '0' so that we always have a number 'in the past'.
I need to look at that one - or you can look at it too and let me know your opinion.  So thanks for asking the quesiton because it would be great to get rid of such a latent issue before making this into an appnote/video.

Hello Anthony,

thank you very much for the explanation in detail! Especially the steps regarding the write into the data field of "PERPIN ECMP".

The latent issue (between the change of "ECMP" action and the data filling/write) should be solved as you described:

A value stored in the data field of "PERSET MOV64" must be equal to a (older) time value prior to an actual time. So means that the current value of 0 is not valid.

My colleague suggests following sequence / procedure:

In the current implementation the time of  the period middle is written into the "PERPIN ECMP" instruction. It should be also written into the "PERSET MOV64" instruction. This ensures during the next call of  the "PERSET MOV64" instruction its data field will contain a timestamp which "has occured" in the past.

Best regards, Jiri

Thanks Jiri,

I'll look at the suggested fix for the latent issue and try to get it into the next iteration of this program.
Planning to turn this into a video/slide presentation.  

Also I should mention that our 'todo' list for this code also includes exploring the split of the calculation steps so that some are done at the period compare and the rest are done at the half period compare.   The motivation for this comes because one of my colleagues had tried to add the code for a QEP decoder to this program and ran out of cycles ... which would mean decreasing the N2HET resolution to make room for the QEP.   As an alternative we've talked about deferring some of the calculations to the half period boundary.  I don't know if you're path will take you in this same direction; but if so that's our thought.   We haven't tried implementing this 'improvement' yet.  It should be feasible, but I also expect it to be a bit tricky because of the nature of N2HET code like this (lots of jumping around, some self-modifying instructions like PERPIN, and very limited # of registers).

Hello Anthony,

thanks a lot for your precise reply and sorry for my late reaction!

Up to now there has arisen another question (or requirement) - how to generate symmetrical dead-times (for switching devices/circuits, e.g H-bridge etc.) to protect the driven devices and simultaneously to get an output signal with so low total harmonic distortion as possible?

Many thanks for your hints,

Best regards, Jiri

Hi Jiri,

I probably need a picture of what you mean by symmetrical dead-times.   But this basic algorithm computes all the switching points so I think you could adjust them or offset them by changing the math slightly.  

The algo posted should be generating symmetric PWMs (aligned to the center of the period).   Is there some asymmetry that is introduced by adding the 'biased' dead-band and you'd like to correct for this?

Best Regards,
Anthony

Hello Jiri,

It has been some time since the last acitivy on this thread. If your question has been answered, please verify the answer so we can close the thread. If you still are having issues/questions on this topic, please let us know so we can help resolve them.

Hello Chuck,

I guess this thread has been opened by Jack - so I assume that I am not able to close that - and really, only the button "Reply" does appear although I am logged in.

Best regards,

Jiri