TMS320F28022: Transmit only for use with C2000/AFE031 App Note, replaces TMS320F28379

Nicholas,

1. Are you running the SFO? If so, how frequently? This should remove some small drifts in frequency due to a variety of causes.
2. How accurate is your SYSCLK input? Are you using a XTAL or the internal oscillator? 

Is the output always off by exactly 45Hz, or does that drift  to say 50Hz or 40Hz sometimes?

Regards,
Cody 

Hi Cody,

I'm running the SFO like this, with the #ifdef being on or off:

    for(;;) {

#if 1
		status = SFO_INCOMPLETE;
		while  (status== SFO_INCOMPLETE) { // This should automatically set HRMSTEP, do this after HRPWM_Config()
		
			status = SFO();
			if (status == SFO_ERROR) {

				error();  // SFO function returns 2 if an error occurs & # of MEPsteps/coarse step exceeds maximum of 255. 
			}
		}
		
		status = SFO_INCOMPLETE;	// Do it again...

		nCompareFineMarkPeriod		= (int)(MARK_FRACTION  * (float)MEP_SCALE_FACTOR) << 8;
		nCompareFineSpacePeriod		= (int)(SPACE_FRACTION * (float)MEP_SCALE_FACTOR) << 8;
		
		nCompareFineMarkDutyPeriod	= (int)(MARK_DUTY_FRACTION  * (float)MEP_SCALE_FACTOR) << 8;
		nCompareFineSpaceDutyPeriod	= (int)(SPACE_DUTY_FRACTION * (float)MEP_SCALE_FACTOR) << 8;

#endif
    }

The 2802x appears to default to the external crystal, I've tried it with and without this code to switch to the internal oscillator:

	CLK_Handle myClk = CLK_init((void *)CLK_BASE_ADDR, sizeof(CLK_Obj));
	CLK_setOscSrc(myClk, CLK_OscSrc_Internal);

I really appreciate any insights you might have.

The output will drift between 131.15kHz and 131.3kHz on the F2802x, and it can take half an hour to drift that much.

The F2802x has about 100 times more jitter than the F28379D does.

The amount of jitter I'm seeing might suggest the issue might be with the hrpwm??

The  S-FSK example code for the F28379D had hard coded numbers for CMPA, CMPB, TBPRD, and TBPRDHR.  As it turns out, the values don't multiply the frequency divisor fraction by the MEP_scale_factor, but they are simply multiplying the frequency divisor fraction * 256 to get the hrpwm period value.  In that same example code, the EPwm1Regs.HRMSTEP.bit.HRMSTEP is hard coded to 55 and it doesn't appear to call SFO after initialization.  Yet that works perfectly.

I've tried multiplying the frequency divisor fraction by 256, and  I've also tried this after calling SFO:

nCompareFineMarkPeriod = (int)(MARK_FRACTION  * (float)MEP_SCALE_FACTOR) << 8;

Which is the correct way?  Why does the F28379D multiply by 256 and set the hrmstep to 55?

I've tried setting the counter mode to TB_COUNT_UPDOWN, if I do that, my pwm period is defined as:

#define MARK_PERIOD (((float)CLK_FREQ / (float)MARK_FREQ ) / 2) 

If I set it to TB_COUNT_UP, TBPRD is defined as

#define MARK_PERIOD (1 + ((float)CLK_FREQ / (float)MARK_FREQ ) ) 

No idea why I'm seeing 100 times more jitter on the F2802x.

Thanks!

The MEP_ScaleFactor appears to dither between 117 and 118 after going through the SFO() loop.  It seems like the right thing to do, provided that it dithers with the right frequency...

Hi Kris,

I really appreciate the help.

As far as the SFO() goes, I get the same result if I run it continuously or just once at initialization.

I need to further clarify the  S-FSK example code for the F28379D, it wasn't multiply 256 to shift to the left by 8.

It's doing this: 

EPwm1Regs.TBPRDHR = (243U << 8);

In this case, the 243 is given by: (200Mhz / 131.25kHz / 4 (prescaler)) * 256.   (I would expect it to be multiplied by MEP_ScaleFactor)

This 243 is then shifted to the left by 8 to be in the upper byte.

Hi kris,

I'm trying to sanitize my code.  Is it possible to email you a copy of it?