Forums

C6713 external memory problem

Started by Simone Winkler January 17, 2005
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 <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#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! 


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" <simone.winkler@gmx.at> 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 <stdio.h> > #include <stddef.h> > #include <stdlib.h> > #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! >
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&#2013266172;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
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



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&#2013266172;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
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 


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&#2013266172;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
> 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
> 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
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. &#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;