• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 83 subscribers
  • Views 615 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F280049-Q1: SFO library takes too long time

Wayne Huang
Genius 14365 points
Part Number: TMS320F280049-Q1

Dear Champs,

I am asking this for our customer.

The user is studying using HRPWM especially HR period and found SFO library takes up to 1.3 ms (13000 cycle) based on Table 18-19 of the TRM 18.15.2 Appendix A.

If SFO is put in the background loop in main(), it will affect all other operations in the main loop.

1. SFO library is usually placed in the background loop of main and can be interrupted by any other ISR. That is, SFO can be run in a very slow way. Is it right?

2. The user cannot accept using 1.3 ms in the background loop because there are other things to do in the same background. Do you have any suggestion how do they solve this issue?

3. The user is asking if TI can share with the source codes and algorithm so that they can divide SFO into several parts in the background loop of main() to ensure other things in the same background can be run as desired. Is it feasible?

4. Is SFO library required for them to use HRPWM?

5. If they don't use SFO (by disabling auto-conversion) and use max 310 ps to calculate MEP based on MAX of Table 5-62 of the datasheet, what will happen to PWM output when step size becomes smaller because temperature/voltage change (MEP is not changed)?

6. If they don't use SFO (by disabling auto-conversion) and use min 150 ps to calculate MEP based on TYP of Table 5-62 of the datasheet, what will happen to PWM output when step size becomes larger because temperature/voltage change (MEP is not changed)?

Please help us clarify.

