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.

TMS2803x EPWM / ADC clock rate problem

Hi All,

For some background, we have the ADCs running, driven by a EPWM. Now, our problem is setting the EPWM registers such that we would achieve a sampling rate of exactly 1.024 MHz. Moreover, we are running at 60 MHz ( TBCLK = SYSCLKOUT), therefore, the closest sampling rate we can achieve with the EPwm2Regs.TBPRD counter is a rate of 1.034 Mhz ( 60 / ( (59 -1) ).  Furthermore, we are aware of the following TBCLK = SYSCLKOUT / (HSPCLKDIV × CLKDIV) and both the DIV values are set to 1. Any hints to alleviate the problem would be appreciated. 

Thanks,

Arya B.

  • I don't think there is any trick that will help you; you will always have to divide the clock rate by an integer multiple.

    You should be able to get a 10.24MHz Crystal Oscillator, then run the device at 10.24 * 10 / 2 = 51.2MHz.  You can then set your ePWM to trigger every 50 cycles.

  • Devin, 

    Thank you very much for the rapid response, we were hoping there would be a better approach that would not cost us ~15% loss in CPU power. Do you think the CLA would have enough horsepower for decimation/interpolation ? Or are there any alternative ways of clocking the ADC that we may have missed ? 

    Thanks,

    Arya B.

  • If it helps, you should also be able to set the pll to 10.24*11 / 2 = 56.32 MHz and the ePWM to trigger every 55 cycles, which is only around 7% speed loss.  

    The CLA is very powerful, so you very well may be able to run your decimation/interpolation algorithms. I can try to work through the calculation with you of how long this would take, but you may need to provide some more specifics of what you are trying to accomplish in your system. 

    Alternatively, it may be easier to take the 7% clock rate hit but then offset that loss in MIPS by giving the CLA some simple tasks (instead of trying to use it to do decimation/interpolation).  

  • Devin,

    Thank you for the quick replies we highly appreciated it, the 7% seems much more manageable, especially if we could offload some tasks to the CLA. I would have to look into the details of the CLA as we have not been using it in our current firmware. To give you some background, our major task on this chip is to conduct fixed point FFTs which are sent over to a master over SPI. Now, would the CLA be able to manage the SPI portion of the system ? or would it be able to conduct parts of the FFT ( bit reversal, magnitude calculations ) or even all of the FFT ? Lastly, If you could share any detailed documentation on the CLA we would appreciated it.

    Thanks,

    Arya B.

  • The CLA user guide is here: http://www.ti.com/lit/ug/spruge6b/spruge6b.pdf

    Here are also some wiki articles: 

    http://processors.wiki.ti.com/index.php/C2000_CLA_C_Compiler

    http://processors.wiki.ti.com/index.php/Control_Law_Accelerator_(C2000_CLA)_FAQ

    http://processors.wiki.ti.com/index.php/Control_Law_Accelerator_(C2000_CLA)_Debug_on_CCS_FAQ

    It looks like the peripherals mapped directly to the CLA on the F2803x are the ePWM, HRPWM, Comparator, and ADC result registers.  You wont be able to directly control the SPI with the CLA (although the overhead to use the SPI once the module is setup should be minimal in any case - just write to the FIFO and it should take care of the rest).

    Based on this article, It also sounds like running the full FFT on the CLA may not work well, but you may be able to offload phase/magnitude calculations to the CLA:

    http://processors.wiki.ti.com/index.php/C2000_FFT:_VCU,_FPU_or_FixedPoint

    Based on this information, I would guess that the best way would be to use the CLA to control data collection from the ADC and also possibly control the ePWM (I am not sure if you are using the ePWM only as a timer, or if you also are controlling something with it). This would leave the C28x core to perform the FFT and copy data to the SPI FIFO

    If you run up against a wall with F2803x devices in terms of MIPS or want to add more functionality in the future, note that you have the option to move to F2806x devices.  These devices are up to 90MHz C28x + CLA + VCU (a co-processor which can be used to speed up 16-bit FFT) but are otherwise almost the same as F2803x devices.

     

  • Devin,

    Thank you very much for the detailed response, this is more than enough for us to get the ball rolling on the CLA. 

    We appreciate all your help.

    Thanks,

    Arya B.

  • Devin,

    Just to follow-up, we replaced the crystal with a 18.432, the PLL is set to 18.432*3/1 = 55.296 Mhz (DSP28_DIVSEL   3, DSP28_PLLCR    3, CPU_RATE   18.0845L). However, now the maximum sampling rate we can achieve is ~975 khz ( TBPRD = 56). Furthermore, if we set TBPRD < 56 our sampling rate drops from 975 kHz to a lower kHz value which is very odd. Keep in mind I have disabled all other tasks,  the CPU is just sampling.  Any help would be much appropriated. 

    Thanks,
    Arya B. 

  • Arya,

    did you consider to use the high-resolution PWM (HRPWM)? With HRPWM you can keep the 10MHz oscillator. By using register TBPRDHR you can adjust the PWM-period in multiples of 150ps  (see spruge8e.pdf).

      

  • Frank,

    I think the HRPWM would let Arya position the PWM edge with higher resolution than a 10MHz clock would allow, the trigger signal from the PWM to the ADC must cross back into the SYSCLK domain, which forces synchronization and therefore the loss of that extra resolution.  

    Arya,

    Could you be running out of time between triggers? How many ADC samples are you taking for each PWM trigger?  What is the ACQPS setting for these samples?  Do you have an ISR at the end of each sample?  

  • Devin,

    good point.  However, wouldn't it be possible to use the HR-PWM as an external trigger signal for the ADC?  This would require an additional wire betweeen ePWMxA and ADCEXT but would allow to use the standard 10MHz clock.

    Regards

     

     

  • Frank,

    The XINT mechanism synchronizes an external signal to SYSCLK.  

    Even if the ADC could be triggered asynchronously, the S+H window is generated from the ADC clock which is SYSCLK or SYSCLK/2.

  • Thank you both for a quick response, we really appreciate it.

    Devin,

    1. Could you be running out of time between triggers?
      1. That was our fear, however,  we have disabled all post-processing of the data, therefore, the CPU is only concerned with sampling. 
      1. Do you think if that was the case, would the CLA have a easier time collecting the samples ?
              
    1. How many ADC samples are you taking for each PWM trigger?
      1. We are taking a single sample for each trigger from one channel.
              
    1. What is the ACQPS setting for these samples?
      1. AdcRegs.ADCSOC0CTL.bit.ACQPS = 6; the bare minimum to achieve the highest sampling rate.
                      
    1. Do you have an ISR at the end of each sample?
      1. Yes, all we do in the ISR is store the data in a buffer and flag after we have 512 samples.
                 
                
    Some more information, we have the ADC ISR in the ramfunctions code section ( #pragma CODE_SECTION(adc_isr1, "ramfuncs") ), therefore, the ISR response time is not limited by the flash read speed. Moreover, we are buffering 512 samples from the single ADC channel. Lastly, keep in mind if switch to the 10Mhz (internal or external)  , we are able to achieve 1 Mhz+ sampling rates. It seems very odd that the ~8% loss in horsepower results in a much lower sampling rate.
    Thanks,
    Arya B.
  • One thing you should be aware of is the first sample issue in the F2803x errata (http://www.ti.com/lit/er/sprz295j/sprz295j.pdf). Instead of taking one sample, you are probably going to want to take two.  The total time this takes should be about 37 cycles, so it should still fit within your ePWM period.  This will also not affect the amount of CPU bandwith you will need to collect samples. 

    The easiest way to do this is to set SOC0 and SOC1 to both trigger off of the ePWM event.  The ADC will take care of sampling SOC0 then SOC1.  Just ignore the SOC0 sample (the channel select does not have to be set to the signal you are actually sampling).  

    I am not sure why you are seeing a drop off in sampling rate.  Can you confirm that TBPRD = 56 works with your original 60MHz setup?

    I think using the CLA to collect the data is a good idea.  My guess as to the best way to do this would be:

    • Have the CPU assign one of the two CLA data blocks to the CLA (1K words).  
    • Have the CLA move each ADC sample to its mapped buffer as they are collected.
    • Once the CLA has collected sufficient data(512 words?) it sends an interrupt to the CPU.  
    • The CPU switches ownership of both CLA data blocks (so it owns the one filled with data and the CLA owns the empty one)
    • In parallel, the CPU computes the FFT and the CLA fills the other buffer. 
    • The process continues indefinitely, with the CPU swapping buffers whenever new data is available.
    Also, if you want to save some bandwidth (should apply to CPU or CLA), you could let the ADC collect multiple samples before moving them to a buffer.  You would accomplish this by:
    • Setup two ePWMs, each with period 2x your original period. (also I think each ePWM has two compares, so you might be able to accomplish this with one ePWM module)
    • Have the first generate a SOC at halfway point and the other at the end of the period.
    • Have the first event trigger SOC0 (discarded sample) and SOC2(good sample) and have the second event trigger SOC1(discarded sample) and SOC3(good sample)
    • Trigger ISR after SOC3 and have ISR move result 2 and result 3 to buffer.
    You could also trigger the ISR after each sample.  This doesn't save you bandwidth, but it should give you more than twice as much time to move the samples to the buffer.  
    You can combine these two strategies with multiple synchronized ePWMs such that you have two ISRs, each which moves 4 good samples to the buffer. In your case, this should give you at least 56 * 4 = 224 cycles to move the 4 samples to the buffer. This should be way more than necessary, so you should have plenty of CPU or CLA headroom.
     
  • Devin,

    Thank you very much for your help and quick replies; it has been crucial to our development.

    Thanks,

    Arya B.