• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 100 subscribers
  • Views 799 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.

DSPLink DSP_EMEMORY error

pablo colodron90122
Prodigy 100 points

Hi all,

 

I am using Davinci DM6446 and I want to build an aplication in the ARM that uses DSPLink for sending and receiving information from the DSP. I am running an Integrity OS in the ARM, although the case would be the same for Linux. The problem that I am experiencing is related to PROC_Load function, which returns error 8000800c (DSP_EMEMORY). The size of the .out file that I am trying to download to the DSP is 360KB

 

I read in 'Toubleshooting DSPLink configuration Issues' that a possible cause for these error is that 'The DSP executable size is too big and heap memory is not available. Recheck the system heap size configuration.' However, I don't now if this implies just increasing the heap memory of the kernel that i am running. It could also be that I have to increase the heap memory of the address space application that has the program that executes this Proc_load() function.

 

I don't know either if it could a problem with the memory mapping of the system, which is the following:

 

hysicalRange BSP_PhysicalMemoryRanges[] = {
    {RAMMemory,  0, 0x80000000, 0x87ffffff, RAM_MemoryType, 0}    /* 128 MB RAM */
};

MemoryReservation __ghsentry_reservedmem_bsptcpipbuffers =
    {(MEMORY_RWE | MEMORY_IOCOHERENT), 0, 0, 48 * 1024 - 1, RAM_MemoryType,
     false, 0xfffff000, 0xfffff000, "__ghs_tcpip_buffers"};

#if defined(DSPLINK)

MemoryReservation __ghsentry_reservedmem_dsplink_shared_kernel_virtual =
    {(MEMORY_RWE | MEMORY_IOCOHERENT), 0, 0x87500000, 0x875fffff,
     RAM_MemoryType, true, 0xffffffff, 0xffffffff,
     "__ghs_dsplink_shared_kernel_virtual"};

MemoryReservation __ghsentry_reservedmem_dsplink_load =
    {(MEMORY_RWE | MEMORY_IOCOHERENT), 0, 0x87f00080, 0x87ffffff,
     RAM_MemoryType, true, 0xffffffff, 0xffffffff,
     "__ghs_dsplink_load"};

MemoryReservation __ghsentry_reservedmem_dsplink_reset =
    {(MEMORY_RWE | MEMORY_IOCOHERENT), 0, 0x87f00000, 0x87f0007f,
     RAM_MemoryType, true, 0xffffffff, 0xffffffff,
     "__ghs_dsplink_reset"};

MemoryReservation __ghsentry_reservedmem_dsplink_shared_gpp_dsp =
    {(MEMORY_RWE | MEMORY_IOCOHERENT), 0, 0x87700000, 0x87efffff,
     RAM_MemoryType, true, 0xffffffff, 0xffffffff,
     "__ghs_dsplink_shared_gpp_dsp"};

#endif

 

As far as I know, this memory mapping assigns 1MB to the section DSPLINKMEM. Does it need to be larger?

 

Does anyboy know possible solution to the problem or has experienced something similar?

 

Kind regards,

