Hi Mateusz,
Now i can use SystemView to monitor the create of task and thread, but there's
no time sequence diagram in Timeline of SystemView, and there's no ISR info in
event window of SystemView, maybe there's some issue of RTT config on my nuttx.
Thank you very much if you would like share the nuttx RTT configuration of your
STM32F446RE board with me.
My config about RTT as shown below:
#
# Performance Monitoring
#
CONFIG_SCHED_SUSPENDSCHEDULER=y
CONFIG_SCHED_RESUMESCHEDULER=y
# CONFIG_SCHED_IRQMONITOR is not set
# CONFIG_SCHED_CRITMONITOR is not set
# CONFIG_SCHED_CPULOAD is not set
CONFIG_SCHED_INSTRUMENTATION=y
# CONFIG_SCHED_INSTRUMENTATION_SWITCH is not set
CONFIG_SCHED_INSTRUMENTATION_EXTERNAL=y
# CONFIG_SCHED_INSTRUMENTATION_PREEMPTION is not set
# CONFIG_SCHED_INSTRUMENTATION_CSECTION is not set
# CONFIG_SCHED_INSTRUMENTATION_SPINLOCKS is not set
# CONFIG_SCHED_INSTRUMENTATION_SYSCALL is not set
# CONFIG_SCHED_INSTRUMENTATION_IRQHANDLER is not set
# CONFIG_SCHED_INSTRUMENTATION_DUMP is not set
# CONFIG_SCHED_INSTRUMENTATION_HIRES is not set
# CONFIG_SCHED_INSTRUMENTATION_FILTER is not set
CONFIG_DRIVER_NOTE=y
# CONFIG_DRIVER_NOTERAM is not set
# CONFIG_DRIVER_NOTEARCH is not set
# CONFIG_DRIVER_NOTELOG is not set
CONFIG_SEGGER_SYSVIEW=y
#
# SYSLOG channels
#
# CONFIG_SYSLOG_CHAR is not set
CONFIG_SYSLOG_RTT=y
CONFIG_SEGGER_RTT=y
CONFIG_SEGGER_RTT_CPU_CACHE_LINE_SIZE=0
CONFIG_SEGGER_RTT_UNCACHED_OFF=0
CONFIG_SEGGER_RTT_MAX_NUM_UP_BUFFERS=3
CONFIG_SEGGER_RTT_MAX_NUM_DOWN_BUFFERS=3
CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=2048
CONFIG_SEGGER_RTT_BUFFER_SIZE_DOWN=32
CONFIG_SEGGER_SYSVIEW_RTT_BUFFER_SIZE=2048
CONFIG_SEGGER_SYSVIEW_RAM_BASE=0
Best regard
Zou
------------------ Original ------------------
From: "raiden00pl"<raiden0...@gmail.com>;
Date: Sun, Apr 3, 2022 09:35 PM
To: "dev"<dev@nuttx.apache.org>;
Subject: Re: The real-time performance of nuttx
Hi,
I just started analyzing the FOC example with SystemView and I found some
problems that can be connected with what you are observing.
My configuration:
STM32F446RE
CPU freq 180MHz
CONFIG_EXAMPLES_FOC_PWM_FREQ=10000
CONFIG_EXAMPLES_FOC_NOTIFIER_FREQ=10000
Context:
ISR34 - FOC ADC handler
ISR72 - Aux ADC DMA handler (VBUS + POT)
ISR15 - SysTick
ISR3 - Hard Fault
pt-0x - FOC control pthread (priority 255)
foc - FOC main, aux low priority work (priority 100)
1. Normal operation - FOC control thread executed every 100us
2. The first problem - system timer (in my case Systick - ISR15) drifts
according to PWM / ADC trigger (ISR34)
3. Previous causes the aux threads being woken up in random moments in relation
to the FOC controller thread
4. In the worst cases, this extends the time between successive calls of the
FOC controller thread
6. The last diagram presents a case that I don't fully understand. The FOC
control thread (priority 255) is interrupted by low priority thread (priority
100) - around 140.0 us
niedz., 3 kwi 2022 o 09:56 fft <f...@feedforward.com.cn> napisał(a):
sorry, the picture of last email was lost!
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
