What makes you think that? Can you share linker script?
Because it works fine when it is built for Flash, suppose the port works fine. Maybe not a good reason to think that way.
I tried to redesign the RAM linker file, but it gets worse. Before there is one scenario when it works fine. But now, it causes software interrupt in all scenarios.
Here is the RAM linker file, including the original one and the redesigned one.
notworkingRAM.zip (16.0 KB)
What you shared is not linker script but a map file which is output from linker. What did you do to make this change in the map file? Are you able to run from RAM without FreeRTOS?
Here is the linker file before and after.
notworkingRAM-linker.zip (2.6 KB)
Here is the task. There are two functions are exactly same. When using the original RAM linker file, there is one scenario that it works fine (New Temp Task is created statically). But when using the redesigned RAM linker file, it causes software interrupt in all scenarios. This is the main reason I think it is relevant to memory use.
notworkingRAM-task.zip (4.4 KB)
Yes, I am able to run it from RAM without FreeRTOS. It makes sense as the program enters software interrupt when calling portRESTORE_FIRST_CONTEXT().
And when the break point is set in the first line of the task function, it doesn’t hit.
I looked at the linker files you shared and I cannot find a difference between the original and redesigned other than some white space changes. Regardless, this seems related to the part and I’d recommend checking on TI forums.
This is seemingly random and may be a memory corruption. You can try increasing the stack size of the task.
Ok will checking there.
Thanks a lot Gaurav!