• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 100 subscribers
  • Views 345 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 - problem using MSGQ and POOL buffers

Pablo Bitton
Prodigy 20 points
Other Parts Discussed in Thread: OMAP-L138

Hello,

 

I am having a problem using MSGQ.

My simple application, based on the MESSAGE sample code, uses the following configuration:

- 1 MSGQ (A) created by ARM (Messages are sent by DSP)

- 1 MSGQ (B) created by DSP (Messages are sent by ARM)

- All MSGQs are using the same POOL, which is configured as follows:

             - 50 buffers of size 128 (used with MSGQ A)

             - 4 buffers of size ZCPYMQT_CTRLMSG_SIZE

             - 40 buffers of size 2688 (used with MSGQ B)

When both ARM and DSP are sending buffers in a high rate, a "NULL pointer dereference" error occurs after several seconds:

Assertion failed (addr != NULL) File: .../gpp/src/ldrv/POOLS/ldrv_pool.c Line: 1045

Unable to handle kernel NULL pointer dereference at virtual address 00000004

 

There are two workarounds I tried which eliminate this error:

1. Change the MSGQ A buffers size to 2688 (like B) or greater.

2. Define another POOL: one for MSGQ A and one for MSGQ B.

Both workarounds vanish the bug, but the source of the main problem is still unknown to me.

 

Any advice will help!

Thanks in advance

  • 0
    TI__Expert 4930 points

    Pablo

    The assertion is coming from function LDRV_POOL_getPoolId in file $(DSPLINK)/gpp/src/ldrv/POOLS/ldrv_pool.c

    Your workaround 2 seems to suggest that in some API call which requires that pool id is passed has POOL_makePoolId is missing

    Deepali

  • 0 in reply to Deepali Uppal
    Prodigy 120 points

    We are experiencing a similar issue using DSPLink and the OMAP-L138. Our application has 3 MSGQs and 1 POOL with 5 different sized buffers.

    Deepali,

    Is your post suggesting that an API call being made in Pablo's application is the issue or that a call in the DSPLink code is causing the crash?

    Pablo,

    Did you make any changes to your calls into the DSPLink API that resolved this? Or are you continuing to use one of your workarounds?

     

    Thanks,

    Steve