• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 85 subscribers
  • Views 800 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28069M: ADC ISR frequency was unexpectedly reduced by half

Ram babu
Intellectual 260 points

Part Number: TMS320F28069M
Other Parts Discussed in Thread: MOTORWARE, C2000WARE

Tool/software:

Hello TI Team,

I hope this email finds you well.

I'm currently working on the Motorware project Lab05g and have encountered an issue regarding the ADC ISR frequency.

The path to my project is as follows: C:\ti\motorware\motorware_1_01_00_18\sw\solutions\instaspin_foc\boards\drv8301kit_revD\f28x\f2806xF\projects\ccs\proj_lab05g

I have successfully merged my custom code into proj_lab05g. The reference example for my custom code can be found at: C:\ti\c2000\C2000Ware_5_00_00_00\device_support\f2806x\examples\c28\adc_soc

The ADC ISR frequency of my custom code is 222 kHz.

However, upon building the merged code project Lab05g using ram_link_F28069F.cmd, I noticed that the ADC ISR frequency remains at 222 kHz.

Subsequently, when I attempted to build the project using F28069F.cmd for Flash programming, the ADC ISR frequency was unexpectedly reduced by half to 111 kHz.

I am seeking assistance on debugging this issue. Could you please provide guidance on how to address this discrepancy?

Thank you for your attention to this matter.

Best regards,

Ram Singh

  • 0
    TI__Mastermind 36526 points

    Hi,

    What are you using to trigger your ADC conversions? 

    Is everything running at half speed once you changed linker files? 

    Best Regards,

    Ben Collier

  • 0 in reply to Benjamin Collier
    Prodigy 150 points

    Hi Ben Collier,

    1. ADC Trigger Source is PWM

    2. Yes Every thing is running of half of the Speed.

    Thanks

  • 0 in reply to Nitish kumar Sharma
    TI__Guru* 86160 points

    Nitish,

    At the top of lab05 you will see the following:

    #ifdef FLASH
    #pragma CODE_SECTION(mainISR,"ramfuncs");
    #endif

    This places the main ISR(which in this lab looks to be tied to ADCINT) into RAM so that the execution speed will be at full CPU speed, the the code is built for flash option. 

    This is because flash memory cannot run at full CPU clock of 90MHz, but needs 3 Wait States at this speed.

    When you added your additional code from the SOC example, did you create a new ISR function/handler?  If so, and nothing else was modified the ISR likely resides in flash vs RAM and will execute slower.

    I'm not sure if this explains exactly what you are seeing, you mention ADC ISR frequency is half, if the ADC ISR has alot of code in it, it may be bandwidth limiting the ADC itself, i.e. the ISR is not done by the time the next ADC conversion is ready.  Would need your comment on how often you are triggering the ADC.  

    Since both sets of code use ePWM to trigger the ADC SOC, I can't think of a reason that the ADC SOC itself would be half RAM vs Flash, which is why I'm starting with the above.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Prodigy 150 points

    Hi Matthew,

    Thanks for your suggestion, I checked your suggestion and i found ok. during observation over i found the main loop is also getting very slower.

    To solve this issue i read a doc from TI  Running an Application from Internal Flash Memory on the TMS320F28xxx DSP (Rev. L) after i just configure the Flash Registers then its working fine. Slight smile

    Now I have a question, what was happening if i did not configure the Flash Register?

    Thanks

    Nitish Sharma

  • 0 in reply to Nitish kumar Sharma
    TI__Guru* 86160 points

    Nitish,

    The Flash Registers will be in their default state, which is maximum waitstates = 15.  So instead of ~22MHz(with correct WS =3), you would run equivalent of ~5MHz.  Code and data will still be read correctly, just much slower.

    It sounds like things are good, but if you need even less time in the ISR, you can look at what I mentioned about loading to flash and running from RAM, to get true 90MHz execution.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Prodigy 150 points

    HI Matthew,

    Thanks for your explanation. could you please explain more about  waitstate with some example for better understanding? I am not that much aware about it. please explain it.

    Thanks

    Nitish Sharma

  • 0 in reply to Nitish kumar Sharma
    TI__Mastermind 26590 points

    Hi Nitish,

    Matthew will be out of office until next Monday 6/24, please expect a delayed response. I apologize for any inconvenience.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    TI__Guru* 86160 points

    Nitish,

    The embedded flash on the F28069 device cannot run at the max CPU clock of 90MHz(11.1ns), but has a min access time of 36ns.  Here is the link to this in the device DS https://www.ti.com/document-viewer/TMS320F28069M/datasheet#GUID-72E3405E-30D3-401E-B08F-D6978CD6CAEF/TITLE-SPRS698SPRS6982410

    To avoid making the C compiler insert manual delays into the code, we have logic that can add wait states to each flash read to meet the above min.  Link above there is also a table listing the WS setting for each CPU clock; but if we do some quick math we get Flashws = (36ns/11.1ns)-1 =  2.24, and we round up to the next integer, for WS setting of "3".

    If we reduce the CPU frequency to 80MHz, that same equation give us a WS setting of "2", and so forth.  

    At boot up/power up, the device resets this field to max WS of 0xF, to ensure that no matter the initial clock rate the flash timings will be met.

    Let me know if this clears things up.

    Best,

    Matthew