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.

TMS320F28388D: QUTMR Latch

Part Number: TMS320F28388D

Hello Team,

Posting on behalf of my customer:

In the context of BLDC firmware. I use eQEP Edge Capture Unit to estimate the speed of the motor. The velocity/position loop runs at 10 kHz. To minimize delays and jitter, I don't rely on the UTIME module which isn't synchronized with the PWM interrupt. 

One solution is to configure QUPRD at 20 kHz and expect at least 1 UTOUT per velocity/position loop, but I have a high jitter. 

Another approach would be to manually force the UTOUT event with QFRC:UTO. However, the QUTMR cannot be latched at the same time. 

I guess this module is missing a QUTMR latch. What alternative do you recommend?

 

Regards,

Renan

  • Hello Renan,

    The eQEP expert is currently out-of-office until next Tuesday, so please give them until then to respond with their recommendation.

    Best regards,

    Omer Amir

  • Hello Omer,

    Any update?

    Regards,

    Renan

  • Hi Renan,

    For speed estimation using the edge-capture unit, what is the desire for latching the QUTMR as opposed to the QCTMR? You may configure the QEP capture latch mode of the eQEP to latch the value of the capture timer (and capture period) on UTOUT event (other option is when CPU reads the position counter) which you can then manually force in your QFRC:UTO bit within your PWM interrupt

    Regards,

    Peter

  • Hello Peter,

    Please see response from my customer:

    Considering my application, I have a 10 kHz velocity/position loop synced with EPWM interrupt, therefore I must be able to compute the position and the speed at this rate. Ideally, the ΔT (Time between UTOUT) would be exactly 10 kHz. The latched positions and events (QPOSLAT, QCTMRLAT, QCPRDLAT) would be done at the beginning of the ISR to ensure synchronicity between velocity acquisition and velocity control. There is unfortunately no mechanism to synchronize EPWM with EQEP module. It should be at least a way to start QUTMR at the beginning of the PWM ISR and ensure by configuring QUPRD that UTOUT is generated before the next interrupt i.e., 100 us later).

    On the other hand, low speed measurement should be performed when the uncertainty of high-speed measurement is bigger than the uncertainty of low-speed measurement. High-speed measurement uncertainty is dx/T, or about 6 rpm for a 100kcpr encoder and a T of 100 us. Ideally, QCPRD should saturate in less than T seconds (here 100 us). If UTOUT occurs before the next interrupt, we will be able to read QCTMRLAT and QCPRDLAT at the beginning of the next cycle.

     If UTIME module is not synchronized with EPWM interrupt, we cannot ensure that a single UTOUT is generated within each EPWM cycle.

    Regards,

    Renan

  • Hi Renan,

    I have consulted with another one of my colleagues and now we have a better understanding of the issue you are facing. Unfortunately, there is no way to latch the QUTMR (typically this wouldn't be needed since UTOUT event occurs whenever QUTMR = QUPRD and the timer value of interest would be QCTMR). Both EPWM and EQEP are clocked off of the same SYSCLK so ideally they should be running at the same frequency. Can you elaborate on what jitter you are getting when you configure QUPRD to issue UTOUT events at twice the frequency?

    One solution proposed would be to utilize another ISR (perhaps another synchronized PWM) which enables the QEPCTL:UTE right before you expect your velocity/position loop ISR to occur. This can be done only once and so you should see the UTOUT event at a constant frequency occur right before the velocity/position loop and have the QCTMR latched for you to make a speed estimation. If any drift occurs, you can simply utilize the other ISR to clear QUTMR and signal the QUTMR to begin counting again so that it should ideally be synced to your velocity/position loop. Do you see any issues in this approach?

    Regards,

    Peter