TMS320F28386D: SFO library explanations

Part Number: TMS320F28386D


Hello,

I have questions related to the SFO library to calibrate the HRPWM.

As we are under aeronautical constraints, we can't really integrate a library without knowing what's inside it. I contacted our FAE before Christmas holidays to see if we could get the source code.

However, in the meantime, we ran a dissassembly on the library to try to understand what it does.

Our understanding is the following, please confirm if we are correct:

  • The calibration is done with a calibration mechanism which registers are under the EPWM1 peripherals address space.
  • The calibration is done on one peripheral at a time (loop).
  • A first call is needed to initialize the SFO library variables.
  • The HW part of the calibration takes 130000 EPWM cycles and at least 3-4 calls are required to effectively reach the result (one call to start the engine - only for first array element -, one call to configure the calibration multiplexer, one call to wait for completion - this one could require to be called multiple times - and one call to compute and update the data).
  • During the calibration, the high resolution is disabled on the given peripheral --> THIS IS NOT STATED IN THE TRM
  • The calibration result is written in the HRMSTEP register of the EPWM1 peripheral whatever the calibrated peripheral, meaning that the same value is used for all PWM peripherals where high resolution is active even if they have different resulting MEP scale factor --> THIS IS NOT STATED IN THE TRM

The two last items are more annoying as these are not stated in the TRM and are important to be aware of.

Also, we wonder, would it be better to have a calibration per PWM peripheral ? I guess this could be achieved without using the AUTOCONV and managing ourselves a table of scale factors based on the MEP_scaleFactor variable computed by the SFO function. But it would mean either calling the function with only one element in the EPWM array or detecting a change back of the state machine to the step 2 after a call of the function to monitor the progress on the array and log the scale factor.

Best regards,

Clément

  • Hi Clement,

    SFO is implemented as a state machine and must be called repeatedly until it reports completion and this is why examples call it from a background loop.

    When possible, dedicating one ePWM that is not used in HRPWM mode to run the diagnostics and then applying the resulting scale factor to other HRPWM channels is recommended approach.

    The second point is expected. This is because all ePWM HRPWM instances use the same HRMSTEP value calculated by SFO, even though each ePWM has its own HRPWM clocking. This is mentioned in the SFO examples.

    Also, you don’t need to do calibration per PWM peripheral. The architecture is designed around a single device-wide scale factor being used for auto-conversion. Channel-to-channel variation is expected to be small.

    Best Regards,

    Masoud

  • Hi Masoud,

    So you confirm our deciphering was all correct ?

    And if I understand your answer, you recommend that we do the calibration on an unused peripheral (still in the range 1 to 8 which are the only one having HRPWM capability) ? Otherwise if we do it on a used peripheral we will have the high resolution capability during the calibration and it wouldn't be acceptable.

    These last two elements might be worth mentioning in the TRM.

    Clément

  • Yes, you're essentially correct. Regarding “HRPWM is disabled during calibration”, I would not state it that strongly as a universal rule. The goal is to choose the diagnostic/calibration ePWM channel in a way that doesn’t disturb your critical HRPWM outputs.

    Best Regards,

    Masoud

  • Masoud,

    Are you sure ? In the disassembly of the calibration code, the HRPWM gets disabled on the channel on which the calibration is performed from what we saw.

    Clément

  • Hi Clement,

    Let me assign the thread to an expert from SW/Design team for confirmation.

    Best Regards,

    Masoud