Wayne Huang

  • 0
    TI__Expert 6790 points

    Hi Wayne,

    Please find below my answers:

    Wayne Huang said:
    SFO library is usually placed in the background loop of main and can be interrupted by any other ISR. That is, SFO can be run in a very slow way. Is it right?

    Yes, that's correct. It can be run as a part of the slower function.

    Wayne Huang said:
    The user cannot accept using 1.3 ms in the background loop because there are other things to do in the same background. Do you have any suggestion how do they solve this issue?

    One solution that I can think of is to increase the EPWMCLK frequency. Secondly, even if they interrupt the SFO function, it should not harm their purpose. The SFO will only update the existing MEP value after it has completed the calibration, else the previous MEP value is restored.

    Wayne Huang said:
    The user is asking if TI can share with the source codes and algorithm so that they can divide SFO into several parts in the background loop of main() to ensure other things in the same background can be run as desired. Is it feasible?

    I need to check whether this is possible or not. I'll come back to you on this.

    Wayne Huang said:
    Is SFO library required for them to use HRPWM?

    It is not mandatory to use. If they want to use the auto conversion feature where the SFO library updates the HRMSTEP register with appropriate MEP value, then only the library is needed, else they may choose to manually write to the register using software.

    Thanks,

    Aditya

  • 0 in reply to Aditya Dholakia
    TI__Expert 6790 points

    Can you please answer to queries 5 and 6?

  • 0
    TI__Guru 51940 points
    Wayne Huang said:
    If they don't use SFO (by disabling auto-conversion) and use max 310 ps to calculate MEP based on MAX of Table 5-62 of the datasheet, what will happen to PWM output when step size becomes smaller because temperature/voltage change (MEP is not changed)?

    You dont HAVE TO use the SFO. You can just calculate it yourself (the MEP step size) then use that value but if the temprature/voltage change and the MEP step size is not automatically updated in your calculation then your EPWM waveform will be off by the change in MEP step size x number of MEP steps used.

  • 0 in reply to Nima Eskandari
    TI__Genius 14365 points

    Dear Nima,

    1.

    "You dont HAVE TO use the SFO. You can just calculate it yourself (the MEP step size) then use that value but if the temprature/voltage change and the MEP step size is not automatically updated in your calculation then your EPWM waveform will be off by the change in MEP step size x number of MEP steps used."

    [W]

    What did you mean by "off" in yellow above?

    Did you mean EPWM output will be off - meaning output is changed to LOW (0V)?

    Or did you mean EPWM output will have offset from the desired output - meaning the rising and falling edges are somewhat "shifted and offset" in total by the change equaling MEP step size x number of MEP steps used?

    2. May we confirm again from 18.15.2 SFO Library Software - SFO_TI_Build_V8.lib of F28004x TRM, it says a typical cycles of SFO library is 130000, which means 130000 cycle * (1/100MHz) = 1.3 ms if this FO is running on RAM?

    The user tested SFO running time like below, but the result from GPIO1 on-time was much different from 1.3 ms. 

    Besides, when it says "typical", does that imply it is not a fixed time?

    We want to confirm how long it takes for one SFO execution, that is, how long it takes for "status = SFO();"

    Does the user's code below for testing SFO() make sense?

  • 0 in reply to Wayne Huang
    TI__Guru 51940 points
    Wayne Huang said:
    offset from the desired output

    I mean offset. Sorry for the confusion.

    When you say I want 300ps of HR, and then set the MEP steps to 2 (since your initial calculation gave you 150ps steps), later due to changes, if the step size goes to 160ps, now you are off by 2x10ps = 20ps.

    That's why we recommend continuous HRPWM SFO.

    Wayne Huang said:
    2. May we confirm again from 18.15.2 SFO Library Software - SFO_TI_Build_V8.lib of F28004x TRM, it says a typical cycles of SFO library is 130000, which means 130000 cycle * (1/100MHz) = 1.3 ms if this FO is running on RAM?

    The image you sent is the HRPWM calculation in the while loop. Has the initialization been already completed before the while loop?

  • 0 in reply to Nima Eskandari
    TI__Genius 14365 points

    Dear Nima:

    1. We understand. Is it possible the MEP offset (set by users) is too large and it’s exceed next (coming) TBPRD?

    2. Yes, the initialization has been completed. Please see the following snapshots based on the code (provided again below).

    DEVICE_DELAY_US is disabled.

    DEVICE_DELAY_US is for 500us.

    DEVICE_DELAY_US is for 5000 us.

    C2 is HIGH before status = SFO() and LOW after status = SFO().

    C3 is toggled after status == SFO_COMPLETE.

    From the above, it appears status = SFO() for one execution takes about 2 us to 3 us, which is different from 1.3 ms (from the doc) and confuses us.

    Or is the user’s testing method above for SFO() incorrect?

    Would you please help us clarify it?

    Wayne Huang

  • 0 in reply to Wayne Huang
    TI__Guru 51940 points

    All of the scope shots are showing GPIO1 correct? not GPIO2?

  • +1 in reply to Nima Eskandari
    TI__Guru 51940 points

    With the delay disabled, GPIO2 shows when SFO is completed.

    GPIO1 just shows how long it takes to check the status of the SFO calculation. A lot of time it should return i

    This will wait before your application while loop to ensure that the SFO is completed.

    while(status == SFO_INCOMPLETE)
    {
    status = SFO();
    if(status == SFO_ERROR)
    {
    error(); // SFO function returns 2 if an error occurs & # of MEP
    } // steps/coarse step exceeds maximum of 255.
    }

    This is what should take a longer time.

    Just calling SFO is CHECKING the status or KICK STARTING A NEW CAL. So it RETURNS fairly fast to ensure it doesnt block user executions in the main while loop.

  • 0 in reply to Nima Eskandari
    TI__Genius 14365 points

    Dear Nima,

    Thank you for your clarification.

    What about this question "Is it possible the MEP offset (set by users) is too large and it’s exceed next (coming) TBPRD?" in my last post?

  • 0 in reply to Wayne Huang
    TI__Guru 51940 points

    Yes! I have ran into this with the duty before.

    I didn't enable AUTOCONVERT and set a value larger than the RAW max MEP STEPs.

    BUT For TBPRDHR, (for using high resolution PERIOD) this wont be the case BECAUSE AUTOCONVERT MUST BE ENABLED!

  • 0 in reply to Nima Eskandari
    TI__Genius 14365 points

    Dear Nima,

    1. You said "BUT For TBPRDHR, (for using high resolution PERIOD) this wont be the case BECAUSE AUTOCONVERT MUST BE ENABLED!". The user wants to use HR period for LLC here. Does that mean they must enable HRCNFG.AUTOCONV? However, from the TRM, it seems HRCNFG.AUTOCONV is optional, and we don't notice it says for HR period, HRCNFG.AUTOCONV must be enabled. Would you please confirm again or show us where it is explicitly in the doc?

    2. If the user must use SFO and enable HRCNFG.AUTOCONV, back to the original question. From your clarification above, we understand it takes 1.3 ms for SFO to complete (showed by GPIO2 toggling). If they only use status = SFO(); to poll the status of SFO in the background code, which should only return error, completed, running, they only need to wait for one SFO status checking time and then do other tasks in the same background first and the check SFO status again and again later in the background. From their testing above by GPIO1, it seems SFO checking takes only 2us to 3us. That is, they only need to reserve 3 us as the max wait time rather than 1.3 ms in the background for SFO, or we can view the DEVICE_DELAY_US in the above testing codes as doing other tasks. Do you think this makes sense? If yes, do we specify or can we show them the max SFO status checking time?  Is 3 us as the max time reasonable, or can we show a max SFO status checking time here?

  • +1 in reply to Wayne Huang
    TI__Guru 51940 points
    Wayne Huang said:
    You said "BUT For TBPRDHR, (for using high resolution PERIOD) this wont be the case BECAUSE AUTOCONVERT MUST BE ENABLED!". The user wants to use HR period for LLC here. Does that mean they must enable HRCNFG.AUTOCONV? However, from the TRM, it seems HRCNFG.AUTOCONV is optional, and we don't notice it says for HR period, HRCNFG.AUTOCONV must be enabled. Would you please confirm again or show us where it is explicitly in the doc?

    If you are using HRPE (High Resolution Period) YOU MUST USE AUTOCONV.

    That's for #1.

    Wayne Huang said:
    If the user must use SFO and enable HRCNFG.AUTOCONV, back to the original question. From your clarification above, we understand it takes 1.3 ms for SFO to complete (showed by GPIO2 toggling). If they only use status = SFO(); to poll the status of SFO in the background code, which should only return error, completed, running, they only need to wait for one SFO status checking time and then do other tasks in the same background first and the check SFO status again and again later in the background. From their testing above by GPIO1, it seems SFO checking takes only 2us to 3us. That is, they only need to reserve 3 us as the max wait time rather than 1.3 ms in the background for SFO, or we can view the DEVICE_DELAY_US in the above testing codes as doing other tasks. Do you think this makes sense? If yes, do we specify or can we show them the max SFO status checking time?  Is 3 us as the max time reasonable, or can we show a max SFO status checking time here?

    You are exactly right. After the initial COMPLETE is given and you are in the main application while loop, the check for status/kickstarting the next calibration TAKES very short time. That is why you can run it in the background.

    3us is VERY reasonable. I dont unfortunately have the data for min/typ/max for SFO just checking the status. But 3us is very reasonable. It should be a few instructions that run in the code.