开启任务调度循环亮灯 单步调试怎么会卡死在 xPortStartScheduler();并且灯只亮不灭 是不是滴答定时器时钟没设置对 一直不能正常使用任务，会是哪里没有设置好 按照正点原子stm32f4的移植教程学的
Hello @wangp,
better post in English to make others life easier to read and answer your question 
So I hope Google translate was right … 
xPortStartScheduler starts FreeRTOS task scheduling and doesn’t or shouldn’t return, if this is what you mean with stuck. It might be also a good idea to put a breakpoint at your task function to see that the task is sucessfully started.
Yes, FreeRTOS requires a system ticker (default: SysTick or an alternative timer with an adopted Timer ISR calling FreeRTOS vTaskIncrementTick.
I’d strongly recommend to define configASSERT and enable FreeRTOS - stacks and stack overflow checking during development.
Breakpoint debugging card in the xPortStartScheduler function, and then can not break the point, stack check I see the tutorial is set to 0 closed, I this project is from a normal use of the bare metal project transplant, bare metal project everything is normal, the tick timer clock is not I do not need to set up
So you’re using the default SysTick ?
yes ,But I was on a business trip yesterday and I’ll look at changing the clock today
I tried to initialize the timer according to the systick timer of stm32f407. The difference between gd and stm was only in the clock, stm’s was 168M, gd’s was 200M,fuck, but the task could not be used. After initializing the two lights, I tried to use only one light to achieve a water lamp, but both lights were always on
When using the default SysTick you don’t need to do anything. It’s all done by FreeRTOS.
Did you have a look at Microcontrollers and compiler tool chains supported by FreeRTOS and/or
https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS/Demo for a good starting point ?
And did you hit a configASSERT when running your application ?
Which FreeRTOS version/port do you use ?
The latest 12.01, does it have anything to do with the latest version? Why don’t I try version 9.0
No. It’s just good to know which version is used
It’s good that you ‘re using the latest version since FreeRTOS is continuously improved also in regard to internal error checks (using configASSERT statements).
Did you enable it along with the stack checks ? It’s very helpful for development !
Now, the task function goes in, runs once, and it gets stuck. The tick timer is not set, is it
The stack check hook function is disabled by me and anyone else can use it. What should I have set up right
The code of the task creation and task function would help.
Also the FreeRTOSConfig.h
I’m sorry I’m an idiot. There’s nothing wrong with my port Settings. I used the task incorrectly. There’s a delay function that uses the tick timer delay function instead of vTaskDelay
The problem solves the porting problem. There is no use problem, and the porting does not need to change the clock. The ticking timer that was already set by the original bare metal project will also work
1 Like
By the way, you can’t configure interrupts again or freertos won’t be able to get up and I don’t know what the reason is, so I’ll just comment out the interrupt configuration and the system will work, okay
Interrupts have to be handled with care Depending how they are used, of course.
A common problem is enabling interrupts too early. That means for instance if the ISR uses FreeRTOS calls like xTaskNotifyFromISR or xSemaphoreGiveFromISR and the task or the semaphore is not yet created (their handles are invalid), but the ISR is already invoked and tries to use them. But those issues are usually catched by the mentioned configASSERT.
It’s a good approach to enable interrupts in a task, which will handle the task notification or a semaphore signaled by the corresponding ISR.