6670: On loading image Target move to running state

Parshant Chowdhary

Other Parts Discussed in Thread: SYSBIOS

Hi All,

I have created a project on 6670. Initially i was using the 'Program.global.defaultheapinstance' of type HeapMem. Due to its undeterministic behavior, i have moved the default heap instance to HeapMultiBuf. After this change, when i try to load the program than target directly moved to running state instead of suspended. Earlier, it moved to suspended state with PC pointing to main function. It seems that somehow its init code corrupted. Could you have some suggestion about how to debug this issue?

Also, if i again make the 'defaultheapmeminstance' of heapmem type than program respond correctly.

Regards,

Parshant

over 11 years ago

0 Tom Kopriva over 11 years ago

TI__Mastermind 20480 points

Parshant,

what version of SYS/BIOS are you using?

Can you put a breakpont in main() and see if your apps gets there? If may want to disable the "run to main()" feature of CCS so you can step through the code starting from reset vector. See this forum post on how to disable the run to main feature for your debugger.

0 Parshant Chowdhary over 11 years ago in reply to Tom Kopriva

Intellectual 320 points

Hi Tom,

I am using

bios_6_33_05_46

Code Composer Studio

Version: 5.1.1.00031

I am not able to put break point in main, as target move to run state immediately after loading the image. So, I have also tried disabling the 'load and run to main' in genereal debugger options and put breakpoint in main, even than beakpoint not hit.

I would be needed some clues what all i can check to debug this issue.

Thank you for your support.

Regards,

Parshant

0 Naoki Kawada over 11 years ago in reply to Parshant Chowdhary

Guru 19890 points

Hi Parshant,

You are configuring your global heap instance named defaultheapinstance with HeapMultiBuf type.
So what do you see in your config file ?
Cdoc says that the following is a example for HeapMultiBuf configuration :

============

The following configuration code creates a HeapMultiBuf instance which manages 3 pools of 10 blocks each, with block sizes of 64, 128 and 256.

  var HeapMultiBuf = xdc.useModule('ti.sysbios.heaps.HeapMultiBuf');
  var HeapBuf = xdc.useModule('ti.sysbios.heaps.HeapBuf');

  // Create parameter structure for HeapMultiBuf instance.
  var hmbParams = new HeapMultiBuf.Params();
  hmbParams.numBufs = 3;

  // Create the parameter structures for each of the three
  // HeapBufs to be managed by the HeapMultiBuf instance.
  hmbParams.bufParams.$add(new HeapBuf.Params());
  hmbParams.bufParams[0].blockSize = 64;
  hmbParams.bufParams[0].numBlocks = 10;

  hmbParams.bufParams.$add(new HeapBuf.Params());
  hmbParams.bufParams[1].blockSize = 128;
  hmbParams.bufParams[1].numBlocks = 10;

  hmbParams.bufParams.$add(new HeapBuf.Params());
  hmbParams.bufParams[2].blockSize = 256;
  hmbParams.bufParams[2].numBlocks = 10;


  // Create the HeapMultiBuf instance, and assign the global handle
  // 'multiBufHeap' to it. Add '#include <xdc/cfg/global.h>' to your
  // .c file to reference the instance by this handle.
  Program.global.multiBufHeap = HeapMultiBuf.create(hmbParams);

===============

Does your configurations look like this ?
I think, if you wrongly configured the parameters for HeapMultiBuf, you could be in problem during HeapMultiBuf or HeapBuf startup functions.
These startup functions are called before main() if you configure the heaps with these types.

You can create a heap instance with the above example at first. And If you succeeded with this configuration,
You can now check the difference between the HeapMultiBuf parameters in cfg file.

Hope this helps.

Regards,
Kawada

0 Parshant Chowdhary over 11 years ago in reply to Naoki Kawada

Intellectual 320 points

Hello Kawada,

Sorry for wrong information earlier, from 'program.global.defaultheapinstance' i actually mean 'Memory.defaultHeapInstance'

Below is the part of my .cfg . So, in a case i keep it as below than target move to running state on loading image

//Memory.defaultHeapInstance = Program.global.heap0;

Memory.defaultHeapInstance = Program.global.heap1;

but if i make it

Memory.defaultHeapInstance = Program.global.heap0;

