This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28379D: stack initialization from a shared portion of memory

Part Number: TMS320F28379D
Other Parts Discussed in Thread: SYSBIOS,

My customer is having a problem in which CPU2 execution does not start. It seems to hang in ti_sysbios_hal_Hwi_initStack(), in the while loop. The suspicion is that the stack is trying to allocate shared memory not yet released by CPU1. Can you please share ideas on how to debug this problem.

This problem only occurred after the RAM mapping had to be expanded this way (everything was working until then):

.ebss :>> D01SARAM | LS05SARAM | GS0_GS14_RAM   PAGE = 1

The hardware is the TMS320F28379D Launchpad.

The RTOS version is older: 2.12.01.33.

The file where the code gets stuck at line 83 is: tirtos_c2000_2_12_01_33\products\bios_6_41_04_54\packages\ti\sysbios\hal\Hwi_stack.c

The customer has the variable xdc_target__isaCompatible_28 defined, but my code examples do not have it. I do not quite understand the implications of this directive - I would appreciate if you could shed some light on it. 

It seems the contents of stkInfo are zero, which causes curStack to start at 0xFFFFFFFF. Is it possible that  Hwi ebss symbols are getting placed in GSRAM and at the time Hwi_initStack() is called, CPU1 has not yet given CPU2 ownership of those GSRAM sections?. 

If in debug mode we start CPU1 first and then start CPU2, the code runs fine.

Thank you!