I am using Ozone debugger tool from Segger for my project. I am new to this tool and still in learning phase.
My project deals with ARM Cortex M4 + M0 (SOC) with hardware floating point enabled.
System uses FreeRTOS as the operating system. I am running into following issue at the start up. I instantiated 3 threads and start the scheduler and run into hard fault.
Can you put a breakpoint near the beginning of your task(s) to see if control is reaching them? With some debuggers, the hard fault only looks like it happens in xPortStartScheduler() but really is happening in a task.
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.
At least we’ve ruled out the common causes of startup faults on CM4.
That code is attempting to read the initial stack pointer (MSP) from the vector table. Can you check your linker file for where the vector table resides? Based on your screenshot, the vector base register is pointing to 0x00008000. Maybe the vector base register (SCB->VTOR) has been set wrong?
I suspect ozone doesn’t care about the location of the vector table nor the value in SCB->VTOR.
Normally, the silicon vendor provides startup code that matches the basic linker files they provide, and so the startup code sets SCB->VTOR. You’d have to look at their code to see how they determine the value to write to SCB->VTOR to understand where things went wrong. For example, maybe you modified their linker file in an unexpected way. Maybe they anticipate you will use a bootloader but you don’t. Etc etc. Regardless, if you set SCB->VTOR early in main(), after all the C startup code is finished and before enabling any interrupts or trying to start FreeRTOS, you should be all set.