How to enable heap in simulator?

Dear Rafael,

My CCS version is 4.1.2.00027 and I am using 6437 little endian simulator.

reading file said:

#include <stdio.h>

void main()
{
 FILE *fp;
 
 fp=fopen("doc.txt","r");
 
 
}

fp returns NULL every time.

Could you please check this attached project?

5531.test_file_IO.rar

Jim

Dear Desouza,

They worked well both in simulator and emulator, thanks very much for checking and modifying them for me.

Jim

Dear Rafael,

Rafael said:

heap does not need to be enabled in the simulator, since it is entirely defined by the code generation tools and physically it is common memory.

1. 
   The purpose of heap is for dynamic allocation, for example, used by malloc().
2. That you said heap is "not needed" is simulator, is because the simulator, and in a deeper layer the operating system, has already allocated and is managing a reserved heap for us.
3. It is because of the lack of software environments in 2, so that we need to manually specify heap size (-heap size) and location in linker.cmd.
   

Could you verify each of the points for me?


Another question is why does file accessing function such as fopen()/fread() require heap? Could you explain this to me?



Jim

Jimmy,

Jimmy Song said:

I would like to ask some questions:

1. The purpose of heap is for dynamic allocation, for example, used by malloc().
2. That you said heap is "not needed" is simulator, is because the simulator, and in a deeper layer the operating system, has already allocated and is managing a reserved heap for us.
3. It is because of the lack of software environments in 2, so that we need to manually specify heap size (-heap size) and location in linker.cmd.

 

1. Yes

2. No. The heap parameters (size and initial address) are entirely configured by the linker command file (the size can also be configured using the linker option -heap). Physically the heap does not differ from any other memory used in a regular program (code, data, stack, etc.). The device (simulator or hardware) just sees it as plain memory. When the executable file is loaded and executed on the device, the heap is allocated in the device memory before the code reaches main().

If by operating system you mean Windows (or Linux, etc.), they do not influence the heap allocation in the TI device (simulator or hardware). If you mean an operating system in the device (DSP/BIOS, for example), then it is highly likely that it configures the heap for you.

Check the references below that contain additional details and information.

http://processors.wiki.ti.com/index.php/Code_Generation_Tools_FAQ#Q:_What.27s_the_difference_between_HEAP_and_STACK.3F

http://processors.wiki.ti.com/index.php/Stack_and_Heap_size_requirements

http://en.wikipedia.org/wiki/Dynamic_memory_allocation

3. See above.

Jimmy Song said:

Another question is why does file accessing function such as fopen()/fread() require heap? Could you explain this to me?

Please check

http://processors.wiki.ti.com/index.php/Tips_for_using_printf#Heap_Size

Hope this helps,

Rafael

Dear Rafael,

Thanks very much for the explanation.

I was able to fread() and then fopen() a file, with neither

1. linker.cmd, not to mention its heap specification
2. Project->Properties->C/C++ Build->Linker->Basic Options->--heap_size: leaving blank

Why the file operation can still success? The link you provided
http://processors.wiki.ti.com/index.php/Tips_for_using_printf#Heap_Size

explains why heap is needed for file IO. So does my situation (1 & 2) even I am leaving --heap_size blank, CCS still defauls a certain value, which is not shown here?

And when options are specified both in linker.cmd and Linker->Basic Options, which value is actually used? Does the value in anyone overrides the value in another?

Sincerely,
Zheng

Zheng Zhao said:

I was able to fread() and then fopen() a file, with neither

1. linker.cmd, not to mention its heap specification
2. Project->Properties->C/C++ Build->Linker->Basic Options->--heap_size: leaving blank

If you don't specify anything, then the linker will use default settings (0x400 each for heap and stack)

Zheng Zhao said:

And when options are specified both in linker.cmd and Linker->Basic Options, which value is actually used? Does the value in anyone overrides the value in another?

The linker *.cmd file will be used in this case.

Zheng,

Just adding to Ki's response, to verify how much heap and stack are being actually configured (among other things) please check the linker map file <test_file_IO.map> in the output directory.

Regards,

Rafael

Dear Rafael,

test_file_IO.map said:

.stack     0    000034e0    00000400     UNINITIALIZED
                  000034e0    00000008     rts6200e.lib : boot.obj (.stack)
                  000034e8    000003f8     --HOLE--

.sysmem    0    000038e0    00000400     UNINITIALIZED
                  000038e0    00000008     rts6200e.lib : memory.obj (.sysmem)
                  000038e8    000003f8     --HOLE-- 

......

00000400   __STACK_SIZE
00000400   __SYSMEM_SIZE

I could find .stack, but not .heap, nor does searching for "heap" in this .map file return anything. Is heap and system the same thing? Or if not, does this file really contain heap size information?

Zheng

Dear Ki-Soo,

Thanks very much, this resolved many of my doubts.

Zheng

Zheng Zhao said:

I could find .stack, but not .heap, nor does searching for "heap" in this .map file return anything. Is heap and system the same thing? Or if not, does this file really contain heap size information?

Yes. See Section 7.1.3 of the compiler user's guide: http://focus.ti.com/lit/ug/spru187r/spru187r.pdf

Thanks

ki

Dear Ki-Soo,

Got it, thanks very much.

Still another question: What is the difference between an updated document and an older one?

For hardware modules, once the chip is released, I think it is not going to be changed (is it the fact?). Therefore, are updated hardware documents merely errata? What else can such documents update? Does TI really update their released type of hardware, like DM6437 1.0, DM6437 1.1, DM6437 1.2... during the years when the product is still active (being sold on the market)? That sounds unlikely to me, since if a hardware is enhacned it should then get a new model name, for example, from DM6437 to DM6438, like IPhone 1, 2, 3G, 4, etc.

Another possibility is that the new document version does not correspond to any update in the hardware, but just revision and correction on the previous released same document, containing less mistake (if the previous version had any mistake) than the previous version. Is this correct?

For new versions of software documents, the difference between a newer and an older one like:

1. TMS320C6000 Optimizing Compiler v 7.2 Beta SPRU187R, October 2010, which you just gave the link to me
2. and TMS320C6000 Optimizing Compiler v 6.0 Beta SPRU187N, July 2005

Since compiler is always included as part of the newly released CCS version, then does new version of a document reflect change in the new CCS? This question also applies documents of software other than the compiler.

Sincerely,

Zheng

ideally, you'll want to use the document that applies to your compiler version. The link I gave you was the latest version so if you are using older versions, Not all content may apply. However the info on the heap has not changed so I knew that content was ok.

This is a useful page on links to the user guides (including for C6000 6.0, 6.1)

http://processors.wiki.ti.com/index.php/TI_Compiler_Information#Compiler_Manuals

Otherwise I don't know too much about documentation versioning number and what exactly they mean. Sorry.

Also, it is good practice to ask new questions in a separate thread if the are unrelated to the existing thread. It helps people who search the forums for answers.

Thanks!

ki

Dear Ki-Soo,

Thanks for reminding. I will follow this in the future.

Zheng