On Sun, Apr 3, 2022 at 3:52 AM fft <f...@feedforward.com.cn> wrote:
>
> Hi team:
>
> I've been puzzled by a strange problem for a long time, when i use FOC
> motor control. It seems that the FOC control thread failed to be scheduled
> in real time. The code structure of ./apps/examples/foc/foc_float_thr.c can
> be simplified description is as follows:
>
> while (motor.mq.quit == false)
> {
> ...FOC control code...
>
> /* Get FOC device state */
> ret = foc_dev_state_get(&dev);
> if (ret < 0)
> {
> PRINTF("ERROR: foc_dev_state_get failed %d!\n", ret);
> goto errout;
> }
>
> ...FOC control code...
>
> }
>
> where foc_dev_state_get will be periodic blocked by waiting semaphore,
> and ADC interrupt periodic give semaphore.
> My custom board is based on stm32f405 and my config about foc as shown
> below:
>
> CONFIG_EXAMPLE_FOC_PWM_FREQ=20000
> CONFIG_EXAMPLE_FOC_NOTIFIER_FREQ=10000
> CONFIG_EXAMPLE_FOC_CONTROL_PRIO=255
>
> So, the FOC control code will be executed every 100us theoretically, In
> fact, this is true in most cases tested on real hardware, but there's
> sporadic unexpected states, that the execution interval between two FOC
> control is 120~170us, There's no effect when the motor speed is low, but
> when the motor speed is very high(up to 60000 erpm), this will cause
> serious problem, the motor may suddenly get stuck and burn. What puzzles me
> is the priority of FOC control thread already been set to the highest 255,
> and i have enabled the CONFIG_PRIORITY_INHERITANCE, why the FOC control
> threads was delayed so serious ? BTW, ther execution time of single FOC
> control loop is 60~70us, and there's 5 custom task in my case:
>
> Is my configuration incorrect or the real-time performance of nuttx can
> not meet the requirements?
> Does anyone else have the same problem?
>
> Best regard
> Zou
>
Without being able to test it is hard to give a definitive answer but I
would start by searching for a too-long critical section, which could be
anywhere, e.g., in some driver code, etc. That would pause the scheduler
and task switching, which would result in a delay to handle your FOC
control thread. It could be tricky to find that, so one way is to disable
various things and see if the problem goes away. Then that code could be
checked further for anything that pauses the system for too long.
The good news is that because your board is based on an ARM chip, you could
go another route and implement a Zero Latency Interrupt for the FOC control
based on a hardware peripheral timer. With a Zero Latency Interrupt you
will find that the latency (time from hardware timer firing to first
instruction in the interrupt) is less than 1 uS and jitter (variance of
latency) is measured in a very small number of nanoseconds.
Zero Latency Interrupts are discussed here:
https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=139629501#content/view/139629501
Cheers,
Nathan
