FreeRTOS API documentation, function xTaskCreate() states that this function may be used with FreeRTOS-MPU:

“...
Using xTaskCreate() with FreeRTOS-MPU allows tasks to be created to run in either Privileged or User modes (see the description of uxPriority below). When Privileged mode it used the task will have access to the entire memory map, when User mode is used the task will have access to only its stack.
...”

It's wrong. In this case MPU region for task stack isn't being set up which causes task created in user mode crash system immediately after scheduler start.

“ It's wrong. In this case MPU region for task stack isn't being set up which causes task created in user mode crash system immediately after scheduler start.”

I have just stepped through the code, and am not sure the statement is right either, as a very quick look appears to show unprivileged tasks being given access to all unprivileged RAM not just the stack. However, I'm not sure your statement is correct either as I can create a task using xTaskCreate() and step into the task without a problem.

I do get an MPU fault, but it is from the check task, which is privileged anyway so it is curious.

I will need to look at that more, but have an urgent job to complete first.

Regards.

I didn't checked deeply and didn't notice that task being given access to all RAM. Also I didn't checked where crash happens exactly. Anyway, bug identified.

P.S. I've just figured out that even if you fix this it will not work in my case because of my heap implementation. I relocated whole heap to privileged_data section to protect system objects which are being placed there by freertos. I didn't considered task stacks because most of my tasks are created with xTaskCreateRestricted().