Hello,

I'm working with a TI C6713 processor. It has external SDRAM that is
connected via EMIF (CE2).
So I have a memory section called SDRAM in my cdb-file that has 0xb0000000
as its base and 0x01000000 as its length (16M).

The problem is:
When I allocate memory with malloc(), i can watch the desired variable in
the watch window, and so I can see the pointer address to that variable. But
the pointer doesn't point to a space within the numbers above! For example
allocating an array gives me something like 0xAFFFF848 or similar values. I
also received 0xbebebebe which is out of range as well. What can be the
problem??

The code section I use (it is C code of numerical recipes, not really
optimized and conventional C code, but it works):

with L=50 and M=401 (defined as preprocessor directives)

r=vector(1,L+M);

with the function vector like below:

#if defined(__STDC__) || defined(ANSI) || defined(NRANSI) /* ANSI */

#include
#include
#include
#include "complex.h"
#define NR_END 1
#define FREE_ARG char*

float *vector(long nl, long nh)
/* allocate a float vector with subscript range v[nl..nh] */
{
float *v;

v=(float *)malloc((size_t) ((nh-nl+1+NR_END)*sizeof(float)));
if (!v) nrerror("allocation failure in vector()");
return v-nl+NR_END;
}

For this one I think I got the 0xAFFFF848 address.

What can I do?
Certainly, I cannot perform calculations upon the allocated arrays, because
they are not in a valid memory section, so this is really bad for me.
When I did the same thing in the internal RAM, everything was fine (for
smaller arrays for sure), but now I need a huge amount of memory because I'm
working with big matrices, and so I have to change my dynamic memory section
to the SDRAM.

Thank you!

Simone

Thank you!

From:	Simone Winkler
Subject:	Re: C6713 external memory problem
Date:	Wed, 19 Jan 2005 18:06:41 +0100

I could solve some of the problems...
I am now able to statically allocate a variable in my SDRAM (which isn't
that easy either...)
You simply define your own additional cmd-file like below:

SECTIONS {
.userdef: {} > SDRAM
}

and in the source code you use

#pragma DATA_SECTION(test, ".userdef");
unsigned int test[10];

--------------------------------------------------

BUT: I still have problems with malloc(), it always gives me a NULL pointer.
So I tried to use MEM_alloc by entering SDRAM as segid:

MEM_alloc(SDRAM,0x3000,0);

But it doesn't recognize the symbol SDRAM!! I also tried IRAM and lots of
other things.... It simply doesn't know the identifier SDRAM as though I
really know and see in my cdb-file that its name definitely is SDRAM....!!
My cmd-file really knows the symbol SDRAM, I verified that. I also tried
_SDRAM, because sometimes DSP/BIOS needs all the functions with an
underscore in front of them. None of my attempts worked...

Do you have ANY idea???

Thank you very much...

Simone Winkler

From:	Andreas Huennebeck
Subject:	Re: C6713 external memory problem
Date:	Thu, 20 Jan 2005 09:41:43 +0100

Simone Winkler wrote:

> BUT: I still have problems with malloc(), it always gives me a NULL
> pointer. So I tried to use MEM_alloc by entering SDRAM as segid:
>
> MEM_alloc(SDRAM,0x3000,0);
>
> But it doesn't recognize the symbol SDRAM!!

That is right. Please read the chapter "MEM module" (2.14) in TI's
DSP/BIOS API Reference Guide:

1. You have to call MEM_define first. 'base' should be the address
of your SDRAM, and you must #define SDRAM by yourself, e.g. if
SDRAM starts at 0x80000000, then

#define SDRAM 0x80000000

should do (you may have to cast it to void*).
MEM_define returns the segid for use in MEM_alloc.
2. As far as I remember you must have at least two heap segments
if you want to use the MEM module.
3. I don't think that using the MEM module helps you if standard
malloc() does not work. Even if you get MEM_alloc() to work
you cannot use any DSP/BIOS function that calls malloc() internally
when malloc() itsself does not work.

> My cmd-file really knows the symbol SDRAM, I verified that.

The cmd-file is used by the linker only. The compiler sees the
source code only.

best regards
Andreas
--
Andreas Hünnebeck | email: ah@despammed.com
----- privat ---- | www : http://www.huennebeck-online.de
Fax/Anrufbeantworter: 0721/151-284301
GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc

From:	Simone Winkler
Subject:	Re: C6713 external memory problem
Date:	Thu, 20 Jan 2005 10:06:02 +0100

> 3. I don't think that using the MEM module helps you if standard
> malloc() does not work. Even if you get MEM_alloc() to work
> you cannot use any DSP/BIOS function that calls malloc() internally
> when malloc() itsself does not work.

You're right, I use this code now.

segid_sdram=MEM_define((void *)0xB0000000,0x00100000,NULL);
test=(unsigned int *)MEM_alloc(segid_sdram,0x3000,0);

