• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 699 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: ePWM[] variable never accessed by SFOv8

Pierre Bouchet1
Expert 2615 points

Part Number: TMS320F28379D

Hello,

I am using SFO_v8_fpu_lib_build_c28.lib and based on the TRM and the code examples I declare which ePWM modules are going to use HRPWM in an array like so:

volatile struct EPWM_REGS *ePWM[] = {0, &EPwm1Regs, &EPwm2Regs, &EPwm3Regs, &EPwm4Regs};

However no matter what I put in the ePWM array the SFO() function seems to never access the contents of the ePWM array.

Furthermore I can see from the disassembly window that a global variable called SFO_CAL is used to index the ePWM array and as far as I can telle that variable is never written by SFO() so the calibration routine cannot read anything else than the first element of the array which is zero.

So my question is: why do I need to define the ePWM array and is it really necessary?

Cheers,

Pierre

  • 0
    Expert 2615 points

    I also forgot to add that the SFO() function never writes in the global array named MEP_SF except at its very first address. Given how this array has 8 elements I suppose it has to do with the fact that there are 8 ePWM modules with HRPWM capability, but only the first one appears to be used.

    Regards,

    Pierre

  • 0 in reply to Pierre Bouchet1
    TI__Guru 52200 points
    Pierre,

    It's great that you asked this question. I have been actually tracking down the SFO library changes and content in the past week. I had all the same questions as you. I am tracking down the answers and will get back to you.

    Nima
  • 0 in reply to Nima Eskandari
    Expert 2615 points

    Hi Nima,

    Thank you, this is a very interesting topic since I am trying to understand the impact of SFO on CPU scheduling for my project. Of course given that you probably have access to the source code it should be easier for you to see what's going on.

    I can only work with the compiled code but there are still some useful pieces of information here and there (debug information, register names, etc.) and I suspect that several parts of the SFO() function are never executed when I call the function in my F28379D program:

    • When TaskPtr == 1 the block (between labels C$L2 and C$L3) where a few registers in the module pointed by ePWM[SFO_CAL] are reconfigured (e.g CMPAHR is set to 80 microsteps) after HRPCTL and CMPAHR have been saved to temporary variables.
    • When TaskPtr == 3 the block (between labels C$L6 and C$L7) where the CMPAHR of the module pointed by ePWM[SFO_CAL] is set to to 200 microsteps.
    • When TaskPtr == 5 the block (between labels C$L12 and C$L13) where the values saved in temporary variables are restored to HRPCTL and CMPAHR.

    From what I can gather all this is dead code because SFO_CAL is set to zero the first time SFO() is called and this value never changes again.

    Regards,

    Pierre

  • 0 in reply to Pierre Bouchet1
    Expert 2615 points
    Hello Nima,

    Any news on this topic?

    Regards,
    Pierre
  • 0 in reply to Pierre Bouchet1
    TI__Guru 52200 points

    You are correct. All of that is dead code. They were features supported in SFOv6b but since v7 none of those are used. In fact the storing and restoring of the CMPxHR are not needed in the v7. The *ePWM[] is not used but since it still exists in the source, it must be created in your application code. All calibration is done with ePWM1 and other than the fact that due to some delays in the code which uses the RPT NOP, interrupt may be delayed minimally. 

    Nima Eskandari

  • 0 in reply to Nima Eskandari
    TI__Mastermind 42195 points

    Pierre,

    What Nima has stated is correct, to give you the "why" see below.

                   This function is largely legacy because of the limitations of certain diagnostic logic. On older devices it was necessary to shut down and dedicate an HRPWM channel for periodic calibration, this structure enabled the user to easily switch between the HRPWM channel that they wished to use to do this.(SFO V5)

     

    Please define the structure similar to: 

    volatile struct EPWM_REGS *ePWM[PWM_CH] =

             { &EPwm1Regs, &EPwm1Regs, &EPwm2Regs, &EPwm3Regs, &EPwm4Regs,

               &EPwm5Regs, &EPwm6Regs, &EPwm7Regs, &EPwm8Regs};

     

    And that is it, you will not need to preform any operations on this code.

     

    Regards,
    Cody

  • 0 in reply to Nima Eskandari
    Expert 2615 points
    Nima,

    Thanks for your answer.

    I have 2 small questions left:

    (1) I have been using the SFO library with "fpu" in the file name but when I use it in my program it calls the (slow) FS$$DIV function in order to perform divisions, instead of taking advantage of the DIVF32 instruction of the FPU. Is that normal or is it because I missed something in my configuration?

    (2) Do you think it possible that in a future version of the SFO library (v9 I guess?) the RPT||NOPs could be replaced with other instructions such as those used in DSP28x_usDelay?

    Regards,
    Pierre
  • 0 in reply to Cody Watkins
    Expert 2615 points
    Thank you Cody! I was writing my own answer to Nima and it seems you and I posted our answers at the same time :)

    Regards,
    Pierre
  • 0 in reply to Pierre Bouchet1
    TI__Guru 52200 points
    Unfortunately I don't think you have missed anything. In the next rev, both of those should be fixed.