OMAPL138B-EP: Tools to debug memory problems

Hi Dmitry,

Have you identified where did the global variable got allocated to? Is there a difference in memory allocation between debug and release builds?

There is no tool to debug this specific case. Are you having any Cache Operations done on the global variables?

Dmitry Darashenka said:

DSP do something in memory like 0xE5xxxxxx

You have not shown in the memory region details, what is allocated in this memory. (Just curious).

Dmitry Darashenka said:

gloabl_var = 1"

Is this a sample global variable OR the actual variable you defined in the code and cause issues?

Thanks

Hi Avarind,

Aravind Batni said:

Have you identified where did the global variable got allocated to?

My global variable (waitId) allocated c4218140 (ARM) and c32a7a7d (DSP).  

Aravind Batni said:

Is there a difference in memory allocation between debug and release builds?

No.

Aravind Batni said:

Are you having any Cache Operations done on the global variables?

I don't have ideas about this. How to recognize this operations?

Aravind Batni said:

You have not shown in the memory region details, what is allocated in this memory.

I don't use this memory region and there are no such addresses in map file  like 0xE5xxxxxx.

Aravind Batni said:

Is this a sample global variable OR the actual variable you defined in the code and cause issues?

Above i mentioned my global variable waitId. I use this variable in ARM and DSP function:

uint8_t ipcWaitData(const uint8_t id, uint8_t* data)
{
uint32_t timeout = 0;
waitId = id; // When i add this line DSP stops to load

/*

/ commented code

*/

return IPC_WAIT_SUCCESS;

} 

Also i use this variable in another function and it works.

Thanks

Dmitry Darashenka said:

My global variable (waitId) allocated c4218140 (ARM) and c32a7a7d (DSP). 

Dmitry,

Are you expecting the global variable to be shared between DSP and ARM? If yes, you would need Cache Operations to be done on the global variable.

Example: If you are sharing WaitID from DSP with ARM (or vice versa). The variable is cached into Processors Cache lines. If you are making some decisions based on the global variable, you would need to flush the cache lines (Wb Inv) so that other core sees the values updated in the memory.

Also, to eliminate corruption on the global variable due to race conditions, you may need to protect the global variable from being accessed by both DSP and ARM (if you are sharing it) via Mutex.

Note that Release Build may produce a different data access timings and if Cache/Protections are not take care, it may produce some unpredictable results.

Let me know how you want to use the Global variable?

Thanks

Avarind,

Global variable isn't shared between ARM and DSP. It used to remeber what Id i requested from other processor.

Dmitry,

let me check with boot experts if there is something to be checked w.r.t. boot for below behavior?

Dmitry Darashenka said:

But after adding to some code lines (like "gloabl_var = 1", "Task_yield(), ..."), loading from bootloader becomes unpredictable

Please expect some delay on this.

Avarind,

Thanks for help. I will be waiting for reply.

Hi Dmitry,

I got below inputs from one of our bootloader expert.

"The behavior of the global variable and your code should not be impacted by the bootloader. The bootloader merely load the code on the DSP and the ARM and exits. The global variables will be loaded as they appear in the ELF sections that are part of the boot image."

Are you seeing different behavior over JTAG and using the bootloader?

Thanks