> 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.
�����������������������������������������������������������������������
Reply by Simone Winkler●January 20, 20052005-01-20
> 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
Reply by Simone Winkler●January 20, 20052005-01-20
> 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
Reply by Andreas Huennebeck●January 20, 20052005-01-20
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.
Reply by Simone Winkler●January 19, 20052005-01-19
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
Reply by Andreas Huennebeck●January 19, 20052005-01-19
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?
Reply by Simone Winkler●January 18, 20052005-01-18
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
Reply by Andreas Huennebeck●January 18, 20052005-01-18
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
Reply by Brad Griffis●January 17, 20052005-01-17
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!
>
Reply by Simone Winkler●January 17, 20052005-01-17
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!