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

DRV8301 foc isr/period issue

asaygl
Intellectual 390 points
Other Parts Discussed in Thread: RM48L952, DRV8301, HALCOGEN, MOTORWARE

In RM48L952 foc project for the DRV8301 motor kit, foc period (T) is set as 0.00005in sys_main.h, which is then multiplied by 2490000 (vCNT_SCALE, not sure what it is but it seems it makes the pwm period 125 inside the het code and triggers the adc at half the period) to set the pwm periods. However, when I debug the code, rtiBenchmarkTime (the time it takes for the DRV_run function to run) shows as 0.00018 (about 18 us). Since the period, T, is used to estimate the speed too (speed_fr module), it needs to be very accurate, but it seems it is far off. I tried to set T as 0.0002 but the code didn't work. I think ADC conversion being complete triggers the DRV_run. Is there a way to use an accurate time difference, T, at the speed_fr module and also, is it possible to change the period and/or trigger the controller via an rti counter?

Thanks

  • 0
    TI__Expert 4225 points

    Hello Asaygl,

    1- we are running 20 KHz PWM period (50 us).  The CNT instruction in NHET is used as a virtual timer to count up.   The NHET LRP loop is 32 HRCLK or 32*VCLK2.  VCLK2 is 12.5 ns.  thus, to get to 50 us, we need 125 * 32 LRP * 12.5 ns/HRCLK .  Therefore, 0.00005*2490000=124.5 LRP counts.

    2- The RTI benchmark time is just a pure indication of how long the DRV run loop takes.  

    As an alternative, you can use PMU built-in cortex R4 (Halcogen can generate this PMU codes) to measure the number of cycles it takes for DRV run loop to execute.

    RTI counters are also used to delay the initial wait time for DRV8301 to power up (50 ms).

    Other than the two purposes above, RTI values should not be used by any other function in motorware code.

    The T is the defined period and is used to set up the speed calculation reference to the loop period.  

    The ADC triggering is synchronized to the PWM period.  

    There is no synchronization between PWM period and RTI counter. Therefore, we can not use RTI to trigger ADC S/H.

    NHET timer is used to trigger ADC synchronously to the PWM period, once ADC conversion completes, the DRV_run is called and run until completion of the loop.

  • 0 in reply to Henry Nguyen
    Intellectual 390 points

    Thanks for your reply! The card schematic shows a 16Mhz crystal, which would make VCLK2: 125 ns and T: 500 us, but I guess that is further pre-scaled to obtain 160Mhz. The speed measurement basically takes the difference between the two consecutive elec. theta values (within [0.1,0.9]) and divides them by the period, before applying the filters. But the time interval between these two theta values depends on the time it takes for DRV_run to reach the qep_run function. Everything should work fine if DRV_run completes its run before the next ADC trigger, thus in less time than 50 us (T), so the time difference always becomes 50 us, the period. However, rti_benchmarktime shows 0.00018 (which means it counts to 180, I wrote 18us before by mistake), and since RTI counts to 50,000 for 50 ms (at drv.c, there are also numerous comments which say 1 tick = 1 us), I assume 180 ticks means 180 us, which is much longer than the period T (50 us), which is what really confuses me.

  • 0 in reply to asaygl
    TI__Expert 4225 points

    Hi Asaygl,

    Actually, the VCLK2=12.5 ns and T=50 us, but it is just a pre-scale factor.

    On the qeu_run case, i think T is still correct.  Please consider the attached GIF file.

    You can see that since the s/w is totally synchronized to ADC S/H event (which is triggered synchronously to PWM period from the same timer), the delay time from eqep_run in one loop to the eqep_run in next loop is always T period.  

  • 0 in reply to Henry Nguyen
    Intellectual 390 points

    This code is used to delay 50 ms (at drv.c):

        //delay 50ms while DRV8301 powers up
        rtiResetCounter(rtiCOUNTER_BLOCK0);
        rtiStartCounter(rtiCOUNTER_BLOCK0);
        while(rtiGetCurrentTick(rtiCOMPARE0) < 50000);
        rtiStopCounter(rtiCOUNTER_BLOCK0);

    which basically states that 1 rti tick is 1 us. Drv_run calculates the #of ticks it took to run with the code (at drv.h):

      obj->rtiBenchmarkTime = obj->rtiCounterValue * (10E-6);     // 1 tick corresponds to 1us

    And that value is 0.00018 in average, or 180 ticks, which should mean it runs for 180 us if 1 tick = 1 us, as stated inside the code, or am I missing something again?

  • 0 in reply to asaygl
    TI__Expert 4225 points

    Hi Asaygl,

    i see what you meant.  Let me rerun and double check the clock setting for RTI.

    i did another independent measurement using PMU and it was around 18 us execution time in the past.

    For now, you can assume that it is ~18 us execution which is less than the ISR loop time. 

    So, eqep_run to eqep_run is always T period time.