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.

  • Resolved

TMDSRSLVR: TMDSRSLVR Exitation generation sw enquiry

Prodigy 110 points

Replies: 10

Views: 425

Part Number: TMDSRSLVR

Hello,

I am developing some code for a resolver interface and I am porting the code for the resolver for a f28335 (controlSUITE\development_kits\TMDSRSLVR_v1.0\Resolver_f28335) to a TMS320F28379D.

I believe I understood most of the code, but there is one part that is very obscure to me:

the definition of the PWMs are as follows:

	ePWM_1ch_CNF(&EPwm1Regs, TIMECNT_6p25uS, 1, 0);     // 160KHz time base gen
	ePWM_1ch_CNF(&EPwm2Regs, SINE_CARRIER,   1, 0);     // Sine carrier gen

Also "SINE_CARRIER" is defined as:

#define   SINE_CARRIER           (250*2.5)  /* 2.5 for Delfino,  1 for Piccolo  */

Now,  the initialization for EPwm1 is clear that needs to have a frequency of 160kHz, however I don't undestand the 250 (or 625 for piccolo).

If the sinewave is to be updated every 6.25us (160kHz), shouldn't its carrier also have the same period?

What are these 250 and 625 numbers based on?

Thanks

  • SINE_CARRIER is the modulator @240KHz for the resolver sine wave. Basically, the carrier sine wave is generated through EPWM2 and is filtered to get a 10KHz sinewave. For Delfino with a 150MHz clock, a PRD of 625 yields 240KHz, for a Piccolo @60MHz, a PRD of 250 yields the same carrier frequency for the carrier. Well, it is a carrier for the carrier!!.
  • In reply to Ramesh Ramamoorthy:

    Hi Ramesh,

    thank you for your answer: I see now how the SINE_CARRIER period is obtained.

    I didn't find before any reference to the 240kHz for the sine_carrier (maybe I skipped some documentation, not sure); I will check with this value and have a look at the signals. 

    I'll be in touch soon with some results

    Thanks,

    Marco

  • In reply to MaDe:

    The carrier modulator was chosen to be higher frequency than the update rate to get a cleaner looking sinewave carrier. With Piccolo @60MHz clock, 240 KHz carrier's carrier seemed to be the limit. For Delfino, it could be higher, agreed. In hindsight, all this could be simplified to update at the sampling rate. Try it out and see if you see any advantage, one over the other.
    Btw, I did not expect to see the kinks in the plots.
  • In reply to Ramesh Ramamoorthy:

    Hi,
    I have a wrong setting for the period in the sine, I'll try again tomorrow... ( left the 625 I think, I have to recalculate it for the 100MHz clock I have on the 28379D).

    You were too fast in answering, I realised later my mistake and changed my comment. I will soon post a video with the proper frequency.

    Thanks again.
  • In reply to MaDe:

    Hi,

    as promised I checked everything again,  setting proper timing for 160kHz and sine_carrier.

    I had an initial hiccup where all my waveforms had double frequency: I was using the symbol "_LAUNCHXL_F28379D" according to the TI tutorial I looked at some time ago for the F28379D.

    However today I learnt that it doesn't apply to me because I don't have a launchpad!

    I would suggest to add it to the end of the course manual: C28x_Microcontroller_ODW_2-0.pdf. The hardware differencies are well specified,  however there is no mentioning about this little software detail... Now I also understand why I could never enter the realtime debugging!

    Going back to the resolver code: now everythign is as it should be.

    In attach a screenshot of my waveforms: D0 is toggle at 10kHz, D1 is the busy pin for the ISR and D2 is the PWM output for the sine generation.

    Yellow and blue are DAC outputs for the 160 and 240kHz carriers. Note: When they are flat it means that the CPU is busy and it has no time to update the value, nothing to worry about

    Thanks again!

  • In reply to MaDe:

    Hello again,

    I am getting very nice sinewaves from the resolver, as you can see in the picture.

    However I have a furhter question: how the code knows where to calculate the angle?

    Reading the AN it says that it does a decimation of 16, to read just the peaks ("controlSUITE\development_kits\TMDSRSLVR_v1.0\~Docs\resolver_to_digital_conv.pdf", Chap. 2.3.2

    I found the

    #define   ADC_SAMP_INST           875    /* adc sampling instant set up  */

    to specify where the sampling should happen, within the 160kHz period (the default value 875 is too high I think, it should be below 625)

    But then, what specifyes wich one of the 16 sampling instants the angle needs to be calculated? The isr routine seems to take longer on the 4th sampling, which is quite far from the actual peak (I have not connected yet the A2D at the momen), will it self adjust with the measure?

    Regards

  • In reply to MaDe:

    You mention that the 4th ISR routine takes longer, so that is where the decimation is happening right now. You may have to position the decimation instant to match with the peak of the sine / cos feedbacks to get a higher SNR. Vary ADC_SAMP_INSTANT to fit your needs.
  • In reply to Ramesh Ramamoorthy:

    Hi Ramesh,

    I tried to change that parameter but it only shifts the sampling within the one cycle,

    in fact it is used here:

    	EPwm7Regs.CMPA.bit.CMPA = ADC_SAMP_INST;   // for ADC SOC generation

    But, from my last picture, you can see that the sampling needs to happen 2.5 cycles before. The 0.5 factor is easy, but where do I specify to read 2 whole cycles before?

    From my understanding, what triggers the decimation is this part of code, in the resolver.c:

    if (resolver_algo_Float())
    {
          EPwm7Regs.ETCLR.bit.INT = 1;                // clear EPwm1 INT flag
    }

    So the routine "resolver_algo_Float" should return 1 when it's the peak of the sinewave.

    There is no documentation about it because is part of TI libraries; will it detect the peak automatically? As I said, I am being cautious and I haven't plugged the sin/cos signals to the ADCs yet.

    Thanks

  • In reply to MaDe:

    OK, ADC_SAMP_INST sets the sampling instant within the 12.5us (or 6.25us) window. This is supposed to be adjusted to sync with the sine peak when the sampling window is close to the peak of the sine wave.

    There is another variable called 'rslvrIn.firLag', this sets the count of the window where the peak is supposed to occur. Depending on the amount of phase shift in the sine wave feedback wrt the sine table, you can pick this number. If the sine table has 8 entries, the 90deg mark should occur corresponding to after the 3rd entry of table is put out, which will have an index of 2. You can experiment adjusting these two values and evaluate.

    Hope it helps.

  • In reply to Ramesh Ramamoorthy:

    Great, thanks!

    I now understand how it works.

    I also was able to dug up some documentation of the library in "controlSUITE\libs\app_libs\motor_control\libs\resolver\v101\~Docs"

    Thanks for the support, all good now!

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.