• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 83 subscribers
  • Views 3006 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28379D: C2000 LaunchPad: HRPWM doesn't work when generating Code from Simulink (with C2000 support package)

Matthias Ampferl
Prodigy 160 points
Part Number: TMS320F28379D


Hello!

As I don't know who exactly designed the C2000 Simulink block set, I'm asking my question here.

I want to use the F2837xD block from said package to create four synchronized 100kHz, 50% duty cycle PWMs, each phased shifted with respect to the others.
The goal is to implement the control for a phase-shifted dual half-bridge DC/DC-converter. Therefore, PWMs 1 and 2 have to be 180° out of phase, as do PMWs 3 and 4. The hard part is finely controlling the phase between PWM1 and PWM3 (which actually controls the converter).
I built an experimental model that runs on the LaunchPad C2000 TMS320F28379D. The ePWM clock rate is set to 100MHz (SYSCLKOUT/2), Time base clock prescaler in each ePWM module is 1.

The scheme I'm using is the following: ePWM12 generates a 100MHz "master clock", that generates a SYNCOUT signal every time the counter reaches zero. I use this SYNCOUT to synchronize all other "slave" PWMs (ePWM1 up to ePWM4). The latter have their Sync. Output set to "Pass through".  The slaves use the counter period value of the master (ePWMLink TBPRD set to ePWM12).
Because high resolution is needed, I enabled the option "Enable high resolution PWM (HRPWM)" in the slave ePWM modules (not in the master). I enter the phase shift value as a decimal (in this case, i tried the register value 10.25)

With that, I encountered a bug:

The code generator doesn't generate code for updating the TBPHSHR register with my phase shift value. It only initializes TBPHSHR to zero. Therefore, I don't see the decimal, so to speak the "high resolution" part of the phase shift in my output signal. I measure the signal directly at the pin with a 200MHz oscilloscope and 500MHz probes. I only see a phase shift corresponding to the normal TBPHS register (the integer part of the phase shift).  
Is there a workaround or hotfix for this?



Sincerely

Matthias
Student (University of Applied Sciences Ingolstadt)

  • 0
    Mastermind 9005 points
    MathWorks authored this support. I will forward your bug report to the development team, and I report back any additional info I learn.

    Thanks,
    -Brian
  • 0
    Mastermind 9005 points
    What version of MathWorks software are you using?

    -b
  • 0 in reply to Brian McKay
    Prodigy 160 points
    Thank you.

    I'm using Matlab R2017a (Version: 9.2.0.556344)
  • 0 in reply to Matthias Ampferl
    Mastermind 9005 points

    I got confirmation that the development team is looking at this. I'll post when I know more.

    -b

  • 0 in reply to Brian McKay
    Prodigy 160 points
    Thank you.
    I'm looking forward to it.
  • 0 in reply to Matthias Ampferl
    Mastermind 9005 points

    Hi Matthias,

    I've been told you are working with MathWorks Advanced Support on this issue.  Please keep working via that channel - it is the best/fastest way to move forward.

    Thanks,

    -Brian

  • 0 in reply to Brian McKay
    Prodigy 160 points

    Hi Devin,


    it's only a temporary fix for the moment, but I've been provided with some files that enable HRPWM use through the Simulink blockset.

    It generally works, but there are still 2 problems:

    1. The measured PWM phase shift doesn't exactly match the register values. It's not due to a measurement error (oscilloscope), because when I increase the TBPHSHR register value linearly, the phase shift doesn't increase linearly. The error (real phase shift minus ideal phase shift) increases with the phase shift.
    2. The "fractional part" of the phase shift (i.e. 0.25 in case of 5.25) is substracted from the "integer part". This results in "jumps" when the phase shift value crosses integer boundaries.

      This results in the following phase shift register values and measured phase shifts (shown as time difference between reference PWM and shifted PWM). PWM frequency is 100kHz.

      4.00 -> 40.2ns
      4.25 -> 37.8ns
      4.50 -> 35.4ns
      4.75 -> 32.9ns
      5.00 -> 50.3ns
      5.25 -> 47.8ns
      5.50 -> 45.4ns
      5.75 -> 43.0ns
      6.00 -> 60.2ns
     
      expected values are
     
      4.00 -> 40.0ns
      4.25 -> 42.5ns
      4.50 -> 45.0ns
      4.75 -> 47.5ns
      5.00 -> 50.0ns
      and so on
     
      You can clearly see that the real values and the ideal values deviate. Also, there's this "jump" problem.
      All time shifts were measured directly at the LaunchPad's pins, the oscilloscope's GND crocodile clips connected to one common GND pin on the LaunchPad.
     
     
    I should also add that the phase shift is negative (i.e. the phase-shifted signals switch "high" earlier than the reference).
    At first I expected positive phase shifts (i.e. the shifted signals are delayed relative to the master/reference PWM), but it wouldn't be such a problem if problems 1 and 2 wouldn't happen.

    Can you explain why this happens (at least part of the behaviour)? Is it a fault on my end?


    Matthias

  • 0 in reply to Matthias Ampferl
    Prodigy 160 points
    I should add that I directly wrote the TBPHSHR register in Code Composer Studio before, to debug the code generated by Simulink.
    There, it also showed an increasing difference between TBPHSHR register value and real phase shift. What could cause this?

    The part of the Simulink code which periodically updates the TBPHSHR register value of each ePWM module currently looks like this:

    110 {
    111 extern int MEP_ScaleFactor;
    112 real_T TBPHSf = Converter_DHB2_PWM_LaunchPad_B.phi1_val; //taken from Simulink block (max. count * phase shift / 360)
    113 TBPHSf -= EPwm4Regs.TBPHS.bit.TBPHS;
    114 TBPHSf *= MEP_ScaleFactor;
    115 EPwm4Regs.TBPHS.bit.TBPHSHR = ((uint16_T)TBPHSf <<8)+ 0x80;
    116 }

    Which, as far as I can see, matches the explanation on page 1852 of the F28379D Reference Manual.
  • 0 in reply to Matthias Ampferl
    Prodigy 160 points

    A temporary fix from Mathworks has resolved issues with the ePWM code generation of Simulink.

    However, the PWM signals still don't come out as intended. I think its a misunderstanding on my part.

    As this is technically a new question and not Simulink-related, I'll open up another thread.

    Matthias