TMDSCNCD28379D: DAC not showing the correct signal; possible code overrun and how to solve it?

Mike,

Thanks for reaching out to the C2000 E2E. 

One approach would be to back track this out of the C2000 register settings and confirm the differences in the PWM control register setting between case 1 and 3. 

Since the frequency is double in case 3, maybe Simulink has added another Compare value to the PWM or changed from up count to up/down count or something like that.  It could be as simple as the period of the PWM halved.

I think there is a way to get the generated C code out, we could examine that for differences between the two scenarios.  Hopefully we could tie this back to one of the configurations in the Simulink block.

We could also connect CCS and examine the ePWM register settings that way as well.  Let me know what method you'd be most comfortable with and we can go from there.

Best,
Matthew

Hi Matthew,

I have gone through the code (not an expert, hence using Simulink :) In both codes (Inverter_000_test.c and Inverter_001.c) ePWM is initialised the same:

    /*-- Setup Time-Base (TB) Submodule --*/
    EPwm5Regs.TBPRD = 12500;           // Time Base Period Register

A 'solution' (not sure if this is the correct one) for adjusting the output frequency is changing the 'Rate Transition' 'Output Port Sample Time' parameter from 10e-5 (smaller code Inverter_000_test) to 5e-5 (bigger code Inverter_001). Block name is 'Rate Transition1'.

In Inverter_000_test.c and Inverter_001.c 'Rate Transition1' is defiend as

  /* RateTransition: '<Root>/Rate Transition1' */
  if (Inverter_001_M->Timing.RateInteraction.TID0_1) {
    Inverter_001_B.RateTransition1 = Inverter_001_DW.RateTransition1_Buffer0;
  }

  /* End of RateTransition: '<Root>/Rate Transition1' */

In Inverter_001.c

  /* Update for RateTransition: '<Root>/Rate Transition1' incorporates:
   *  Constant: '<Root>/Constant14'
   */
  Inverter_001_DW.RateTransition1_Buffer0 = Inverter_001_P.Constant14_Value_m;

  /* Computed Parameter: Constant14_Value_m
   * Referenced by: '<Root>/Constant14'
   */
  230.0F,

In Inverter_000_test.c

  /* Update for RateTransition: '<Root>/Rate Transition1' incorporates:
   *  Constant: '<Root>/Constant14'
   */
  Inverter_000_test_DW.RateTransition1_Buffer0 =
    Inverter_000_test_P.Constant14_Value_mo;
}

  /* Computed Parameter: Constant14_Value_mo
   * Referenced by: '<Root>/Constant14'
   */
  230.0F

So in both codes rate transition block constant is 230.0F... still have to investigate how this number is related to 5e-5.

Please find attached the code for both cases. Sine waveform is sent to DACOUTA and DACOUTB.

Inverter_000_test_ert_rtw.zip --> similified code, 100 Hz waveform

Inverter_001_ert_rtw.zip --> more detailed code, 50 Hz waveform

Mike,

Thanks for giving more background and sharing the simulink code. 

I had mis-understood the initial tie in between the C2000 PWMs and the output DAC.  I had incorrectly assumed that the DAC updates were tied into the update rate/events of the C2000 PWMs itself, vs coming from a common update algorithm that feed both in parallel.  The PWM register settings likely have nothing to do with what we are seeing.

I understand that you are using the DACs on the C2000 directly, fed from a Simulink calculated value(which does go to the C2000 PWMs, but unrelated to what you are measuring on your scope). 

I think you are on the right track with the Rate Transition setting, as we are using the C28x CPU to manually write this value to the DAC Output register, the timing of the write is important to preserve the frequency.  I suspect when you slim down the code, the C28x has more CPU bandwidth to update the DAC blocks with the output from the Modulation 1 block.

I see that the the output transition blocks that feed the DACs are controlled by a variable "Tcontrol" I would have thought this would keep the update rate constant between both versions of code. 

It looks like this is used to control the update in the control block in Inverter_001 as well.  Not sure if making a distinct update control for the DACs would fix this when adding more code.

I'm going to ask some of the folks at MW to comment a bit more here; if I were coding this in C I would likely tie the DAC update to one of the PWM ISRs to keep that update consistent with the PWM timebase itself; but with multiple update blocks perhaps these were all tied to a common CPU Timer, and its ISR.

Best,

Matthew

Hi Matthew -- I also recorded signals while running in External Mode. DAC and GPIO measure 50 Hz signals and logging signal gives 100 Hz waveform; same as with the 'smaller' code. PWM reference (control) signal is 50 Hz.

PWM signal is the correct switching frequency (5 kHz). There are no additional update settings for DAC or GPIO. Setting DAC synchronization signal to e.g. PWMSYNC5 did not solve the problem. The signal is still 50 Hz but with a slightly smaller resolution.

Does the signal frequency difference between the smaller and the bigger application code mean the code is too big and is overrunning?

Hi Mike,

Can you provide your model files that are scale down version from the original model but still help us to reproduce the issue.

Regards,

Venkatesh C

Hi Venkatesh,

yes, no problem. This is the layout of the smaller application code (file name: Inverter_000_test.slx); 100 Hz DAC output. The same elements are used in the bigger code (file name: Inverter_001.slx); 50 Hz DAC output

 ApplicationCodeF28379D.zip

Hi Venkatesh,

thank you very much. Toggling the signal at each step time helped a lot to pinpoint the issue. Even other tasks were overruning, i.e. step time was increased by 2. I have increased step time (for RAMP and ADC) and set them to be equal to control sample time (10 kHz) and now it works as expected.

Off-topic: you maybe know of a more optimal way of implementing RAMP signal and generating sinusoidal reference?