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.

TMS320F28377S: Problems with SFO library and delayed PWM register updates from CLA

Part Number: TMS320F28377S

I am using the TMS320F28377S part with a control loop running in the CLA and updating the ePWM CMPA registers. The SFO v8 library is being called every 100ms in a background loop on the main processor core. The CLA code is timed to provide the CMPA register updates just before the beginning of a new ePWM cycle. At random times I am seeing the CLA taking up to an additional 25ns (at 200MHz) to finish updating all the CMPA registers. I have tracked down the delays to be happening when the SFO library is executing on the main core while the CLA is trying to update the CMPA registers.

I am unable to find detailed information about the SFO library and its execution times and states other than its initial call time. During the background periodic calls to the SFO library expectation is to not have any impact on ePWM access or interrupt operation.

How best to eliminate or synchronize the activity of the SFO library with the CLA?

Does the SFO library interfere with interrupts and/or contain any REP instructions that would delay interrupts?

Is it possible execute the SFO library and do the ePWM updates that cause delays in an interrupt routine?

  • Hi PinkCrapeMyrtle,

    25ns is 5 cycles at 200MHz. The CLA is likely experiencing these delays because the C28x is accessing the PWM registers at the same time. The C28x has priority for read/write access over the CLA. Therefore, the CLA will get stalled when both CPUs try to access the same peripheral or peripherals on the same bus or peripheral bridge.

    You can perform some synchronization using message RAMs. You can have the C28x signal to the CLA when it is finished touching the PWM registers.

    I do not know what you mean regarding REP instructions. Do you mean RPT (repeat) instructions.

    I will need an SFO library expert to help with these questions.

    Regards,
    sal
  • Hello,

    Yes, there are RPT instructions for delay in the SFO function to complete calibration and may cause minor interrupt latency. The maximum delay to generate an interrupt should be about 20 cycles when using the SFO.

    You could consider calling the SFO less frequently, around every 5-10 seconds if the application doesn’t have many temperature/voltage fluctuations.

    The SFO calls are intended to be part of initialization and/or a background loop, not in an ISR. This ensures that the SFO is actually executed and doesn’t rely on an interrupt to be generated.

    Regards,
    Elizabeth
  • Yes the delays that I am seeing are from C28x accessing the PWM registers at the same time. Where in the documentation would I find information about C28x having priority of the CLA during peripheral access? I know that the documentation talks about the C28x and CLA using a round robin arbitration for shared memory.

    The system is running a real-time control loop on the CLA that can’t be delayed. Missing update window in the control loop could lead to system instabilities. The CLA would have to signal the C28x to not perform the PWM accesses in the SFO library when the CLA is getting ready to access them. I need access to the SFO library source in order to do this. The HRPWM documentation talks about the need to run the SFO library in the background to keep the scale factor optimized and it implies that it shouldn’t cause any issues with the rest of the running software.  I need to get more detailed information about how the library will affect the rest of my software such as maximum delays to interrupts and access sequences to ePWM that would cause delays to CLA operation in access to ePWM registers.

    Yes, I meant RPT instructions.  

    Decreasing the frequency of calling the SFO doesn’t help since it would still cause delays in the CLA control loop when it is called.

    Since the C28x and CLA are running independent of each other the only way to keep the C28x from accessing the ePWM register at the same time is to try manage the SFO library PWM accesses through an interrupt routine. This would allow for synchronization between the CLA and C28x and not have them both access the PWM registers at the same time.

  • Hi,

    We cannot release the source code to the SFO library.

    The TRM and Datasheet have arbitration information regarding the memory accesses for C28x and CLA.

    There are multiple ways you can synchronize the CLA and C28x. You can use message RAMs. You can also use the MIRUN. The C28x can view the MIRUN register. If the CLA task is running, then the C28x should wait to access the PWM registers until the CLA task is complete.

    Hope this helps. Let us know if you have any more questions.

    sal