It compiles and runs, but it returns a segid of -1.
And so certainly MEM_alloc returns a null pointer.

:-(

Maybe I can continue with static variables even if this is not what I
wanted...:((

Thank you!
Simone

From:	Simone Winkler
Subject:	Re: C6713 external memory problem
Date:	Thu, 20 Jan 2005 10:10:40 +0100

> It compiles and runs, but it returns a segid of -1.
> And so certainly MEM_alloc returns a null pointer.
>
> :-(
>

Hi!
I just made it work!! (the last thing I tried finally came out for good...)

Now I've got 2 heaps:
1) in IRAM
2) in SDRAM

the first one (IRAM) is used for the DSP/BIOS objects, the second one for
malloc()/free() (You can choose those two things within the MEM manager in
the DSP/BIOS.

When I use the following code:

segid_sdram=MEM_define((void *)0xB0000000,0x00100000,NULL);
test=(unsigned int *)MEM_alloc(segid_sdram,0x3000,0);

segid now returns 2 and test is going to 0xB00FD000. yibbieh!!

malloc() by itself still doesn't work...Maybe because of the 2 heaps.

Thank you for your help!

Simone

From:	Jerry Avins
Subject:	Re: C6713 external memory problem
Date:	Thu, 20 Jan 2005 11:44:57 -0500

Simone Winkler wrote:

...

> Hi!
> I just made it work!! (the last thing I tried finally came out for good...)

Congratulations! (Of course the last thing you try makes it work. After
that, you stop trying.) I think compilers are more trouble than they're
worth unless you use them often.

...

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Brad Griffis
Subject:	Re: C6713 external memory problem
Date:	Tue, 18 Jan 2005 02:23:17 GMT

Have you defined your heap such that it is located in SDRAM? I believe this
is determined by where you define the .sysmem section to be located when
writing your linker command file. If you are configuring this through BIOS
I think you can do this through a GUI by right-clicking on the MEM section
and going to properties.

Brad

"Simone Winkler" wrote in message
news:41ec0ee6$1@e-post.inode.at...
> Hello,
>
> I'm working with a TI C6713 processor. It has external SDRAM that is
> connected via EMIF (CE2).
> So I have a memory section called SDRAM in my cdb-file that has 0xb0000000
> as its base and 0x01000000 as its length (16M).
>
> The problem is:
> When I allocate memory with malloc(), i can watch the desired variable in
> the watch window, and so I can see the pointer address to that variable.
> But the pointer doesn't point to a space within the numbers above! For
> example allocating an array gives me something like 0xAFFFF848 or similar
> values. I also received 0xbebebebe which is out of range as well. What can
> be the problem??
>
> The code section I use (it is C code of numerical recipes, not really
> optimized and conventional C code, but it works):
>
> with L=50 and M=401 (defined as preprocessor directives)
>
> r=vector(1,L+M);
>
> with the function vector like below:
>
> #if defined(__STDC__) || defined(ANSI) || defined(NRANSI) /* ANSI */
>
> #include
> #include
> #include
> #include "complex.h"
> #define NR_END 1
> #define FREE_ARG char*
>
> float *vector(long nl, long nh)
> /* allocate a float vector with subscript range v[nl..nh] */
> {
> float *v;
>
> v=(float *)malloc((size_t) ((nh-nl+1+NR_END)*sizeof(float)));
> if (!v) nrerror("allocation failure in vector()");
> return v-nl+NR_END;
> }
>
> For this one I think I got the 0xAFFFF848 address.
>
> What can I do?
> Certainly, I cannot perform calculations upon the allocated arrays,
> because they are not in a valid memory section, so this is really bad for
> me.
> When I did the same thing in the internal RAM, everything was fine (for
> smaller arrays for sure), but now I need a huge amount of memory because
> I'm working with big matrices, and so I have to change my dynamic memory
> section to the SDRAM.
>
> Thank you!
>
> Simone
>
> Thank you!
>

From:	Andreas Huennebeck
Subject:	Re: C6713 external memory problem
Date:	Tue, 18 Jan 2005 09:06:47 +0100

Simone Winkler wrote:

> Hello,
>
> I'm working with a TI C6713 processor. It has external SDRAM that is
> connected via EMIF (CE2).
> So I have a memory section called SDRAM in my cdb-file that has 0xb0000000
> as its base and 0x01000000 as its length (16M).
>
> The problem is:
> When I allocate memory with malloc(), i can watch the desired variable in
> the watch window, and so I can see the pointer address to that variable.
> But the pointer doesn't point to a space within the numbers above! For
> example allocating an array gives me something like 0xAFFFF848 or similar
> values. I also received 0xbebebebe which is out of range as well. What can
> be the problem??

Refer to the "Optimizing C Compilers Guide", page 5-13. You have to
define the heap size, the memory section (what you did), but you
also have to define the .sysmem segment.

> The code section I use (it is C code of numerical recipes, not really
> optimized and conventional C code, but it works):

Forget about this code and run this test first:
- call malloc() of 1k bytes: the returned address should be close to
the begin of your heap (here on a C6414 it's begin+8).
Make sure that the malloc() call above really is the first malloc(),
therefore run this test at begin of main().
- if this works, call malloc() of 1k bytes in a loop until it returns 0.
check if the number of successfull calls x 1 kBytes matches the
size of your heap (approximately).
If this all works, then start using application code with malloc.

best regards
Andreas
--
Andreas Hünnebeck | email: ah@despammed.com
----- privat ---- | www : http://www.huennebeck-online.de
Fax/Anrufbeantworter: 0721/151-284301
GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc

From:	Simone Winkler
Subject:	Re: C6713 external memory problem
Date:	Tue, 18 Jan 2005 21:53:48 +0100

Hi, thank you very much for your answer!

I figured out that the problem is more complicated than I thought...
I'm using D.SignT module which has a C6713 DSP, 16MB SDRAM, a CPLD and
several other things onboard.
So what I first had to do is to introduce the SDRAM into my EMIF
configuration. It uses CE3 space and now as it is refreshed, I can write and
read from/to my memory space by simply writing to a specific memory adress
within the address range of the SDRAM and reading it afterwards.

BUT: now malloc() returns a null pointer. I can then still write and read
to/from the allocated variable, but I suppose this is only possible because
the memory is not protected against writing to "wrong" addresses.

I didn't try to statically allocate a variable within my SDRAM, but I'll do
to verify everything.

One of my ideas is the following:
I've got 2 heaps:
1) in IRAM, because I've set the section for DSP/BIOS objects to IRAM
2) in SDRAM for the huge dynamically allocatable variables I need.
In the build options I also have to enter a heap size - should I enter the
sum of both heaps there? I suppose 2 heaps aren't that good!?

The second thing is, I couldn't find a .sysmem section. Just a field in the
DSP/BIOS configuration for choosing a memory segment for malloc()/free(). I
think this is what you meant, I've already set that one before. But this one
doesn't compile to a .sysmem section in the cmd-file.
When I tried to use malloc() with IRAM, everything worked, so I think that
then I did the right thing.

Do you have another idea?
Please help me!

Thank you very much,

Simone

From:	Andreas Huennebeck
Subject:	Re: C6713 external memory problem
Date:	Wed, 19 Jan 2005 10:11:10 +0100

Simone Winkler wrote:

> I figured out that the problem is more complicated than I thought...
> I'm using D.SignT module which has a C6713 DSP, 16MB SDRAM, a CPLD and
> several other things onboard.
> So what I first had to do is to introduce the SDRAM into my EMIF
> configuration. It uses CE3 space and now as it is refreshed, I can write
> and read from/to my memory space by simply writing to a specific memory
> adress within the address range of the SDRAM and reading it afterwards.

OK, so the memory I/O works.

> BUT: now malloc() returns a null pointer. I can then still write and read
> to/from the allocated variable, but I suppose this is only possible
> because the memory is not protected against writing to "wrong" addresses.

??? You're writing to a NULL pointer?

> One of my ideas is the following:
> I've got 2 heaps:
> 1) in IRAM, because I've set the section for DSP/BIOS objects to IRAM
> 2) in SDRAM for the huge dynamically allocatable variables I need.
> In the build options I also have to enter a heap size - should I enter the
> sum of both heaps there? I suppose 2 heaps aren't that good!?

