This function is used to setup the timer interrupt and it is not called periodically. If you are calling this function periodically, you are doing something wrong.
taskYIELD_WITHIN_API should lead to a call to vPortYield which should then enter FreeRTOS_SVC_Handler. Did you confirm the above using a debugger? Check if the SVC handler is installed correctly.
I think configSETUP_TICK_INTERRUPT() function was called periodically because ResetHandler() was called always, so the setup process executes periodically.
I have checked that SVC handler was not called.
That is the issue - figure out why that is not happening.
.align 4
.global vPortYield
.type vPortYield, %function
vPortYield:
SVC #portSVC_YIELD
BX LR
Above is the implementation of vPortYield, SVC #portSVC_YIELD will call SVC handler, right?
I found that line SVC #portSVC_YIELD was not called too.
When i comment line taskYIELD_WITHIN_API(); in timers.c, the ResetHandler() will not called periodically. So i doubt the issue related to section
freertos_system_calls which defined in ld script.
taskYIELD_WITHIN_API maps to portYIELD_WITHIN_API. Since ARM_CRx_MPU port does not define portYIELD_WITHIN_API, it defaults to portYIELD. ARM_CRx_MPU port defines portYIELD to vPortYield. How it is possible that a call to taskYIELD_WITHIN_API is not resulting in a call to vPortYield? How did you conclude that?
Yes, i am also very confused. But it is true.
.align 4
.global vPortYield
.type vPortYield, %function
vPortYield:
LDR R10, =0xb7000060
LDR R11, =0x1234
STR R11, [R10]
SVC #portSVC_YIELD
BX LR
For above debug codes,
I just dump the value for address 0xb7000060, and its value always be 0x0.
If the function was called, the value would be 0x1234. right?
I doubt that as i enabled the MPU, maybe vPortYield int section freertos_system_calls was not be called correctly. When it was called the program would trigger a memory access error and ran into ResetHandler().
If there is free time, we can double check the sections definition in ld script and MPU sections definition together.
I’m truly grateful for your support.
Refer to this linker script and see if you are doing everything correctly. One thing I can see is that you are not setting __syscalls_flash_length__.
I found there is a R5F version: r5f
Can i reference this one?
Yes, that should be fine.
I did a test using below codes to instead taskYIELD_WITHIN_API() and called inline:
__asm volatile (
"SVC %0\n"
"BX LR"
:
: "I" (portSVC_YIELD)
);
SVC handler was called correctly.
So it is clear now, when functions in section freertos_system_calls were called, program will ran into ResetHandler().
I have updated my ld script follow Ti R5F example, but still the same issue.
Please share your linker script.
please help to check, thanks a lot.
This conclusion is incorrect. When a SVC call is raised from a section other than the system calls section, this code makes it no op.
I notice that your startup code does not initialize the data section and that may be an issue. Do the following experiment:
/* Define a global variable and set it to a non-zero value. */
uint32_t var = 0xABCD1234;
int main( void )
{
if( var == 0xABCD1234 )
{
/* Leave a marker here. */
}
else
{
/* Leave a different marker here. */
}
}
See whether the variable is set to correct value in main.
The test result is:
var == 0xABCD1234
it seems the data section has been initialized.
Can you share the code which initializes the data section? Does the also initialize the privileged data section correctly?
Most of the codes have been uploaded to my repo,
I think the initializes take place in file boot.S file
You can check it, thank you very much.
I have seen that already and I cannot find it in that. Can you do the same experiment while placing the variable in privileged data section:
/* Define a global variable and set it to a non-zero value. */
__attribute__( ( section( "privileged_data" ) ) ) uint32_t var = 0xABCD1234;
int main( void )
{
if( var == 0xABCD1234 )
{
/* Leave a marker here. */
}
else
{
/* Leave a different marker here. */
}
}
The test result is:
var == 0xABCD1234
Thank you for sharing the result. Data initialization is fine. We need to figure out which instruction is causing reset. Having a debugger would be really helpful to nail down the problem. Is it possible for you to get debugger setup?
Sorry, i have checked that the R5 can’t be debugged using T32.
Because hardware design.
Do you have other debugging methods which can help to find the instruction causing reset?
Thank you.