This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Why does 2nd HeapBuf_alloc() return Adress of 0x8000 while my heap is in DDR3?

Other Parts Discussed in Thread: SYSBIOS

Hello,


I'am working with TMDXEVM6678L with C6678 Multicore DSP and SYSBIOS 6.34.2.18


I created a HeapBuf in DDR3:


*.cfg:

Program.sectMap["DDR"] = "DDR3";
var heapBuf0Params = new HeapBuf.Params();
heapBuf0Params.instance.name = "heapBuf0";
heapBuf0Params.blockSize = 8;
heapBuf0Params.numBlocks = 1000;
heapBuf0Params.sectionName = "DDR";
heapBuf0Params.align = 0;
Program.global.heapBuf0 = HeapBuf.create(heapBuf0Params);

and in my *.c I'am calling HeapBuf_alloc() 2 times:

    ptr = HeapBuf_alloc(heapBuf0, sizeof(char)*2, 8, &eb);
    ptr2 = HeapBuf_alloc(heapBuf0, sizeof(char)*2, 8, &eb);

But:

after that, 'Expressions View' shows:

ptr    char *    0x80000000    0x00831D3C    
sharedHeap0    unknown    Error: identifier not found: sharedHeap0    // you can ignore that
ptr2    char *    0x00008000    0x00831D40    
eb    struct xdc_runtime_Error_Block    {...}    0x0083256C    
Add new expression    

Do you have any suggestions why this is happening?


Btw: when i try to use a HeapMem in DDr3, a HeapMem_alloc() even gives me NULL when i try it the first time, even if i want to allocate 2 bytes and Buffer size is 2048...

  • Florian,

    Can you reformat or describe this:

    ptr    char *    0x80000000    0x00831D3C    
    sharedHeap0    unknown    Error: identifier not found: sharedHeap0    // you can ignore that
    ptr2    char *    0x00008000    0x00831D40    
    eb    struct xdc_runtime_Error_Block    {...}    0x0083256C    
    Add new expression    

    Where are you seeing this?

    Also, what is “sharedHeap0”, and “you can ignore that”?  Is it possible that it is already in DDR3 and there is a collision?

    Thanks,
    Scott

  • Hello Scott,


    this Output is copied from the 'Expressions' View of CCSv5.3. You can insert anexpression there (i.e. ptr) and if it exists in your code, it gives you information about that, like location and value.

    sharedHeap0 is something i was looking at before, put i dont use this anymore in my code but didn't delete the search from the expressions view. So you can ignore that, because its nothing.

    Since yesterday, i started to try HeapMem_alloc() on a HeapMem i created instead of HeapBuf, but there is also some undeterministic behaviour. Sometimes even when i try to allocate just a Byte from a the HeapMem it gives me a NULL but another time it just works with 2000 Bytes.

    When I'am at the laboratory i can give more output.


    Best Regards,

    Florian

  • Florian,

    OK, thanks.

    Since you mention undeterministic behavior, I wonder if the timing parameters for DDR3 are setup properly.  Are you able to correctly access DDR3 memory repeatedly from your program, before trying to allocate a heap there?

    Thanks,
    Scott

  • Hello Scott,


    I don't know if i understand this question correctly. Shall I try to allocate Memory from DDR3 without creating a Heap there before? I wonder if thats possible, because creating a heap, placing it to some memory section and allocating some bytes from it is the only way i know, how to specify the memory i want to allocate some bytes from.

    Or what do you mean with "correctly access DDR3 memory repeatedly from your program" ?

    Best Regards,
    Florian

  • Florian,

    What I was asking is if you know whether access to DDR3 memory is working properly.  Before trying to use that memory for a heap.  

    For DDR memory there is usually some initialization of read/write timing and refresh parameters.  In some situations these timing parameters are setup by the program itself, and sometimes they are setup via the debugger, for example by a GEL file command in CCS.  If the timing/refresh parameters are not correct, then memory accesses are not reliable, or ‘undeterministic’ as you described what you are seeing.

    One way to do this is to initialize a pointer to an address in DDR3.  Then use that pointer to write/read a block of memory, and verify that what was written to the diffent locations is read back properly.  And it is best if you do this several times repeatedly, using different values, to make sure you are seeing reliable accesses.

    This might not be the problem, but it is important to know if DDR3 memory is configured and working properly before placing a heap there.

    Scott

  • Hello Scott,

    thanks for your help.
    I had no time to test it yet and worked with the MSMSRAM instead of DDR3.

    I will try it at the end of this week, when I'am at the laboratories.

    Just to get it right, i shall initialize a pointer with a 0x8... address by myself, manually, and try to write and read from it without any _alloc() function?

    Florian

  • Florian,

    Yes, that is the type of test I was thinking of.

    You might also try just viewing the memory with a CCS memory view, and then refreshing the view a few times and see that the contents aren't changing.  And try writing a value in the view, and see if it writes and then displays back correctly.  The test with your program is best, but a test with the CCS memory view is a simpler way to determine if there is some basic timing issue.

    Scott

  • Scott,


    you are right, my DDR3 Memory seems not te be configured correctly.
    I did what you say and tried to write and read successively to the memory and the values are completely different after a single cycle, and seem to change randomly in every cycle.

    I figured out, that i didn't specify the GEL files for each Core in the target configuration file.
    After i did this, i could write and read from the DDR3 correctly and also place a HeapMem there and allocate memory from it.

    Thanks you for your help!

    Best Regards
    Florian

  • Florian,

    OK, great!  Thanks for reporting back.

    Best regards,
    Scott