TPM Overflow Interrupt For MC9S08QE128 Demo Board.

[FWFan]

Hi All,

I am having trouble with the overflow interrupt for my TPM project.  I have a micro stepping routine and and a partial stepping routine.  I can get them to work separately, but when I combine them, only the micro stepping routine will trigger the overflow flag.  The partial stepping will not trigger the overflow flag isr.  I have kept everything in one file so it is rather long.  Hopefully, you could point out something I have missed.  The only difference with this version is that I have included a sci isr to command which stepping to activate.

Thank you,

FWFan

[FWFan]

I noticed that the counter does rolled over and the overflow flag does get set for the first time.  But the overflow isr does not get called so the flag never gets cleared.  Not even once.  The counter keeps counting down and restart at 100% cycle though.  

[bigmac]

Hello,

What memory model are you using?. Perchance would the ISR function be located in paged memory?

Regards,

Mac

[FWFan]

Hi Bigmac,

I am using the small memory model.  I got the micro step to work but not the partial step.  Perhaps, you can see this in the SCI ISR routine.  On an earlier version, when I don't use the SCI ISR routine, partial step would work, but only if it is activated by itself.

Thank you.

[FWFan]

I have confirmed that using the SCI ISR seems to interfere with the TPM overflow, but I cannot be sure.  I am trying polling SCI and this seems to be much better, but still only if I reset the TPM before using microstepping.  Of course, if I can fix the SCI ISR, that would be much better for the whole application.  I think.

[bigmac]

Hello,

Perhaps with your original code, the SCI ISR was taking too long to execute, and maybe you were missing TPM overflow events.  It all depends on your overflow period, and perhaps the baud rate to some extent.  All ISRs should be kept as short as possible, and the baud rate should not be too high, relative to the overflow period.

If you use SCI receive interrupt, the ISR action should be nothing more complex than writing the current character into a (circular) buffer.  The processing of the buffer characters should be done within the main loop code.  The ISR execution period should be significantly shorter than the TPM overflow period, or any other TPM interrupt period.  If this is not achievable, you will need to use SCI polling.

This would be the general approach.  Your code is a little too long to benefit from a cursory examination.  I am also not familiar with the process of microstepping a stepper motor.

Regards,

Mac

[FWFan]

Thank you Bigmac,

I see what you mean about the SCI ISR period and the TPM overflow period.  I really need to look into that if I want to go the SCI ISR route.  I know the main program is too long and not conventional.  I usually don't separate the routines until I get a lot working first.  But is this wise?

Thank you again for your valuable help.

FWFan

[rocco]

Hi FwFan,

There is a big difference between your "movMotMicroStp" routine and your "move_motor_partialstep" routine:

"movMotMicroStp" has no loops and just starts the motion. It exits immediately and lets the motion take place in the background.

"move_motor_partialstep" performs the entire move within a loop that will not exit until the motion completes.

When you call these routines from the SCI polling code, the TPM interrupts can occur because interrupts are enabled. But when you call these routines from the SCI interrupt service routine, interrupts are disabled. That doesn't effect the "movMotMicroStp" operation, because it exits right away, so the SCI interrupt service routine can also exit right away, re-enabling interrupts. But the "move_motor_partialstep" routine doesn't exit, and prevents the SCI ISR from exiting, so all other interrupts, including TPM interrupts, are blocked.

Hope that helps.

[FWFan]

Thank you Rocco.

That is very observing.  I knew about the difference between the two motor routines but I did know that the while loop in the partial stepping would prevent the SCI ISR to complete.  I need to rethink about the partial stepping routine if I wish to use SCI ISR.  Which I assumed is much more preferable.

FWFan 

[bigmac]

Hello,

The reason for using SCI receive interrupt is so that you do not miss any incoming characters.  However, neither of the functions MovMotMicroStp() nor  move_motor_partialstep() should be called from within the ISR code.  They should both be main loop functions that may be interrupted by the timer.

You need to be very wary of calling any function from within an ISR, because it may result in "hidden" side effects.  IMHO, if not making use of a function call within an ISR makes the code appear "too messy", the ISR is probably too complex.

To reiterate my previous post, the SCI ISR should simply place the received character into a buffer, and then exit.  Another main loop function should then interrogate whether the buffer is empty or not, and then process each received character.  This also includes to send any return character.

Regards,

Mac

[FWFan]

Thank you Bigmac,

I see what you are saying now.  What I need to do is capture the incomming command from the SCI ISR and save it into a buffer.  Then process this command in the main loop and call the appropriate function.  So the buffer needs to be a global variable.  I have never thought about this idea.  Thank you very much.

FWFan