Understanding the SFO() routine

HI,

try to go through this RG 2625.HRPWMspruge8e.pdf (Appendix A, p.39).

Regards,

Igor

Thank you, Igor.

I had looked through the TRM a good bit. It was the language of the TRM that was at least part of the cause for my confusion. It was not immediately obvious that once called, the SFO() routine does NOT continue to run until calibration is complete. It was also not obvious that subsequent calls to SFO() are essentially polling for status of the already initiated calibration. But after a few times through it, I think I understand that now.

The only remaining question is the range of CPU cycles that may be required by execution of the SFO() routine. Are there theoretical minimum and maximum numbers for this? The TRM text refers to "negligible CPU cycles." I would really like to quantify (or place bounds upon) the term "negligible."

Thanks again for the assistance.

Hi, Robert.

Robert Weggel said:

The only remaining question is the range of CPU cycles that may be required by execution of the SFO() routine. Are there theoretical minimum and maximum numbers for this? The TRM text refers to "negligible CPU cycles." I would really like to quantify (or place bounds upon) the term "negligible."

Well, I think only TI employees can answer this question, if this info is not closed.

Regards,

Igor

I made some measurements regarding SFO(), see comments in code below:

Initialization:

   DBG_MEPSFO_LED_ON;
   while(SFO() != SFO_COMPLETE) // 2.2ms @ 60MHz F28033
      ;
   DBG_MEPSFO_LED_OFF;

Periodic call every ca. 200ms:

   DBG_MEPSFO_LED_ON;
   SFO();   // 5 calls = 1 cycle; duration = 2 / 2 / 15 / 2 / 26 µs @ 60MHz F28033
   DBG_MEPSFO_LED_OFF;

Hope this helps.

That is very helpful.

However, to better understand: in the line that contains the periodic call to SFO(), are the data points actually in µs? Does that mean that the fifth call to SFO() occupied the CPU for 26µs/16.67ns = 1560 cycles? If that's the case, I might challenge the TRM's claim that an SFO() call requires "negligible" cycles.

Regardless of reality, your measurements and time are truly appreciated.

Thank you.

Yes, it's microseconds, rounded.

The SFO state machine appears to have 5 states it cycles through, each state consuming a distinct amount of time. No change there whether called every 10ms or every 200ms (these were the extremes I tested).

HRMSTEP is updated at every 5th SFO() call (can't tell which), i.e. every 1000ms if SFO() is called every 200ms - consuming about 46 ppm CPU cycles.

These are just my observations with my setup: F28033 at 60MHz, SFO lib V6b, runtime measured by scope on I/O pin, IRQs disabled around pin toggle and SFO call, thus undisturbed.

Despite the helpfulness of the lab experiment data, I wonder if any TI employees might be able to answer the following:

1. From the time SFO() is called until the time the program counter returns to the calling code, how many clock cycles are consumed by the SFO() routine?

2. Is there a minimum number of CPU cycles that will always be required for each call?

3. Is there a maximum number of cycles that could be required for each call?

4. Is there any ability of the user/developer to restrict or further control the SFO() routine?

My application's iteration (or loop) rate is very fast. So each clock cycle counts. It is therefore crucial that I understand better the requirements for use of the SFO() calibration routine. It should not be an issue for me to make periodic SFO() calls; each individual call could be an issue, however, if it requires too much time.

Whatever details that may be provided are greatly appreciated. I understand the TRM discusses the SFO() routine somewhat, though I was unable to quantify its behavior from the TRM. I should also re-iterate my thanks to those who have responded and invested time on my behalf.

I am specifically interested in the SFO() routine's behavior/use in the TMS320F28062 MCU (if, in fact, its behvior differs within the Piccolo device family).

Robert,

I'm working on collecting all of the information you need, but I expect this is going to take a week or so by the time I have everything.  In the meantime, if you haven't already reviewed the SFO portion of the HRPWM chapter in the TRM I recommend doing so.  It does list the max execution time for the SFO function which should help with one of your questions.

I'll get back to you with more information as soon as I have all of the details I need.  Thanks,

Kris

By "HRPWM chapter in the TRM" do you mean spruge8e?

It states "Typical time required for SFO() to update MEP_ScaleFactor if called repetitively without interrupts: 2.23ms (60 MHz SYSCLK)" - which seems to apply only for initialization, not for repeated calls, see my measurements above.

Robert,

Please see the responses to your questions below.

Robert Weggel said:

1. From the time SFO() is called until the time the program counter returns to the calling code, how many clock cycles are consumed by the SFO() routine?

In total, if the SFO() for F2806x is called continuously with interrupts disabled it will take approximately 132,000 cycles.

Robert Weggel said:

2. Is there a minimum number of CPU cycles that will always be required for each call?

You can expect the  minimum number of cycles from the time you call the SFO() until it returns to your code to be approximately 60 cycles.

Robert Weggel said:

3. Is there a maximum number of cycles that could be required for each call?

You can expect the maximum number of cycles from the time you call the SFO() until it returns to your code to be approximately 735 cycles.

Robert Weggel said:

4. Is there any ability of the user/developer to restrict or further control the SFO() routine?

At this time there is no user ability to control the SFO() other than determining when they call it.  Depending on your application, the SFO() may not need to be called very frequently at all.  It is most important to call the SFO() after a change in temperature or voltage to recalibrate your HRPWM channels.  If your application doesn't encounter these conditions, running the SFO() once from start to finish should be adequate along with an occasional, non-frequent calibration.

Please let me know if this answers your questions.

Kris

Kris,

This is valuable information for anyone designing and intending to use the HRPWM. I appreciate your effort to gather this on my behalf. Perhaps a future revision of the Piccolo Tech Ref Man could include this information?

If I may, I'd like to ask one final question pertaining to the SFO() routine:

When the SFO() routine is active does it disable interrupts for any period of time, and if so, how long? I believe my design will tolerate the 735 cycle maximum, but only if the SFO() routine can be interrupted without additional latency in servicing that interrupt.

Thank you for your time and help!

Robert,

I will look into adding this into the documentation. Thank you for your suggestion.

The SFO itself does not disable interrupts. It does however contain some uninterruptible CPU instructions just as most user code would.  These should be no more than 10-30 cycles on estimate. If you need the exact number let me know.  Thanks,

Kris

Kris,

I think knowing an exact upper limit on the 10-30 estimate would be very beneficial to me. Knowing the maximum interrupt latency ahead of time will allow me to structure my code to call the SFO() routine at an appropriate time (where such latency is most tolerable).

I would very much appreciate that info if you are able to provide it.

Sincerely,

Bob W.