//Memory.defaultHeapInstance = Program.global.heap1;

than image load fine.

/* Create a Memory Heap in the DDR3 memory. */

var heapMemParams1 = new HeapMem.Params;
heapMemParams1.size = 0xA00000;
heapMemParams1.sectionName = "systemHeap";
Program.global.heap0 = HeapMem.create(heapMemParams1);

Program.global.heap1 = HeapMultiBuf.create(heapMultiBufParams);
//Memory.defaultHeapInstance = Program.global.heap0;

Memory.defaultHeapInstance = Program.global.heap1;

Regards,

Parshant

0 Naoki Kawada over 11 years ago in reply to Parshant Chowdhary

Guru 19890 points

Hi Parshant,

Ok. So I briefly checked the bios code and the following code looks generated during the configuration only if HeapStd is not being used:

Void ATTRIBUTE *malloc(SizeT size)
{
Header *packet;
xdc_runtime_Error_Block eb;

xdc_runtime_Error_init(&eb);

if (size == 0) {
return (NULL);
}

packet = (Header *)xdc_runtime_Memory_alloc(NULL,
(SizeT)(size + sizeof(Header)), 0, &eb);

if (packet == NULL) {
return (NULL);
}

packet->header.actualBuf = (Ptr)packet;
packet->header.size = size + sizeof(Header);

return (packet + 1);
}

