Application stops when executing prvPortStartFirstTask for CM4

Hello, i have created a freeRtos project for s32k142 (cortex m4), but when I call vTaskStartScheduler function the application will stop at address 0x0, when i debugged it it seems that this happen exactly at the function "prvPortStartFirstTask " especially here:

	__asm volatile(
					" ldr r0, =0xE000ED08 	\n" /* Use the NVIC offset register to locate the stack. */
					" ldr r0, [r0] 			\n"
					" ldr r0, [r0] 			\n"
					" msr msp, r0			\n" /* Set the msp back to the start of the stack. */
					" mov r0, #0			\n" /* Clear the bit that indicates the FPU is in use, see comment above. */
					" msr control, r0		\n"
					" cpsie i				\n" /* Globally enable interrupts. */
					" cpsie f				\n"
					" dsb					\n"
					" isb					\n"
					" svc 0					\n" /* System call to start first task. */
					" nop					\n"
				);

Any idea please, i am beginner in using freertos.

Does this forum thread help? Hard Fault encountered after vTaskStartScheduler is invoked

Hello, thank you for your reply
I have checked the link that you have sent:

  1. Can you put a breakpoint near the beginning of your task(s)
    Yes, but it didn’t reach any task

  2. Be sure configASSERT() is defined,
    Yes it is

  3. be sure you have a vApplicationMallocFailedHook() installed to catch out-of-memory and/or heap configuration errors.
    we are not using it because we have static tasks

  4. Check the priority of the SVC exception.
    Yes, and it is 0x00

  5. Does your FreeRTOSConfig.h have these lines:
    #define vPortSVCHandler SVC_Handler
    #define xPortPendSVHandler PendSV_Handler
    #define xPortSysTickHandler SysTick_Handler

Yes i have added them

  1. If all of that fails, can you step through the code and isolate the statement that is causing the hard fault? Note that you will need to put a breakpoint at the beginning of the vPortSVCHandler() to step into that function.
    I have put the breakpoint inside the asm code for both functions “prvPortStartFirstTask” and “vPortSVCHandler” but it doesn’t stop on any of them

You may have already checked, but the other possible solution on that thread is to check SCB->VTOR? Is it pointing at your application’s vector table?

I missed this in my reply above. Does program control never reach prvPortStartFirstTask()? I understood from your first post that the issue occurs somewhere inside prvPortStartFirstTask().

Can you post your entire project? Maybe attach it here or upload to github?

Hello Jeff, thanks for your reply,

yes it reaches “prvPortStartFirstTask” but once i arrive to it if do step over or step into it will go to unknown address, you can see the capture below:

In the capture, you can see also the VTOR address it’s 0xe000ed08, is there somewhere else where i can check it ?

Thank you

There may be some pointers in this here thread:

prvPortStartFirstTask() fails at SVC 0 - Kernel - FreeRTOS Community Forums

Thank you for your response, I will check them point by point.
I just wanted to add this screen which shows all the informations on SCB register, when it get stuck

Hello Jeff, about what you said here:

“I missed this in my reply above. Does program control never reach prvPortStartFirstTask() ? I understood from your first post that the issue occurs somewhere inside prvPortStartFirstTask() .”

Sorry, i was putting breakpoint here:

so it couldn’t enter there.

But now i actually put the breakpoint in the assembly code, and it reaches until the line "svc 0 ", as shown in the capture below:

image

then it goes to some wrong address like in the photo below:

image

I have put breakpoint in “vPortSVCHandler” function also, but it never reach it

Hi @Zak ,

The address of the VTOR register is 0xe000ed08, but the value is 0 as shown in either hex or binary column. After taking svc 0, mcu is jumping to the address stored in VTOR register which is 0.

It does seem like VTOR is not properly. Because, as per the picture above, value at address 0x0 is 0xffffffff. Can you please check the address where the exception vectors are located either from the.map or the linker script and load that value into VTOR by following prvPortStartFirstTask() fails at SVC 0 - Kernel - FreeRTOS Community Forums ?

Hello, but it will be zero only if i try to run it again, in that picture it’s just i have clicked run, that’s why it is set to zero, and i have just figured out that the micro-controller is actually reset, that’s why it went to zero, and when i checked the register that tells the reset reason “RCM” it says that it is a “core lockup reset”.
But if you checked the other picture it will shows the address when i just stuck:

Again, check with the thread mentioned here twice. It looks like exactly your problem. The solution is right there.

Hi @Zak this problem looks different to me than in the other posts. Your flash-borne vector table appears to be empty. Your picture of the flash contents at 0x00000000 indicates that part of flash (the vector table) is empty. But other pictures indicate that other parts of flash are not empty – they contain code. Pretty odd for your flash image to have code but an empty vector table.

Are you booting from RAM? That might explain how VTOR is 0x1FFFC080.

Can you check what values are in R0 before and after 0x0001242c executes?

Can you post your project on github or attach it here?

Hello guys, thank you all for your help
It worked now, and as always the problem was SCB->VTOR, in my case it was getting 0x1fffc080, which is not correct, the correct address is the beginning of m_data section (0x1fffc0a0), but somehow he is subtracting 0x20 from that whioch leads to VTOR address pointing to another section, i think it’s an alignment problem, because when i started m_data section form the address 0x1fffc100 it worked and the SCB->VTOR address is also 0x1fffc100.

But actually still i have another problem:
Now all the tasks are working but after some time some of them will stop working without any cause, but i will create a new topic for this.

Thank you

Thanks for reporting back @Zak .

From Armv7-M architecture manual:

The lower 7 bits of VTOR are reserved, therefore VTOR address should be 0x80 (128) byte aligned. Hence, 0x1fffc0a0 becomes 0x1fffc080.

2 Likes

Hello thank you for your explanation, yes you’re right, now it all makes sense.
Thank you