This is something i'd like to know as well. Currently I use only the SDRAM
as heap, but I would like to use SDRAM and IRAM. You can use different
heaps, see this excerpt from TI's support hotline:

For every "MEM" region you declare in BIOS, you are allowed to
define one heap and when you call MEM_alloc(), you can specify
which heap to try and get the memory from . So the maximum number
of user-defined heaps just depends on how many memory sections
you have in your memory map. Please refer to the MEM API's in
the DSP/BIOS API Reference Guide.

I haven't found out yet how to set the default heap for standard
malloc()/new and free()/delete operations. Maybe the DSP/BIOS
configuration as mentioned below is the hint I need.

> The second thing is, I couldn't find a .sysmem section. Just a field in
> the DSP/BIOS configuration for choosing a memory segment for
> malloc()/free(). I think this is what you meant, I've already set that one
> before. But this one doesn't compile to a .sysmem section in the cmd-file.

Well, I don't use the CC-Studio, just the naked compiler. I write the
cmd-file all by myself. The compilation is done within an imake based
make system which must run without user interaction.

> When I tried to use malloc() with IRAM, everything worked, so I think that
> then I did the right thing.
>
> Do you have another idea?

Try a manually written cmd-file.
And send me a mail if you get all this to work, please.

Tschau
Andreas
--
Andreas Hünnebeck | email: ah@despammed.com
----- privat ---- | www : http://www.huennebeck-online.de
Fax/Anrufbeantworter: 0721/151-284301
GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc