• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 82 subscribers
  • Views 1735 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.

TMS320F28335 HVPM-BLDC FOC Example Code - Where does PIE enter into loop?

Tim Klein
Intellectual 580 points

Other Parts Discussed in Thread: TMS320F28335

Dear Sir/Ma'am,

I've reviewed the example code for the TMS320F28335 HVPM-BLDC FOC, and I'm having trouble discerning where the MainISR function gets called in the A-B-C (1ms-5ms-50ms) cycle loops.  I suspect that the MainISR is not part of the A-B-C loops, and instead is just an interrupt (the definition of PIE - Peripheral Interrupt Expansion) that "interrupts" the A-B-C loops to execute itself at the certain set frequency (10kHz in the example).  I don't understand where it is being called though.  What, specifically, is causing the interrupt to then be serviced?  I can't seem to understand where the PIEVectorTable is located...that would specifically have all the of PIE's listed out in order of precedence, correct?

Any help is greatly appreciated.  I have to put together an internal workshop that details the code for fellow engineers, so that they can effectively utilize and modify the example to fit their needs.  I have read the documentation that comes with it, and it has been a great help, but I need to start to point directly at the code.

-Tim

  • 0
    TI__Guru** 114905 points
    Hi Tim,

    Your post is being moved to the C2000 forum, where the experts on the firmware reside.
  • 0 in reply to Rick Duncan
    Intellectual 580 points
    Rick,
    Thank you for routing, but I'm not sure that will help to answer my question. I'm not interested in the inner-workings of the chip for the PIE - that is thoroughly detailed. What I need to understand is the CODE. Where in the code is the PIE assigned with executing the MainISR? Some of the documentation that goes with it states this is "int3", I believe. Where is this assignment made?
    -Tim
  • 0 in reply to Tim Klein
    TI__Guru 57255 points

    Tim,

    This is, in fact, the correct place for your question.  :)

    Your understanding is pretty much correct.  The A, B, C task state machine functions is code that is set to run whenever the ISR is not running. 

    In the code you're studying there is one ISR.  This one ISR is generated when ePWM1's timer becomes 0.  Because the PWM counts from 0 to some period value and then resets, this means that an ISR is called once every PWM period. 

    The PWM timer is also used to generate start-of-conversion pulses for the ADC.

    The first time the ISR is called, OffsetISR() is called to calibrate the ADC inputs by doing some offset compensation.  In subsequent ISRs, MainISR() instead is called.  MainISR is where the ADC is read, the control loop is performed, and the PWM is updated with the newest values from the control loop.

    Hopefully this helps.


    Thank you,
    Brett

  • 0 in reply to Rick Duncan
    Intellectual 580 points
    Rick, thank you for routing. My apologies for doubting.
    -Tim
  • 0 in reply to Brett Larimore
    Intellectual 580 points
    Brett,

    Thank you for this information. This is exactly what I was looking for helping me to understand. The slides in your next post are also a perfect!

    What I don't understand at this point is, if the A-B-C task state machine loop is only running when the ISR is not running, how does it keep an accurate timing of the state machine events? I think I know the answer, but need to confirm. The answer would be that the ISR only requires ~1000 cycles to operate, and the TMS320F28335 operates at 150Mhz or ~6.667ns/cycle, or ~7us-8us to execute; a maximum ISR_FREQUENCY of ~100 (kHz) is achievable if only the ISR is running. If the ISR_FREQUENCY is set to 40 (kHz), the timeframe is 25us, which means there is a computational-window of ~17us to run the A-B-C task state machine loops. If, in the running of the task state machine loops they take longer than this 17us (for this case), then they would simply be "interrupted" by the ISR, and resume their operation in the next window after the ISR once again completes. Please correct/update as you see fit.

    Thank you,
    -Tim
  • 0 in reply to Tim Klein
    TI__Guru 57255 points

    Hi Tim,

    Your understanding is correct.

    We rely on free, non-ISR bandwidth, to run the state machine.  This means two things:
    1) The A-B-C state machine tasks won't necessarily happen exactly every 1ms (or whatever period the task is set to).  For instance, if the ISR is running when task B1 should occur, the ISR will finish before B1 can run.  This means that the timing between the times that the B1 task is run will not be an exact amount of time.  We judge this to not be a big deal because the code in the state machine isn't super time critical.  If the timing of some code is critical, we could move it into the ISR. 

    * We also have the option to set up other interrupts (such as one for SPI or SCI), but there are some added concerns.  Specifically, we don't really ever want to delay the control loop ISR.  The way to minimize this best is to use only one interrupt, but the impact can be minimized if you utilize nested interrupts: http://processors.wiki.ti.com/index.php/Interrupt_Nesting_on_C28x
     
    2) We assume (and check) that the amount of non-ISR bandwidth is greater than the amount of bandwidth needed to run the state machine tasks.

    Hopefully this helps.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 580 points
    Brett,

    In the case for your #2, where you "assume (and check) that the amount of non-ISR bandwidth is greater than the amount of bandwidth needed to run the state machine tasks", would it be bad if it isn't? In the case I've detailed, what if the state machine only takes 5us to run through once? That is less than the remaining 17us or so until the next PWM interrupt and less than the 8us or so for the ISR loop. I would expect that it would simply run again in its never-ending loop. This wouldn't be bad, would it?

    -Tim
  • 0 in reply to Tim Klein
    TI__Guru 57255 points

    Tim,

    I believe your interpretation of my #2 is different from what I meant in #2.  If I take your interpretation, yes, any extra spare time will be spent in the never-ending loop.  This is not bad and is, in fact, good.  It is good to have spare cycles.

    My intention in #2 was the opposite - the situation where the amount of cycles it should take to run your A-B-C tasks is greater than the amount of cycles available between all the interrupts in the given task period.  For example, the case where I configure task C to get called every 1ms, but don't have enough cycles to finish task C in 1ms (along with the other tasks).

    (I do want to mention that some customers will naturally tend toward using an OS, like TI-RTOS, if the non-control tasks end up taking a lot of the bandwidth, there are many tasks and/or their timing is critical.  Many customers, however, may still prefer to keep determinism in the control loop ISR and would prefer to take an approach similar to the one shown in these application example projects)


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 580 points
    Brett,

    Thank you for that clarification. What you stated is what I expected, but obviously misinterpreted your statement.

    I'm going to look into the Nested-ISR you linked to above. While we plan to have the standard A-B-C loop with the Motor Controller running as the MainISR, we also plan to run an additional algorithm once per rotation at a specific point/time in the rotation as triggered by an external sensor. That is going to be interesting to try to implement, though I figure your Nested-ISR implementation will do the trick.

    Thank you for your input and to Rick for pointing me to you in this group.
    -Tim