first of all many thanks for your detailed answers, that helps a lot !
I played a little bit around with the memory distribution but the program
acted totally unpredictable. Sometime the printf function worked, sometimes
not,
the PC jumped from one instruction to a complete different one and so on.
So I extremely increased the size for the stack (random but big value =) and
transformed
the hole project into a DSP/ BIOS project in order to use the LOG_printf
functions and because
it generates automatically a *cmd file.
In the DSP/BIOS configuration file I bumped every section (.text .bbs .data
etc.) into
the SDRAM that I created (I didn't go for performance but results =)....
It works now ( the main problem was the stack size)..... BUT SUPER SLOW ...
It needs about 7 minutes to encode a frame of Cif video (352x288)... but it
works =D
So the next step to do is what you guys proposed me in order to optimize
the memory usage... and of course read some papers...
I hope I can get out about 10 fps by optimizing the memory usage.
Thanks again
Dorian
-----Original Message-----
From: Andrew Nesterov [mailto:a...@techemail.com]
Sent: Tuesday, October 30, 2007 12:57 AM
To: c...
Cc: d...@redcodes.net
Subject: Re: Beginner Question: How to make a memory map ?
Hi Dorian,
Have you ever managed to load the executable? The memory map file
indicates that the application uses 600,000 bytes starting from
0x00000000, which wouldn't fit into DM642 on-chip L2 SRAM. I
guess that the example .cmd file specifies a single chunk of memory
0x00000000 through somewhere close to 0xFFFFFFFF?
C6000 (so far) implements a flat 32-bit byte-addressable physical
addresses memory. These 4GB are splitted into several address
spaces, some of them are on-chip, others are MMR (memory mapped
registers) and external RAM. Some of the address ranges are not
mapped into any existing memory at all, so that reading/writing
to these is unpredictable.
To determine what addresses your program can use, you need to
look at the device data sheet, which is available on the TI
web site, the lit number for the DM642 is SPRS200. Look at
the section 2.5.
The next step is the tech ref doc for your DM642 board. There
is another mem map table that specifies which CEs (external
memory) is populated and their physical size.
For example, the Spectrum Digital's EVM has 32MB (out of 256MB
possible) SDRAM populated on CE0.
There are 256KB of on-chip L2 SRAM physically present, which
cab be split into L2 cache and L2 RAM, see section 2.3.1 of
the data sheet.
The linker, memory, sections and the allocation algorithms
are specified in the SPRU186 7.5, 7.7, 7.8, etc.
Finally, a sample .cmd file might have a following configuration:
SECTIONS /* can be allocated into any of the above */
{
.vectors > VECTORS /* could go anywhere; by default must be here */
.text > EXTMEM0 /* .text is large and won't fit into INTMEM */
.cinit > INTMEMR /* others would probably fit */
.const > INTMEMR /* if not, they might fit into EXTMEM */
.tables > INTMEMR
.data > INTMEMR
.far > INTMEMR
.stack > INTMEMR
.cio > INTMEMR
.bss > INTMEMR
.switch > INTMEMR
.sysmem > INTMEMR
}
Andrew > Subject: Beginner Question: How to make a memory map
?
> Posted by: ".dorian" d...@redcodes.net dorian_schneider
> Date: Sun Oct 28, 2007 7:21 am ((PDT))
>
> hey guys,
>
> I am sorry for this post, I am sure most of you can't see these
questions
> anymore.
>
> I never worked with a dsp before and I have to port a Visual Studio x264
> based video encoder project
> to a dm642 board. The code compiles now in CCS 3.1, but the program acts
> completely weird. I think
> that is caused by my cmd file (I am using the one from the first tutorial) >
> Can you guys explain me how to write a good memory map, and what do I have
> to consider when managing the dsp memory ?
>
> I attached the *.map file from my project and appreciate your patience =)
> dorian
>
> ---------- ****************************************************************************
** > TMS320C6x COFF Linker PC v5.1.0
> ****************************************************************************
** >>> Linked Sun Oct 28 20:16:35 2007
>
> OUTPUT FILE NAME: <./Debug/x264enc.out>
> ENTRY POINT SYMBOL: "_c_int00" address: 00083120
> SECTION ALLOCATION MAP
>
> output attributes/
> section page origin length input sections
> -------- ---- ---------- ---------- ----------------
> .data 0 00000000 00000000 UNINITIALIZED
> .text 0 00000000 000837e0
> .const 0 000837e0 00009baf
> .far 0 0008d390 00004ee4 UNINITIALIZED
> .cinit 0 00092278 0000072c
> .cio 0 000929a8 00000120 UNINITIALIZED
> .bss 0 00092ac8 00000014 UNINITIALIZED
> .vectors 0 00092c00 00000200
> .stack 0 00092e00 00000400 UNINITIALIZED
> .sysmem 0 00093200 00000400 UNINITIALIZED
> .switch 0 00093600 0000022c
> 000937fc 00000030 >>>> 0009382b last addr
Reply by Andrew Nesterov●October 29, 20072007-10-29
Hi Dorian,
Have you ever managed to load the executable? The memory map file
indicates that the application uses 600,000 bytes starting from
0x00000000, which wouldn't fit into DM642 on-chip L2 SRAM. I
guess that the example .cmd file specifies a single chunk of memory
0x00000000 through somewhere close to 0xFFFFFFFF?
C6000 (so far) implements a flat 32-bit byte-addressable physical
addresses memory. These 4GB are splitted into several address
spaces, some of them are on-chip, others are MMR (memory mapped
registers) and external RAM. Some of the address ranges are not
mapped into any existing memory at all, so that reading/writing
to these is unpredictable.
To determine what addresses your program can use, you need to
look at the device data sheet, which is available on the TI
web site, the lit number for the DM642 is SPRS200. Look at
the section 2.5.
The next step is the tech ref doc for your DM642 board. There
is another mem map table that specifies which CEs (external
memory) is populated and their physical size.
For example, the Spectrum Digital's EVM has 32MB (out of 256MB
possible) SDRAM populated on CE0.
There are 256KB of on-chip L2 SRAM physically present, which
cab be split into L2 cache and L2 RAM, see section 2.3.1 of
the data sheet.
The linker, memory, sections and the allocation algorithms
are specified in the SPRU186 7.5, 7.7, 7.8, etc.
Finally, a sample .cmd file might have a following configuration:
SECTIONS /* can be allocated into any of the above */
{
.vectors > VECTORS /* could go anywhere; by default must be here */
.text > EXTMEM0 /* .text is large and won't fit into INTMEM */
.cinit > INTMEMR /* others would probably fit */
.const > INTMEMR /* if not, they might fit into EXTMEM */
.tables > INTMEMR
.data > INTMEMR
.far > INTMEMR
.stack > INTMEMR
.cio > INTMEMR
.bss > INTMEMR
.switch > INTMEMR
.sysmem > INTMEMR
}
Andrew > Subject: Beginner Question: How to make a memory map
?
> Posted by: ".dorian" d...@redcodes.net dorian_schneider
> Date: Sun Oct 28, 2007 7:21 am ((PDT))
>
> hey guys,
>
> I am sorry for this post, I am sure most of you can't see these
questions
> anymore.
>
> I never worked with a dsp before and I have to port a Visual Studio x264
> based video encoder project
> to a dm642 board. The code compiles now in CCS 3.1, but the program acts
> completely weird. I think
> that is caused by my cmd file (I am using the one from the first tutorial)
>
> Can you guys explain me how to write a good memory map, and what do I have
> to consider when managing the dsp memory ?
>
> I attached the *.map file from my project and appreciate your patience =)
> dorian
>
> ----------
>
>
******************************************************************************
> TMS320C6x COFF Linker PC v5.1.0
>
******************************************************************************
>>> Linked Sun Oct 28 20:16:35 2007
>
> OUTPUT FILE NAME: <./Debug/x264enc.out>
> ENTRY POINT SYMBOL: "_c_int00" address: 00083120
> SECTION ALLOCATION MAP
>
> output attributes/
> section page origin length input sections
> -------- ---- ---------- ---------- ----------------
> .data 0 00000000 00000000 UNINITIALIZED
> .text 0 00000000 000837e0
> .const 0 000837e0 00009baf
> .far 0 0008d390 00004ee4 UNINITIALIZED
> .cinit 0 00092278 0000072c
> .cio 0 000929a8 00000120 UNINITIALIZED
> .bss 0 00092ac8 00000014 UNINITIALIZED
> .vectors 0 00092c00 00000200
> .stack 0 00092e00 00000400 UNINITIALIZED
> .sysmem 0 00093200 00000400 UNINITIALIZED
> .switch 0 00093600 0000022c
> 000937fc 00000030 >>>> 0009382b last addr
Reply by Madhav G●October 29, 20072007-10-29
Hi,
Building / compiling a different platform source code using CCS .pjt doesnt
ensure the functionality or correctness of the application.
You need to use the .cmd file in your .pjt in order to map the sections and
get the modules working. But before you do anything below, you need to
understand how much accessible memory you have on your board.
Use #pragma CODE_SECTION() directive and map all functions in your .c files
to one common memory name, say, *myprg*. This myprg name can actually be any
name you wish...even dorian_prg!
Do the same way using #pragma DATA_SECTION() for all arrays and input
buffers and map these data arrays to,say *mydat*.
Build the project and open .map file. Look for myprg and mydat names in this
.map file. The numbers against these names is the actual memory requirements
and these do not include any RTS dependencies etc.,
With this actual program and data memory information, you are now in a
position to map the memories for correct functionality.
Sometimes, the myprg section can be huge. So, you may need to "break" and
map a few of your functions to myprg1 and remaining functions to myprg2
sections and accordingly map them in the .cmd file.
In your .cmd file, you see SECTIONS {} block. Map myprg > ISRAM and mydat >
ISRAM. In the MEMORY {} block, map ISRAM with some valid origin and length.
Ensure that the memories are are not overlapping with other named sections
in your .cmd file.
If this fails, that is, if you have insufficient memory to map, then you may
have to map a few sections onto SDRAM. In order to enable mapping to SDRAM,
your .gel file should contain the necessary SDRAM memory enabling
instructions. Like I pointed at the beginning of the mail, you need to
understand how much accessible memory you have on your board.
In CCS Help, you can look for #pragma, .sect, .text, .bss keywords to
understand what they mean and how they will help you.
I hope this helps!
BR,
-/Madhav
On 10/28/07, .dorian wrote: >
> hey guys,
>
> I am sorry for this post, I am sure most of you can't see these
questions
> anymore.
>
> I never worked with a dsp before and I have to port a Visual Studio x264
> based video encoder project
> to a dm642 board. The code compiles now in CCS 3.1, but the program acts
> completely weird. I think
> that is caused by my cmd file (I am using the one from the first tutorial
> =D).
>
> Can you guys explain me how to write a good memory map, and what do I have
> to
> consider when managing the dsp memory ?
>
> I attached the *.map file from my project and appreciate your patience =)
>
> dorian
Reply by ".dorian"●October 28, 20072007-10-28
******************************************************************************
TMS320C6x COFF Linker PC v5.1.0
****************************************************************************** >> Linked Sun Oct 28 20:16:35 2007