• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 1215 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.

TMS320F28377S: SFRA low frequency limit, SFRA application in temperature control

EK
Expert 2520 points
Part Number: TMS320F28377S
Other Parts Discussed in Thread: SFRA, CONTROLSUITE

Hi,

I like SFRA library for its great help optimizing 500kHz current control loop. But I would like also to use SFRA for slow 16Hz temperature-fan loop or ~100-200Hz temperature-TEC loop. Are there any low/high frequency limits in SFRA? I don't see this information in SFRA pdf. Can SFRA work for temperature control, where feedback always drifts up/down because of external factors?

And here's a problem:

I would like to start from 0.1 Hz, since FAN isn't fast thing and FAN PWM is limited to 16Hz. SFRA lib seems generating starting 0.1Hz frequency waveform well, I also clearly see injection response in temperature ADC, doble checked feedback variable and inject/collect calls. But SFRA kind of freezes forever and doesn't advance to next frequencies. Since there's nothing about frequency limits in the SFRA doc, I thought perhaps 0.1Hz is a problem? But I'm using floating point variant, also SFRA injection for 0.1Hz is working! I tried changing starting frequency to 10, 100Hz, almost always it takes ages to advance, in best case it takes few minutes to step to next frequency.

I tried 500kHz injection. It was better, but sometimes it takes ~10s to advance from starting 0.1Hz, and sometimes step takes over minute. I wonder what could cause such long and random delays? Does SFRA need N whole Finjection periods to collect data? Then why N is random? Is it all because temperature background always slowly drifts up/down, which perhaps upsets SFRA measurements and SFRA restarts for current frequency? Could any SFRA status variable reveal what's wrong? I see no explanation for status and state in SFRA pdf. 

Moving from 16 to 140Hz loop didn't help, still n random minutes to step.

Thanks,

