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 Problems about integrating new server on DM6467

Hi, all

I try to test our H264 encoder on DVSDK 2.00. First, I test the video_copy example under the codec engine 2_23_01, the memory copy example works well. And I then I begin to call our parameter initliazation function in function alg_initObj() and set the dynamic parameters in the alg_control()  function, and the process is only memcpy as the example. But this time, the appliction doesn't work, with the following error:

"Error: DSP-side memory map does not match configuration.
Compare DSP-side TCF/MAP file with /dsplink/config/all/CFG_<PLATFORM>.c"

. I googled the error information, found it the dsplink related error. So I checked the memory map of the tcf file of the server and *.cfg files for the apps. As the the declaration of createFromServer, I think there's no unmatch between the memory of the ARM and DSP side. And I try to modify the function calls in alg_initObj() and alg_control(), and if the calls are inliined in alg_initObj() and alg_control() without function calls, after rebuilding, there's no DSPLINK error as above. The function is the same except extra functions calls in alg_initObj() and alg_control(), but the run of the app generates so much difference. I used the 'CE_DEBUG=2' or 3 to trace the debug info, if using function calls in alg_initObj() and alg_control(), there would be an error info such as

 "Loading and starting DSP server '*x64P' FAILED,status=[0x8000
8013] (look for error code 'DSP_EBASE + 0x13' in dsplink*/packages/dsplink/gpp/inc/usr/errbase.h) This error code typically indicate
s a problem with the DSP memory map, i.e. it is different from what the Arm side specified; check the DSP server's memory map in you
r Arm application .cfg script, and make sure you have set 'armDspLinkConfig' configuration variable correctly (for details, refer to
 the documentation for ti.sdo.ce.Engine.xdc). Also, verify that the DSPLINKMEM segment on the DSP is large enough."

So this is also the DSP memory map unmatch between ARM and DSP. I checked the generated *.map file of the server package, and find if ther's function call in alg_initObj() and alg_control(), the ARM_RAM will be used. And the memory statistics is similar like this:

"         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  ARM_RAM               10010000   00008000  00001898  00006768  RWIX
  IRAM                  11818000   00010000  00010000  00000000  RWIX"

I searched the ARM_RAM in the map file, and found only map like this "ffffffff   ARM_RAM".

So I'd like to know why the ARM_RAM is used if there's function call in alg_initObj() and alg_control(). How to solve this problem? Now I can inline the function call in alg_initObj() and alg_control(), but I couldn't avoid funciton calls in the alg_process. Any advice is appreciated. Thanks all.

  • I believe that this thread was incorrectly posted to the BIOS forum.  I am moving it (back) to the Linux forum and the moderator has asked an apps engineer to take a further look.

  • Hi touse,

    It seems strange to me that ARM_RAM is being used. Did you explicitly ask the linker to put code/data into the ARM_RAM section? I have rebuilt the server for the video_copy example and the makefile indicates that nothing is placed in ARM_RAM by default:

      ARM_RAM               10010000   00008000  00000000  00008000  RWIX
      IRAM                  11818000   00020000  00000000  00020000  RWIX
      CACHE_L1P             11e00000   00008000  00000000  00008000  RWIX
      L1DSRAM               11f00000   00007000  00001000  00006000  RWIX
      CACHE_L1D             11f07000   00001000  00000000  00001000  RWIX
      DDRALGHEAP            88000000   07a00000  07a00000  00000000  RWIX
      DDR2                  8fa00000   00400000  00083f29  0037c0d7  RWIX
      DSPLINKMEM            8fe00000   00100000  00000000  00100000  RWIX
      RESET_VECTOR          8ff00000   00000080  00000000  00000080  RWIX

    So assuming you took this server as a starting point, it should not have anything placed in ARM_RAM to start with. (you may wish to double-check that.)

    Now when you add your encoder to the server, you must have created a codec package containing your encoder library (see any of the codec packages in the directory /library/dvsdk/dvsdk_2_00_00_22/dm6467_dvsdk_combos_2_05/packages/ti/sdo/codecs for an example) . In that codec package, there is normally a file called link.xdt which determine how you'd like to place specific sections defined in your encoder library. Make sure that nothing is placed in the ARM_RAM section, and try to explicitly place everything into e.g. DDR2 section. If you are specifically having trouble with certain functions like alg_initObj and alg_control, make sure you create a code section for each function in your C code like this

    #pragma CODE_SECTION(alg_initObj, ".text:algInit")

    and then in your link.xdt file you can explicitly place the .text:algInit section into DDR2. See if this helps.

    Best regards,

    Vincent

  • Vincent, thanks for your reply. Yes, I create a codec package under dm6467_dvsdk_combos_2_05/packages/ti/sdo/codecs and using #pragma CODE_SECTION(alg_initObj,  ".text:algInit") to allocate the code memory, and I can make sure the alg_func are placed in DDR2 memory from the server's memory map file. When using video_copy example, there's nothing located in ARM_RAM, but when there's a function call in alg_initObj and alg_control, there's ARM_RAM used as code/data, and according to my knowledge, every time, no matter the code size of the alg functions, the used ARM_RAM size is the same, i.e, 0x1898. I don't know whether the usage of the ARM_RAM that caused the DSPLINK error for ARM/DSP memory map un-match. But from the memory map file, I can only find the difference between the original video_copy example and my new codec. 

  • I think I find where the error is, there's a user-defined data section that occupy the ARM_RAM. Thanks for all.