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!
C6713 external memory problem
Started by ●January 17, 2005
Reply by ●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 ●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 ●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 ●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?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
Reply by ●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 ●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.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
Reply by ●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 ●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 ●January 20, 20052005-01-20
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. �����������������������������������������������������������������������