Edward

  • 0
    TI__Mastermind 43730 points

    Edward, 

    1. There is no low frequency limit as such, but as SFRA was designed for faster control loops, we have only tested it at 0.5Hz and above. 

    2. Check systems with 10Hz bandwidth or so should not be a problem, we have to do this for voltage loops in PFC

    http://www.ti.com/tool/tidm-1007

     

    figure 40

    3. Few things you can do to speed up the SFRA execution. do fewer frequency points, i.e. only do 10 -20 points or so 

    4. Low-frequency sweeps are going to take longer time, sometimes playing slightly with the frequency value can put the SFRA out of a numeral accuracy issue if one frequency is taking significantly longer than the other. 

    5. Edward, yes if the ISR rate in which SFRA is called is that slow 16-140Hz it is going to take very long, unfortunately currently we do not have a mechanism to let the user tune the speed of SFRA compromising accuracy. I have added it to requirements for a future release when that happens. For now, i do not have a solution for it. 

    The only thing I can suggest is if you can run it slightly faster? I understand the bandwidth is very low and it does not need to run fast but that will help in the speed of execution. 

    Also, SFRA GUI freezing could be just SCI comms freezing up after some time. You can look at sfra object freqindex and see if it is incrementing. ?

  • 0 in reply to Manish Bhardwaj
    TI__Mastermind 43730 points
    Also you can try using the *.lib file located here

    C:\ti\controlSUITE\development_kits\tidm_1000\v1_01_00_00\f2837x\pfc3phvienna

    SFRA_FTMU_Lib.lib

    we have made some changes to TMU lib that can improve your execution time.

    This version of the lib is not yet part of the SFRA lib release under C:\ti\controlSUITE\libs\app_libs\SFRA

    but is in the pipeline to get released.
  • 0 in reply to Manish Bhardwaj
    Expert 2520 points
    Hi Manish,

    Thank you very much for information. I tried replacing SFRA lib with your pointed SFRA_FTMU_Lib. Haven't tried it with low freq loop yet, I noticed that after replacement it stopped injecting in closed loop mode. It was weird. I've two SFRA_F_INJECT calls in my program, one is called in open loop mode, and another in closed loop mode. Open mode works and closed mode injection stopped working. I changed linker setting to link again with original SFRA lib. The same! Perhaps linking order has changed. Looking at map file I found that SFRA lib has some data in ebss section. In my program linked for RAM, ebss is allocated in GS RAM above 0x10000 address. Changing ebss allocation to <0x10000 made SFRA inject working again in both, open and closed loop modes. Is there such ebss restriction? I'm unable to find it in SFRA pdf.

    re 3. Of course fewer points would speed up testing time, but if limits are unknown and it still can take ages to test with few points, then SFRA is not practical to use and Ziegler - Nichols step response looks better then, though I've no decent software for it and personel hates to perform it...

    re 4 and 5. Thanks for new requirements for new SFRA lib versions. Yes, I can rise ISR rate but can't rise FAN PWM frequency and ADC rate (quite slow sigma delta ADC, though for testing time it can I could switch other channels and rise it up to ~400Hz). What I see is that even at 500kHz ISR, both, SFRA and SFRA_FTMU are unpredictable, some poins are fast, and some points take enormously long. No problems for systems with few kHz bandwidths.

    I'll compare SFRA_FTMU_Lib vs SFRA and come back.


    Regards,
    Edward
  • 0 in reply to EK
    Expert 2520 points

    Hi,

    •  Looking at map file I found that SFRA lib has some data in ebss section


    Correction, it's not SFRA data in .ebss, but my SFRA.obj file.

    Its interesting, I moved every SFRA related data (magnitude, frequency vectors etc) to RAM addresses < 0x10000, still SFRA is not happy. Moving whole .ebss to < 0x10000 fixes SFRA injection, but placing .ebss again >0x10000 breaks SFRA injection. I've put breakpoint in disassembly window below LCR  SFRA_F_INJECT call. DP on return from inject call is 0x634, which is >=18D00 or RAMGS12, which is empty and not used at all. Moving .ebss again below 0x10000 and stopping in same place, DP is now 0x234, which points to internal SFRA_LIb variables like _SFRA_F_preCount etc.

    Any idea what else must be provided to not have problems with SFRA library? SFRA pdf instructs only to put SFRA inject and collect routines to RAM for best performance and to put SFRA_F_Data to dataRAM1, which is not explained what it is, must dataRAM1 be placed < 0x10000 or not. In my case SFRA_F_Data is allocated < 0x10000, I also tried putting SFRA_F_INIT , collect and inject also to RAM < 0x10000, it doesn't help. For some weird reason whole .ebss has to sit < 0x10000. Any idea why?

    Edit:

    SFRA_FTMU_Lib one point time seems being consistent with tested frequency. Each next step takes less time. This is better compared to SFRA_F_Lib. But 100Hz at 500kHz ISR takes about 5-6 seconds. 100 points from 100Hz to 200kHz take about 2.5minutes, which is about 5 times longed than SFRA_F_Lib, which finishes the same 100Hz - 200kHz 100 points in less than 30seconds. Well, if single 100Hz point using SFRA_FTMU_Lib takes 5 seconds, then 0.1Hz would take over an hour. Not good for such slow loops. I'll try it with PWM-TEC loop which is much more faster and I hope it will work. I'll try it later, no HW at the moment.

    Thanks

    Edward

  • 0 in reply to EK
    TI__Mastermind 43730 points
    Edward,

    Thanks for your inputs,

    1. the SFRA lib uses globals and hence does use items that are in ebss,

    On F2837x devices and above we have a much larger memory available on our devices than we had previously, our previous limit for 22 bits for address. The SFRA Lib is compiled with older version and also uses assembly code, that will be affected by this if the memory is in a higher range than addressable by 22 bits,

    with >0x10000 address space this might be getting violated and this may be causing the SFRA to break.

    I have filed two bugs

    a. re-compile SFRA with newer compiler version
    b. document the needs for the ebss to be in less than 22 bits space

    I apologize for the inconvenience.

    2.

    SFRA_FTMU_Lib one point time seems being consistent with tested frequency. Each next step takes less time. This is better compared to SFRA_F_Lib. But 100Hz at 500kHz ISR takes about 5-6 seconds. 100 points from 100Hz to 200kHz take about 2.5minutes, which is about 5 times longed than SFRA_F_Lib, which finishes the same 100Hz - 200kHz 100 points in less than 30seconds. Well, if single 100Hz point using SFRA_FTMU_Lib takes 5 seconds, then 0.1Hz would take over an hour. Not good for such slow loops. I'll try it with PWM-TEC loop which is much more faster and I hope it will work. I'll try it later, no HW at the moment.

    the mods for the SFRA TMU are still work in progress, our ultimate goal is to provide flexibility to the user to choose how long they want to let SFRA run.. unfortunatlely i don;t have a ready fix right now for you to make it smoother. We do have a bug filed against it, and it;s on our radar for improvements to make.

    Unless there is any additional information i can help with, i will move this post to "TI Thinks resolved", you can always open the thread back or start a new one .