DSPLINK error: MSGQ_put on ARM crashes DSP (2nd MSGQ)

Judson Wilson

First I should note that my colleague Arya will be handling this issue as I am handing this project off to him.

I have posted relevant files in an attachment.

I have setup a program that uses 2 pools, and 2 sets of 2 MSGQs (2 on ARM, 2 on DSP). One set is intended to run at a higher priority level through different tasks/processes. My code originated from the MESSAGE example from dsplink 1.65.00.03. I have the same problem with BIOS 5.33.05 / Link 1.65.00.03, and BIOS 5.41.13.42 / Link 1.65.01.06 (I upgraded so I could see the ROV view in CCS 5.1 to troubleshoot this problem).

The original MSGQs from the MESSAGE example work completely fine. The new ARM (receiver) MSGQ, using the second pool, also seems to work fine. The new DSP MSGQ seems to be found perfectly on the ARM side, but when I put a message to it, the DSP seems to immediately crash (unrelated to the DSP's call to MSGQ_get). I get this same problem even if I try to have the DSP send a message to the ARM, and then send it back (thus avoiding any simple MSG allocation problems, as it allocates fine on the DSP and goes to the ARM fine).

I have gone through the basic steps to check to see if there is a task stack problem. There does not seem to be. I added the options to my TCONF file to check at every context switch:

I have also checked the LOG messages, which produced nothing interesting. The Raw Logs show this:

I changed the TCONF file to also use my own error handlers, and it appears that it is being called by SYS_abort with a pointer to "Run-time exception detected, aborting"

It feels like there is some kind of memory problem, but I can't track it down. Our memory setup is almost identical to the stock MESSAGE example, except for the splitting of the POOL memory. The sections are in the same places, as far as I can tell.

Based upon the fact that the POOL works great in one direction, my thought is that is definately a problem with the DSP's second MSGQ, not with the pool.

None of the BIOS calls are returning errors. The MSQ locate process seems to work fine.

Thanks for any help. Unsure where to go next on this.

over 13 years ago

0 Arya Ba over 13 years ago

Intellectual 690 points

I have attached the core files to aide the troubleshooting process.

Any help would be much appreciated.

Thanks,

Arya

DSPLink Error.zip

0 GAnthony over 13 years ago in reply to Arya Ba

TI__Intellectual 2790 points

Hello Arya:

The GPP side memory config looks fine, but I didn't check the DSP side to ensure it was the same. I cannot say exactly why the code would be crashing, but I can provide a link with some pointers, and something I did notice in the code.

In the project zip, ARM/DSPLinkComms.c, I see the commented out code:

        mqtAttrs2.poolId = POOL_makePoolId(processorId, POOL_LOWPRIO_ID);
        status = MSGQ_transportOpen (processorId, &mqtAttrs2) ;
        if (DSP_FAILED (status)) {
            printf("MSGQ_transportOpen () failed. Status = [0x%x]\n", (unsigned int)status);
        }

If the intention is to create two POOLS and register them both with the MessageQ transport, then:

1) I don't think that is possible;

2) the second call should fail with an ERROR code:

From the DSPLink Programmer's Guide, 7.3.1 MSGQ_transportOpen:

DSP_SALREADYOPENED The MSGQ transport for the specified processor has already been opened.

(Actually, per the source code, it looks like DSP_EALREADYOPENED is returned instead). So, the MQT only needs one default pool from which to allocate it's control messages.

Regarding the memory config, there are some tips to check:

http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2007-October/004418.html

Note Mugdha's counsel:
" After configuring the pools, if application is using dynamic
configuration, the GPP-side application must be rebuilt. If dynamic
configuration is not used, the DSP/BIOS LINK user API library
dsplink.lib must be rebuilt from /dsplink/gpp/src/api followed by the
application rebuild."

I would recommend trying with only one pool, and see if that works.

Regards,
- Gil

0 Arya Ba over 13 years ago in reply to GAnthony

Intellectual 690 points

Hi Gil,

Thank you very much for the response, I went ahead and replaced the 2 separate POOLs with a single POOL and there is a single transport open as well. Moreover, I increased the POOL, DSPLINKMEM and DSPLINKMEM1 sizes. However, the problem still persists on the DSP side, when it places the "dummy" value into the message queue it proceeds to crash. Although, the ARM side is able to retrieve that packet before/after the DSP crashes. Any help would me much appreciated to see what is causing this odd problem.

Thanks,

Arya

0 GAnthony over 13 years ago in reply to Arya Ba

TI__Intellectual 2790 points

Arya:

I didn't see where shared_MSGQ_message_meters was defined. Can you ensure it is a structure that can be cast to MSGQ_msg?

Otherwise, since it's on the DSP, and you have CCS debugger, I can only recommend putting tracing into the MSGQ_put() code on the BIOS side to see where the crash is occuring when coming out of MSGQ_put(). That may show if there is a bad access to memory.

Regards,

- Gil

0 Arya Ba over 13 years ago in reply to GAnthony

Intellectual 690 points

Hi Gil,

Thank you very much for the help, after switching to a single pool and tweaking some other values DSPLink is now functional. Here are some links which I found to be helpful (in case someone runs into this post).

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/31002.aspx?pi36526=1

http://e2e.ti.com/support/embedded/bios/f/355/t/103997.aspx

http://processors.wiki.ti.com/index.php/DSPBIOS_LINK_WebEx_Presentations

http://processors.wiki.ti.com/index.php/DSPLink_POOL_FAQs

Thanks,

Arya B.

Processors

Processors forum

DSPLINK error: MSGQ_put on ARM crashes DSP (2nd MSGQ)