AnsweredAssumed Answered

ST7 instability with AN1905 sensorless BLDC motor control software

Question asked by indelible on Aug 13, 2010
Latest reply on Aug 16, 2010 by indelible
Hi everyone,

I apologize in advance for what is bound to be a very generic-sounding question, but I've been staring at this bug for a week and feel like posting here might at the very least be cathartic :)

I'm using the AK-ST7FMC motor control kit with the 3-phase sensorless brushless DC motor control software library described in AN-1905.  The chip itself is an ST7FMC2N6B6, and I'm using the Cosmic C compiler (in small memory model mode), STVD7, and an inDART-STX.  I am new to the chip, the compiler, the emulator...everything.

I've modified the software to start and stop the motor periodically.  I use Timer A to generate an interrupt at a selectable period.  From the Timer A ISR I invoke a callback function via a function pointer that in turn sets a flag indicating that it's time to start the motor.  The program's main loop sees the flag and calls MTC_StartMotor.  The D/C event ISR increments a counter with each autoswitched commutation.  The main loop periodically samples the counter and calls MTC_StopMotor when the counter passes a target threshold.  The sequence then repeats.

My problem is that occasionally the system will stop.  As near as I can tell, this happens during motor startup, between the time MTC_StartMotor is called and the time that the D/C event ISR enters autoswitched mode.  The system stops responding to keypresses and is just generally borked until a reset.  I believe that I've verified (through toggling a debug pin attached to a scope) that the D/C event ISR stops firing, the Timer B and Timer A ISRs stop firing, the main loop stops short, the chip is either executing code off in the weeds, or it is being held in reset, or something I don't understand is happening.  This occurs as long as the firmware is running from flash, whether the system is connected to the inDART or not. 

It is interesting to note that I've not been able to reproduce this issue when the code is being run on the chip directly from STVD7 via the inDART.  That doesn't mean it's not there, though.

So, I'm not asking you to solve this problem :)  What I am asking for, however, is any advice that you might offer me as I attempt to solve this problem myself.  I've reviewed my code.  I've ensured that writes to variables and function pointers that are accessed via ISR occur with interrupts disabled.  I've ensured that no functions are called from both ISRs and "main" program execution, because as I understand it function reentrancy is not supported given my configuration.  I've used the debugger to ensure that tables and function pointers have the appropriate contents.  I've reviewed the generated assembly language, examined the linker map file, and read up on the Cosmic C compiler and the ST7's memory models, calling conventions, and etcetera.  Unfortunately, I'm still stuck.

I suspect one of several things are happening: an invalid pointer is being dereferenced either as part of a function call or as part of a table lookup, an ISR is firing and not resetting its flag, causing it to hog forever, something is getting fouled up "stack"-wise (although as I understand it there might not be a call stack per se), or the chip is winding up in reset or power-down or something.

Being unfamiliar with this particular chip and toolchain, and being in somewhat of a hurry to put this bug behind me, my question (at last) is:

What would you do if you were me?  How would you go about finding the root cause of this issue?  Does anything that I've described raise a red flag based on your knowledge of the chip, the compiler, the demo kit, or my software design?

Any help that you could provide would be greatly, greatly appreciated, and I thank you in advance.