Hi Mateusz,

Thanks very much for your help, I finally caught the problem by SystemView, I 
found the  low priority FOC main task interrupt high  priority FOC control 
pthread and the problem led to the failure to complete the control of  this 
cycle, I think that's what caused my problem, but i don't know why,is puzzling!


Because my email always loses pictures,after send to  
"dev@nuttx.apache.org", whether pasted or attached, I have put the pictures in 
the link below:


https://github.com/apache/incubator-nuttx/issues/6012


Best regard
Zou
 

 
------------------ Original ------------------
From: &nbsp;"raiden00pl"<raiden0...@gmail.com&gt;;
Date: &nbsp;Sat, Apr 9, 2022 01:11 AM
To: &nbsp;"dev"<dev@nuttx.apache.org&gt;; 

Subject: &nbsp;Re: The real-time performance of nuttx

&nbsp;

For time sequence you have to enable the cycle counter, look at
https://github.com/apache/incubator-nuttx/pull/5964
To enable ISR logging CONFIG_SCHED_INSTRUMENTATION_IRQHANDLER=y.
In order to avoid the buffer overflow, I also recommend increasing
CONFIG_SEGGER_SYSVIEW_RTT_BUFFER_SIZE

pt., 8 kwi 2022 o 18:52 fft <f...@feedforward.com.cn&gt; napisał(a):