Pablo Colodrón

  • 0
    TI__Mastermind 22760 points

    Pablo,

    You could try building dsplink with trace enabled, to see where the memory allocation is failing.  The instructions for doing this are described in the DspLink User's guide.  I don't know if the procedure is the same for Integrity OS as it is for Linux, but for Linux you need to:

    - Run the perl script, dsplinkcfg.pl,  with trace=1

    - Edit the file drv_pmgr.c and uncomment the lines

               TRC_ENABLE (ID_LDRV)            ;
               TRC_ENABLE (ID_LDRV_PROC)       ;

               TRC_SET_SEVERITY (TRC_ENTER) ;

      You can enable more modules if this is not sufficient.

    - Rebuild dsplinkk.ko and your application.

    You may also want to contact GreenHills support since they did the Integrity port of DspLink.

    Best regards,

        Janet

  • 0 in reply to janet
    Prodigy 250 points

    Hello Janet,

     

    Thank you very much for your help. Unfortunatelly, I only have a precompiled version of dsplink libraries (libdsplink_api, libdsplink_common, libdsplink_kernel and libdsplink_test). I will ask Green Hills if I can be provided with a library with trace enabled.

     

    As this will probably take some time, I would like to ask you if there are any known issues that could cause this kind of problems. Maybe the heap memory is not enough or it might be possible that the memory mapping for my board is wrong somehow?

     

    Best regards Janet,

    Pablo

  • 0 in reply to pablo colodron
    TI__Mastermind 22760 points

    Pablo,

    It sounds to me like your system heap on the Arm side is not big enough.  But I don't know how you configure the kernel heap size for Integrity OS.  It could be that the loader is trying to allocate a buffer to copy the DSP executable image into, but I really can't say for sure, given that I don't have any trace to look at.  Can you try cutting down your image so that the size is much smaller and see if it then loads?

    Best regards,

        Janet

  • 0 in reply to janet
    Prodigy 250 points

    Hello Janet,

     

    I have tried to load another .out image (that did not included the DSPLink file, so it is smaller) of size 190KB and PROC_load() works. However, the .out that i wanted to use is 350KB (because it has DSPLink) and it does not work. Maybe there is a way of reducing the size of the .out that i am using (i assumed that, as it is using DSPLink, its size should be in this order but maybe could be smaller)

     

    Kind regards,

    Pablo

  • 0 in reply to pablo colodron
    TI__Mastermind 22760 points

    Pablo,

    So it looks like the PROC_load() is failing because the file size is too large.  Do you know how to increase the size of the system heap for Integrity OS?  I have no idea how this is done in Integrity.

    Best regards,

        Janet

  • 0 in reply to janet
    Prodigy 250 points

    Hi Janet,

     

    The way in which my system works is the following:

    - Integrity kernel with a heap of 16MB and file system

    - Independent address space application that uses DSPLink. I managed to increase the heap to 16MB but it still fails.

     

    The extrange issue is that, before executing PROC_Load(), I tried to allocate a memory of 3MB (malloc() and free()) just to be sure that there is enough heap memory. This allocation works so it seems extrange that PROC_Load fails, because the .out file is 350KB. PROC_Load needs to allocate much more memory in addition to the memory required for storing the file (in this case 350KB)?

     

    Thank you very much for your useful help again.

    Kind regards Janet,

  • 0 in reply to pablo colodron
    TI__Mastermind 22760 points

    Pablo,

    I found this information on the Green Hills website:

    The INTEGRITY RTOS protects memory many ways:

    • from exhaustion
    • from damage
    • from unauthorized access

    INTEGRITY’s unique memory quota system keeps one address space from exhausting the memory of any other.

    To ensure adequate kernel memory, INTEGRITY requires that kernel memory not be used for messages, semaphores, or other kernel objects created in response to process requests. Instead, the kernel performs all services requested by a process using the memory resources that the requesting process supplies.

    To prevent the risk of user stack overflow, INTEGRITY’s kernel has its own memory stack. Without this, the kernel would need to access the user process’ sta    ck. But this can lead to problems because it is impossible for the user process to anticipate the maximum stack size if it is subject to use by unknown code (i.e., the kernel).

    So maybe your process is attempting to use more then its quota of memory.

    Best regards,

        Janet

  • 0 in reply to janet
    Prodigy 100 points

    Hello Janet,

     

    I couldn't respond sooner, sorry. I could get an open version of DSPLink and I could compile it with trace enable. Let me show you the results of the trace logs. I hope this could give some clues about what is happening in my system. Aparently, the function DRV_Invoke() is failing, but I do not know why this is happening:

     

    I/O: Entered PROC_Load ()
    I/O:     procId    [0x0]
    I/O:     imagePath    [0x334f00]
    I/O:     argc    [0x2]
    I/O:     argv    [0x334f40]
    I/O: Entered DRV_Invoke ()
    I/O:     drvObj    [0x3351c4]
    I/O:     cmdId    [0x6c05]
    I/O:     arg1    [0x334e9c]
    I/O:     arg2    [0x0]
    I/O: Entered DRV_CallAPI-VA ()
    I/O:     cmd    [0x6c05]
    I/O:     args    [0x334e9c]
    I/O: Leaving DRV_CallAPI-VA ()     status [0x8000]
    I/O: Leaving DRV_Invoke ()     status [0x8000800c]
    I/O:
    I/O: Failure: Status:[0x8000800c] File:[0x200] Line:[370]
    I/O: Leaving PROC_Load ()     status [0x8000800c]

     

    Thank you one more time for your kind help.

     

    Kind regards,

     

  • 0 in reply to pablo colodron90122
    Prodigy 100 points

    Hello again Janet,

     

    I reached to the point in which I see that the function 'SynchronousSend' fails the execution and gives the 'memory error'. This instruction is located in drv_api.c line 776:

     

    /* Send to DSPlinkDispatchTask */
            CheckSuccess(SynchronousSend(DSPlinkConnection, B));

     

    Does this give you any more ideas?

     

    Thank you very much,

    Pablo

  • 0 in reply to pablo colodron90122
    TI__Mastermind 22760 points

    Hi Pablo,

    I only have the Linux version of DSPLink, so I don't have 'SynchronousSend'.  I'm guessing that must be an Integrity OS call.  I wonder if it corresponds to the Linux ioctl()?  The trace in your previous post looks like it's only user level trace.  Is there any way you can get trace from the driver also?  I think that is where the failure is occurring.

    Best regards,

        Janet