• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 641 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.

LAUNCHXL-F280039C: ADC sampling in symmetric PWM

David Capdevila
Prodigy 250 points
Part Number: LAUNCHXL-F280039C

Hello,

We are implementing a FOC algorithm in a BLDC motor. We are at the point where we have already the algorithm running and the inteerupts and ADC sampling are already working. However we foun out a problem that may affect a lot the ADC sampling and we do not know which should be the direction to follow. The following image represents a simulated PWM update where the control decides to increase or decrease a lot the duty cycle of the PWM.

The procedure in the control is as follows: ADC SOC trigger sampling of current in A, B and C. Then the FOC is executed and the Counter compare A is updated as soon as control finishes. The counter compare is shadowloaded so the true update will happen when the time base counter reaches 0 or the period value. The resulting waveforms are presented in the image. As you can see, because the counter compare is updated when timebase reaches the period, the PWM gets update in the falling edge of the high side, produceing a asymetric waveform.

The main problem is that the sampling is produced when the timebase reaches the period because it is suposed to be the average current value (i.e. the time that falls rigth in the middle of the PWM when is high). Because of the change of the compare value, the PWM middle value is not synchronized anymore with the timebase count period value. We are intereseted on having all pwm still synchornized to sample all of them at th same time and obting its average value.

One solution could be to update the compare values when timer reaches 0 before the timer starts increasing again. However, as you can se the control interrupt lasts 29us so it is not posible to update the pwm before. We would like to know which is the best path to follow in order to solve this situation.

Tahnks in advance,

David

  • 0
    TI__Genius 11036 points

    Hello David,

    I have one quick question for you before we continue. What event triggers the ADC SOC?

    Regards,
    Jason Osborn
    Note: Key takeaways from this post are bolded.

  • +1 in reply to Jason Osborn
    Prodigy 250 points

    Hello Jason,

    Thank you for your help. The SOC is triggered when the time base counter reach the PRD value. With the configuration up and down counter this value is the middle point when the pwm is high.

    Regards,

    David

  • +1 in reply to David Capdevila
    TI__Genius 11036 points

    Hello David,

    Thank you for the reply. First, I would note that generally, updating the CMPx value at the same time the ADC SOC begins is not ideal. 

    Second, have you considered moving the ADC SOC to CTR=ZRO or (as I've seen it implemented before to avoid the first issue) a small nonzero value, such as CTR=CMPC=5? If this event triggers the ADC SOC, your ISR should be finished with its calculations by the time you need to update the CMPx values at CTR=ZRO.

    Regards,
    Jason Osborn
    Note: Key takeaways from this post are bolded.

  • 0 in reply to Jason Osborn
    Prodigy 250 points

    Hello Jason,

    By mistake I marked somw replys as this resolved my issue. We have considered to trigger the ADC SOC near the 0 value. However, we discarded that option because at that point the current may or may not grow, depending on the pwm duty cycle. We decided to sample in the middle of the pwm so all the measures from the three phases at taken at the same point which should be the average current value.

  • 0 in reply to David Capdevila
    TI__Genius 11036 points

    David,

    If the ADC trigger source is a hard requirement, the most impactful suggestion I can give here would be to take a look at the interrupt and see if there's any optimizations or other refactoring you can do to get the ISR execution time lower than 29us.

    Alternatively, if you set the CMPx shadow to active load to occur at CTR=ZRO, the CMPx values would update 1 ePWM period behind the ADC calculations, but otherwise your system would be symmetrical.

    Regards,
    Jason Osborn
    Note: Key takeaways from this post are bolded.

  • 0 in reply to Jason Osborn
    Prodigy 250 points

    Hello Jason,

    Thank for your recommendations. I will try to optimize the ISR because the second alternative is not possible to be implemented, the control has to update the pwm as fast as possible avoiding any glitches when updating the CMPx.

    Regards,

    David

  • +1 in reply to David Capdevila
    TI__Genius 11036 points

    Thanks for updating me on the plan moving forward, David! I had a feeling that the CMPx calculations being a period behind wouldn't be a workable solution, but I wanted to mention the possibility for the sake of completeness. As for optimizing the ISR, we have a few optimization guides available for use here on ti.com- let me know if you need me to track down any that seem particularly relevant.

    At the most general level, minimizing the time spent in the ISR is key. Offloading tasks that are not time-critical to a slower background loop can often be helpful in doing that- that'd be things like updating physical or digital debug values (like setting status LEDs or digital debug displays), certain error checking tasks, etc. The Universal Motor Control Lab example solution in the C2000 Motor Control SDK can be a good reference for things that are typically safe to offload out of the ISR.

    If your efforts are successful, please let me know here and mark the thread resolved! If not, I'll still be available to help track down a working solution for you.

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Prodigy 250 points

    Hello Jason,

    Thank you for your recommendations. Would it be possible to receive those refrences you mentioned? I only know the optimization guide which i already follow.

    Also, I wanted to mention that for now we enable the optimzation and fpu in relaxed mode once we were sure the interrupt worked as expected. We are expecting to improve the code in the following weeks but for now we still have a lot of functionalities to implement. With the optimizations, we are able to work with a decent interrupt computing time but we will revisit the code. I hope I can contact you again for further recommendations.

    Regards,

    David

  • 0 in reply to David Capdevila
    TI__Genius 11036 points

    David,

    These are the two I recall. Happy to help!

    Regards,
    Jason Osborn

  • 0 in reply to Jason Osborn
    Prodigy 250 points

    Hello Jason,

    Thank you for your suggestions. However, I already know this guide, are there some other interesting application notes? I get lost while navigating on the documentation portal.

    Regards,

    David

  • 0 in reply to David Capdevila
    TI__Genius 11036 points

    David,

    Not that I can recall offhand, particularly without being able to see the code itself- hard to know what advice to give when I'm unsure what advice is needed! I'll continue looking and if I locate any, I'll send them your way. My final note on optimization, if you're unsure of what in your ISR is taking a particularly long time, would be to take a look at the assembly output of your ISR and see if anything is more complicated on the back-end than you anticipated. This can be a bit more confusing to look at, so I don't typically recommend it as a first step.

    If you are interested in searching for more information yourself and can't find anything relevant in our guides, I would recommend searching through any number of 3rd party general C-code optimization guides- all will generally tell you the same idea of minimizing time spent in an ISR, simplifying calculations with constants where possible, minimizing how often you need to make jumps, etc., but some may have specific advice more applicable to your efforts that I'm not aware of.

    Regards,
    Jason Osborn