This malloc() API will be overriden to standard malloc() and now malloc() will allocate memories from HeapMultiBuf instance.
So, if malloc() is being called before main() for something bios or runtime setup, I believe
you should not use HeapMultiBuf for the defaultHeapInstance and you will have to use HeapMem.
(This is just my suspicion... further explanation needs TI's help)

I'm wondering if your application allocates memories dynamically by Memory_alloc() with NULL heap instance.
In order to allocate memories from HeapMultiBuf instance, you can change the first argument for Memory_alloc just like below :

Memory_alloc (HeapMultiBuf_Handle_upCast(<your global heap multi buf handle>, ....)

Hope this could be one of solutions.

Regards,
Kawada

0 Tom Kopriva over 11 years ago in reply to Naoki Kawada

TI__Mastermind 20480 points

Hi guys,

to chime in here.

I'm a bit confused here. It looks like the Heap intialized in DDR3 (Program.global.heap0) works fine for you, correct?

Where is "Program.global.heap1" placed in you linker file? I'd check your .map file and see that it's placed in a valid memory section.

By the way, this HeapMultiBuf is massive! I'm curious if it would better to try a smaller HeapMultiBuf buffer and then increasing its size when you know it's working.

heapMultiBufParams.bufParams =
{blockSize: 1024, numBlocks:8, align: 128, sectionName:"systemHeap_1"},
{blockSize: 2048, numBlocks:4, align: 128, sectionName:"systemHeap_1"}];

If you don't assign a defaultHeapInstance in the .cfg file, then SYS/BIOS will assign it to HeapMem. Be aware that other SYS/BIOS modules may also be allocating memory from the defaultHeapInstace.

0 Parshant Chowdhary over 11 years ago in reply to Tom Kopriva

Intellectual 320 points

Hello Tom/Kawada,

Both heap1/heap 0 mentioned above are in DDR3. We have written code in C++ which use new/delete to allocate/deallocate memory. To achieve realtime requirements, we have changed the 'Memory.defaultheapinstance'

to HeapMultibuf. As per sysbios documentation, the memory allocation/deallocation using heapmultibuf is deterministic.

As C++ use vector/map which may have runtime memory requirements and we would like to fulfill all run time

memory requirements using HeapMultiBuf. So, Is there any other way in case 'defaultheapinstance' can not be a Heamultibuf ?

Regards,

Parshant

0 Naoki Kawada over 11 years ago in reply to Parshant Chowdhary

Guru 19890 points

Parshant,

I'm not sure about C++, but I think C++ should support overload.
How about overloading new/delete with your own new/delete using Memory_alloc(<heapMultiBuf> ...) and keep defaultHeapInstance to use HeapMem ?

Regards,
Kawada

0 Parshant Chowdhary over 11 years ago in reply to Naoki Kawada

Intellectual 320 points

Kawada,

Yes, overloading a operator but that would requires overloading of new for all the classes/structures and for map and vector we need to define allocators.

But if 'Memory.defaultheapinstance' a HeapMultiBuf than we do not need to take care the above things.

Although as TOM suggested, I have tried with smaller heap Multibuf instance

Program.global.heap1 = HeapMultiBuf.create(heapMultiBufParams);
//Memory.defaultHeapInstance = Program.global.heap0;
Program.global.heap2 = HeapMultiBuf.create(heapMultiBufParams1);
Memory.defaultHeapInstance = Program.global.heap2;

With this on loading the image Program stops on CSEXit with the following print on the console

[C66xx_1] ?[C66xx_1] [C66xx_1] [C66xx_1] [C66xx_1] [C66xx_1] [C66xx_1] [C66xx_1]

Regards,

Parshant

0 Tom Kopriva over 11 years ago in reply to Parshant Chowdhary

TI__Mastermind 20480 points

Can you see if ROV shows the HeapMultiBuf and HeapBuf modules? It should show how many blocks are available and such. Perhaps with the smaller heap configuration you're running out afterall...

I would suggest for you to try the SYS/BIOS C++ Example (blgtime), make sure it builds and runs, and then change the defaultHeapInstance. I was able to use the HeapMultiBuf module as the defaultHeapInstance with the bigtime example, but I tried it on a board I had laying on my desk (ARM). Are you using this on a custom board or some EVM?

When you said CSEXit, did you mean C$$EXIT? If you use the BIOS custom debug libraries you should be able to step through the pre-main intialization routine and see where it dies.

var BIOS = xdc.useModule('ti.sysbios.BIOS');
BIOS.libType = BIOS.LibType_Debug;

0 Parshant Chowdhary over 11 years ago in reply to Tom Kopriva

Intellectual 320 points

Hello Tom,

I have tried as per you suggestion.

I have found that code was running inside startup.c and crash in function Startup_exec(Crash Point. Startup_execImpl()

(Startup_execImpl)();

Yes the Function is C$$Exit. Now the console prints are

[C66xx_1] [C66xx_1] [C66xx_1] [C66xx_1] dc.runtime.Memory: line 52: out of memory: heap=0x0, size=265
[C66xx_1] [C66xx_1] =[C66xx_1] [C66xx_1] /

So, i have try to check HeapBuf in ROV at this point of time but target remain struck in Acquiring data.

Regards,

Parshant

0 Tom Kopriva over 11 years ago in reply to Parshant Chowdhary

TI__Mastermind 20480 points

The error you're seeing now basically says you don't have enough Heap.

Did the bigtime.cpp example work?

0 Parshant Chowdhary over 11 years ago in reply to Tom Kopriva

Intellectual 320 points

i Hello Tom,

In bios_6_33_05_46, bigtime.cpp does not have default heap instance as a heapMultibuf. So, I leave it and forward with my test program itself. Yes the problem seems to be heap is not enough, So i increase my heapbuf size. I increased the heap size to

but still i am getting the same error. From ROV not much help, On C$$Exit, it shows nothing has been allocated in any of the heap. I need some more information to identify why its not able to get the memory even ample of heap is there. Any informative log which shows that why it has not received '265' bytes. Do any SysBIOS module have some specific memory requirements?

Regards,

Parshant

0 Naoki Kawada over 11 years ago in reply to Parshant Chowdhary

Guru 19890 points

Parshant,

Sorry for the interrupt. I'm interested in this thread.

Let me confirm one thing - If you configured defaultHeapInstance with HeapMem, you could reach to main(). Then, if you try to allocate memory from HeapMultiBuf (such as Memory_alloc (HeapMultiBuf_Handle_upCast(<your global heap multi buf handle>, ....)) in main(), can you get some chunks ?
If you succeeded to get some chunks, it means the configurations for HeapMultiBuf itself should be ok. (but of course, you may need some optimization for HeapMultiBuf size).
I'm wondering if your HeapMultiBuf configurations are not looked like the script I suggested you before and it might be able to a problem.

Regards,
Kawada

0 Parshant Chowdhary over 11 years ago in reply to Naoki Kawada

Intellectual 320 points

Hello Kawada,

As i reported earlier, if i keep the below .cfg for default heapinstance

var heapMemParams1 = new HeapMem.Params;
heapMemParams1.size = 0xA00000;
heapMemParams1.sectionName = "systemHeap";
Program.global.heap0 = HeapMem.create(heapMemParams1);

Program.global.heap1 = HeapMultiBuf.create(heapMultiBufParams);
Memory.defaultHeapInstance = Program.global.heap0;

I would be able to reach main and get other allocation while running program. The program works fine. Using my own modified malloc, i give allocation to program dynamic mem requirements using HeapMultibuf defined above. In this case issue is, as i discussed earlier c++ lib new/delete would use default heap instance. As Heapmem behavior is undeterministic,

i think of to move defaultheap to multibuf also. This would start problem.

Regards,

Parshant

0 Parshant Chowdhary over 11 years ago in reply to Parshant Chowdhary

Intellectual 320 points

Hi All,

I have got chance to further analyze this issue. Using ROV, i have found the following errors

,ti.sysbios.family.c64p.Hwi,Module,N/A,hwiStackPeak,Overrun!

,ti.sysbios.gates.GateMutexPri,Detailed,(0x11872b50),pendElems,Error: Problem scanning pend Queue: JavaException: java.lang.Exception: Target memory read failed at address: 0x0, length: 8This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt.

,ti.sysbios.heaps.HeapBuf,Detailed,(0x11872210),freeList,numFreeBlocks: 3000 inconsistent with number of elements in HeapBuf.freeList: 0

,ti.sysbios.heaps.HeapBuf,Detailed,(0x11872238),freeList,numFreeBlocks: 220 inconsistent with number of elements in HeapBuf.freeList: 0

,ti.sysbios.heaps.HeapBuf,Detailed,(0x11872260),freeList,numFreeBlocks: 100 inconsistent with number of elements in HeapBuf.freeList: 0

,ti.sysbios.heaps.HeapBuf,Detailed,(0x11872288),freeList,numFreeBlocks: 25 inconsistent with number of elements in HeapBuf.freeList: 0

,ti.sysbios.heaps.HeapMem,Detailed,(0x11872bb0),totalFreeSize,Corrupted free list header next ptr (0x2) at freeList entry 0x11872bbc

,ti.sysbios.heaps.HeapMem,FreeList,HeapMem@11872bb0-freeList,Address,Bad next pointer = 0x2

,ti.sysbios.heaps.HeapMultiBuf,Detailed,(0x11872b70),N/A,Caught exception in view init code: TypeError: Cannot read property "length" from undefined

,ti.sysbios.knl.Queue,Basic,ti.sysbios.knl.Queue@11872b60,N/A,Caught exception in view init code: "C:/ti/xdctools_3_22_04_46/packages/xdc/rov/StructureDecoder.xs", line 517: java.lang.Exception: Target memory read failed at address: 0x0, length: 8This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt.

,ti.sysbios.knl.Task,Detailed,ti.sysbios.knl.Task.IdleTask,stackPeak,Hwi Stack Overrun!

,ti.sysbios.knl.Task,Module,N/A,hwiStackPeak,Overrun!

Regards,

Parshant

0 ScottG over 11 years ago in reply to Parshant Chowdhary

TI__Mastermind 26780 points

Parshant,

Given the messages indicating a Hwi stack overrun… can you try increasing the Hwi stack size and see if that resolves the issue? For example, add this to your application’s .cfg file, replacing a numeric value for "ABCD":

Program.stack = 0xABCD;

Scott

0 Parshant Chowdhary over 11 years ago in reply to Parshant Chowdhary

Intellectual 320 points

Hi All,

As suggested, I have tried increasing the Program.Stack and hwistackPeak overrun stops coming with

Program.stack = 16384;

From ROV, it seems that hwistackPeak is going up to 12000.

After this error stop coming, now ROV start showing taskstackpeak overrun. I increased in to value

Task.defaultStackSize = 1048576;

but still idle task stack peak is overrun. Any suggestion why idle task has such a huge requirements while initialization. How to determine the stack Peak for idle task?

Regards,

Parshant

0 ScottG over 11 years ago in reply to Parshant Chowdhary

TI__Mastermind 26780 points

Parshant,

What functions are running in the idle task, and what functions do those functions call? Do you have any that allocate large amounts of stack for local variables/structures?

Scott

Processors

Processors forum

6670: On loading image Target move to running state