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> napisał(a):
>
> 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
>>
>