&gt;
&gt; Hi Mateusz,
&gt;
&gt; Now i can use SystemView to monitor the create of task and thread, but
&gt; there's no time sequence diagram in Timeline of SystemView, and there's no
&gt; ISR info in event window of SystemView, maybe there's some issue of RTT
&gt; config on my nuttx. Thank you very much if you would like share the nuttx
&gt; RTT configuration of your STM32F446RE board with me.
&gt; My config about RTT as shown below:
&gt;
&gt; #
&gt; # Performance Monitoring
&gt; #
&gt; CONFIG_SCHED_SUSPENDSCHEDULER=y
&gt; CONFIG_SCHED_RESUMESCHEDULER=y
&gt; # CONFIG_SCHED_IRQMONITOR is not set
&gt; # CONFIG_SCHED_CRITMONITOR is not set
&gt; # CONFIG_SCHED_CPULOAD is not set
&gt; CONFIG_SCHED_INSTRUMENTATION=y
&gt; # CONFIG_SCHED_INSTRUMENTATION_SWITCH is not set
&gt; CONFIG_SCHED_INSTRUMENTATION_EXTERNAL=y
&gt; # CONFIG_SCHED_INSTRUMENTATION_PREEMPTION is not set
&gt; # CONFIG_SCHED_INSTRUMENTATION_CSECTION is not set
&gt; # CONFIG_SCHED_INSTRUMENTATION_SPINLOCKS is not set
&gt; # CONFIG_SCHED_INSTRUMENTATION_SYSCALL is not set
&gt; # CONFIG_SCHED_INSTRUMENTATION_IRQHANDLER is not set
&gt; # CONFIG_SCHED_INSTRUMENTATION_DUMP is not set
&gt; # CONFIG_SCHED_INSTRUMENTATION_HIRES is not set
&gt; # CONFIG_SCHED_INSTRUMENTATION_FILTER is not set
&gt;
&gt; CONFIG_DRIVER_NOTE=y
&gt; # CONFIG_DRIVER_NOTERAM is not set
&gt; # CONFIG_DRIVER_NOTEARCH is not set
&gt; # CONFIG_DRIVER_NOTELOG is not set
&gt; CONFIG_SEGGER_SYSVIEW=y
&gt;
&gt; #
&gt; # SYSLOG channels
&gt; #
&gt; # CONFIG_SYSLOG_CHAR is not set
&gt; CONFIG_SYSLOG_RTT=y
&gt;
&gt; CONFIG_SEGGER_RTT=y
&gt; CONFIG_SEGGER_RTT_CPU_CACHE_LINE_SIZE=0
&gt; CONFIG_SEGGER_RTT_UNCACHED_OFF=0
&gt; CONFIG_SEGGER_RTT_MAX_NUM_UP_BUFFERS=3
&gt; CONFIG_SEGGER_RTT_MAX_NUM_DOWN_BUFFERS=3
&gt; CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=2048
&gt; CONFIG_SEGGER_RTT_BUFFER_SIZE_DOWN=32
&gt; CONFIG_SEGGER_SYSVIEW_RTT_BUFFER_SIZE=2048
&gt; CONFIG_SEGGER_SYSVIEW_RAM_BASE=0
&gt;
&gt; Best regard
&gt; Zou
&gt;
&gt;
&gt; ------------------ Original ------------------
&gt; *From: * "raiden00pl"<raiden0...@gmail.com&gt;;
&gt; *Date: * Sun, Apr 3, 2022 09:35 PM
&gt; *To: * "dev"<dev@nuttx.apache.org&gt;;
&gt; *Subject: * Re: The real-time performance of nuttx
&gt;
&gt; Hi,
&gt; I just started analyzing the FOC example with SystemView and I found some
&gt; problems that can be connected with what you are observing.
&gt;
&gt; My configuration:
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; STM32F446RE
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CPU freq 180MHz
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CONFIG_EXAMPLES_FOC_PWM_FREQ=10000
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CONFIG_EXAMPLES_FOC_NOTIFIER_FREQ=10000
&gt;
&gt; Context:
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ISR34 - FOC ADC handler
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ISR72 - Aux ADC DMA handler (VBUS + POT)
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ISR15 - SysTick
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ISR3&nbsp; - Hard Fault
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pt-0x - FOC control pthread (priority 255)
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; foc&nbsp;&nbsp; - FOC main, aux low priority 
work (priority 100)
&gt;
&gt; 1. Normal operation - FOC control thread executed every 100us
&gt;
&gt;
&gt;
&gt; 2. The first problem - system timer (in my case Systick - ISR15) drifts
&gt; according to PWM / ADC trigger (ISR34)
&gt;
&gt;
&gt;
&gt;
&gt;
&gt; 3. Previous causes the aux threads being woken up in random moments in
&gt; relation to the FOC controller thread
&gt;
&gt;
&gt;
&gt;
&gt;
&gt; 4. In the worst cases, this extends the time between successive calls of
&gt; the FOC controller thread
&gt;
&gt;
&gt;
&gt;
&gt;
&gt; 6. The last diagram presents a case that I don't fully understand. The FOC
&gt; control thread (priority 255) is interrupted by low priority thread
&gt; (priority 100) - around 140.0 us
&gt;
&gt;
&gt;
&gt; niedz., 3 kwi 2022 o 09:56 fft <f...@feedforward.com.cn&gt; napisał(a):
&gt;
&gt;&gt; sorry, the picture of last email was lost!
&gt;&gt;
&gt;&gt; Hi team:
&gt;&gt;
&gt;&gt; I've been puzzled by a strange problem for a long time, when i use FOC
&gt;&gt; motor control. It seems that the FOC control thread failed to be 
scheduled
&gt;&gt; in real time. The code structure of 
./apps/examples/foc/foc_float_thr.c can
&gt;&gt; be simplified description is as follows:
&gt;&gt;
&gt;&gt;&nbsp;&nbsp; while (motor.mq.quit == false)
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; {
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 ...FOC control code...
&gt;&gt;
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /* Get FOC 
device state */
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ret = 
foc_dev_state_get(&amp;dev);
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (ret < 
0)
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 {
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 PRINTF("ERROR: foc_dev_state_get failed %d!\n", ret);
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 goto errout;
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 }
&gt;&gt;
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 ...FOC control code...
&gt;&gt;
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; }
&gt;&gt;
&gt;&gt; where foc_dev_state_get will be periodic blocked by waiting semaphore,
&gt;&gt; and ADC interrupt periodic give semaphore.
&gt;&gt; My custom board is based on stm32f405 and my config about foc as shown
&gt;&gt; below:
&gt;&gt;
&gt;&gt; CONFIG_EXAMPLE_FOC_PWM_FREQ=20000
&gt;&gt; CONFIG_EXAMPLE_FOC_NOTIFIER_FREQ=10000
&gt;&gt; CONFIG_EXAMPLE_FOC_CONTROL_PRIO=255
&gt;&gt;
&gt;&gt; So, the FOC control code will be executed every 100us theoretically, In
&gt;&gt; fact, this is true in most cases tested on real hardware, but there's
&gt;&gt; sporadic unexpected states, that the execution interval between two FOC
&gt;&gt; control is 120~170us, There's no effect when the motor speed is low, 
but
&gt;&gt; when the motor speed is very high(up to 60000 erpm), this will cause
&gt;&gt; serious problem, the motor may suddenly get stuck and burn. What 
puzzles me
&gt;&gt; is the priority of FOC control thread already been set to the highest 
255,
&gt;&gt; and i have enabled the CONFIG_PRIORITY_INHERITANCE, why the FOC control
&gt;&gt; threads was delayed so serious ? BTW, ther execution time of single FOC
&gt;&gt; control loop is 60~70us, and there's 5 custom task in my case:
&gt;&gt;
&gt;&gt; Is my configuration incorrect or the real-time performance of nuttx can
&gt;&gt; not meet the requirements?
&gt;&gt; Does anyone else have the same problem?
&gt;&gt;
&gt;&gt; Best regard
&gt;&gt; Zou
&gt;&gt;
&gt;

Reply via email to