• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 678 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Problems with calloc in DSP/BIOS

MikeH
Guru 15580 points

I am having a problem with a library in my DSP/BIOS application calling "calloc". When I get to this step the program crashes. I remembered reading the information below about using the DSP/BIOS version of calloc by -undefining calloc in the linker options. I have tried "--undefine _calloc", but the linker appears to be linking back to the rtsl version of calloc. At least that's what I see in my .map file.

Can someone provide some guidance with this issue?

Thx,

MikeH

//It is recommended that you use the DSP/BIOS library version of malloc,

//free, memalign, calloc and realloc within DSP/BIOS applications. When

//you are not referencing these functions directly in your application but call

//another run-time support function which references one or more of them,

//add '-u _symbol', (for example, -u _malloc) to your linker options. The -u

//linker option introduces a symbol, such as malloc, as an unresolved symbol

//into the linker's symbol table. This causes the linker to resolve the symbol

//from the DSP/BIOS library rather than the run-time support library. If in

//doubt, you can examine your map file for information on the library sources

//of your application.

  • 0
    TI__Guru* 96960 points

    Mike,

    Which version of BIOS are you using?

    What exactly is the crash? PC goes into the weeds, exception, etc.

    Todd

  • 0 in reply to ToddMullanix
    Guru 15580 points

    Todd,

    Thanks for responding.

    ToddMullanix said:
    Which version of BIOS are you using?

    Ver bios_5_41_07_24

    ToddMullanix said:
    What exactly is the crash? PC goes into the weeds, exception, etc

    The program goes to "SYS_EXITFXN, UTL_halt:" and sits, looping at "0002A120    BNOP.S1       C$L1 (PC+8 = 0x11823c88),5"

    FYI, I have allocated a heap in DDR of ~200kB.  I am calling a function that dynamically allocates 100kB of memory for its use. I am calling the function from a SWI. However, I found this in another post:

    Assuming that your external memory is working (i.e., the EMIF is properly configured by your custom code or via a GEL file), the most common root for this problem is calling MEM_alloc() or malloc() either from a SWI or from a HWI - this can cause lockup problems given these APIs have a memory lock mechanism to protect against data overwrite.

    Could this be contributing to the problem?

    Thx,

    MikeH


     

  • 0 in reply to MikeH
    TI__Guru* 96960 points

    Mike,

    MEM_alloc, malloc, calloc, etc. all use a TSK level lock (i.e. SEM) with a non-zero timeout. Therefore they cannot be called from a HWI or SWI. The functions can be called within main() or from a TSK.

    Todd

  • 0 in reply to ToddMullanix
    Guru 15580 points

    Arrgghh. Ok, thanks. 

    MikeH

  • 0 in reply to MikeH
    TI__Guru* 96960 points

    Mike,

    I don't know if it helps, but you can call BUF_alloc in a SWI (or HWI). This is because the BUF_alloc is fast and deterministic. Internally, interrupts are disabled for a very short time instead of using a SEM when acting on a shared resource. Note: malloc and MEM_alloc both internally traverse a variable length linked list when looking for a free block. Thus the need for a SEM instead of disabling interrupts for a non-deterministically amount of time.

    The API reference has a quick "Function Callability Table" in the appendix that shows which APIs can be called where.

    Todd