task_yield results in hard fault.

[Eyal]

Hi.

I have a RAK5010 i use for iot application.

i recently moved from SDK 15.20 to sdk 16.
I use the task manager to manage two tasks:

1. task to dump nrf logs

2. task to handle the GSM and  main loop.

in the near future i do expect to add some more tasks or at least use more the task_Wait, for the time being each task is a for(;;) loop with task_yield in it's end.

since sdk 16 i have an issue with task_yield, the first task task yield works fine, the other task starts running and when it calls task yield i get hard fault. The hard fault occurs since the PC is 0x0000! the LR showed me the return address is just AFTER task_switch was called from task_yield function. adding SEGGER_RTT_printf also sows that (i wrap the task_Switch function with prints, both show).
That means that after the task switch for some reason the processor is sure 0x0000 is the right address to go.

Any hint on that would be appreciated, if it's my software that corrupts the stack before the task_yield call, how do i test that ?

[Edvin]

Hello,

What does the task_yield() function do? Is it something that you wrote? What does it do?

Are you sure you experience a hardfault, and not an APP_ERROR_CHECK()? I am just asking because these names are often mixed up. Does the log say anything?

I know nothing about your application. What do you use? Do you use the softdevice? Any RTOS?

[Eyal]

task_yield() is a function that is defined in task_manager.h. task manager is a, well, task manager that id provided in the "experimental" directory in the sdk, it's pretty much the same between sdk 16 and 15.2.
What does it do ? it assets your state that you are running with PSP and the right priority and access right and then calls a function called task_switch written in assembly.
Task switch chooses the next task that should run and performs arm m4 task switch operation.

After task_switch returns basically task_yield() should return to the PC where the previous task was yielded instead of the current task that called the "yield" function. There is a bug there so it seems that causes the PC to be 0.

[Eyal]

and yes i use S140 and the BT stack. i use the task switch since i dumped freerots, so no other rtos than the softdevice.

[Edvin]

Is there any way for me to reproduce this without the external GSM module? Does it happen immediately after startup? Or does it require a response from the GSM module?

Are you sure it is a hardfault, and not one of the asserts checks in task_yield()? Does the log say anything Hardfault related?

[Eyal]

i don't know if the GSM module is necessary i didn't check without it, i do know that  when it calls task_switch it gets hard fault for memory region 0x00000, yes it's a hard fault i got the hardfault module from the sdk compiled in and i checked the registers state when i got the breakpoint, it was definatly not an assert, what's more all the asserts are BEFORE the call to task_switch and the exception according to LR happens AFTER the return from the function.

[Edvin]

It is difficult to say exactly whats going on here. Perhaps you pass on a bad pointer somewhere (NULL) you change some data that is too long for the data type you are using somewhere in your code? What is in the SP register when you get the hardfault?