Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hello François,

On the DSP side, if you are using the tcIPCInbound class, are you calling the ReturnBuffer() method in your callback handler? You need to do this or else the underlying POOL objects used by the GetBuffer() calls are not returned to the pool and the DSPLINK queue. This is not symmetrical in the ARM side our wrapper class, unfortunately, as the ARM Inbound class will return the buffer following the callback -- a result of 2 authors writing each side of the interface...

I'm not sure this is the case of what you are describing, though. I would think tearing down the entire DSPLINK structure and starting it back up would clear the state of the Pools, unless you are leaving the DSP code running.

We haven't had too much trouble running applications more than once if they are shut down cleanly, and the OMAP-L138 DSPLINK code seems fairly diligent about flush CACHEs at the appropriate times, but I can't claim that there may not be an issue here.

Any chance you have some simple example code you might be willing to post?

-Mike

Mike,

Thanks for your answer.

Yes, I am already using the ReturnBuffer() method in DSP side.

Also, while purging our code to remove our intellectual property before posting the code in this forum, I found an important bug in our code. So, you helped me indirectly by asking me some code!

Anyway, the behavior of our code changed since the bug fix. I am analyzing and comparing the result between the full version and the purged version of our application. Still see some problem(s) but I am not sure from where it comes from.

Regards,

-François

I know this is an old thread, but I am having similar issues. This is the first time I have head about the "ReturnBuffer()" call. I searched the Hello World could and could not find any reference to it. The header file is not really clear about what buffer I am returning in the incoming message handler. I assume I'm supposed to 'return' the buffer that came in?

Is there a similar Return Buffer for the ARM side?

I am simply trying to send a few messages back and forth. I can get the DSP to send the initial message to the ARM, the ARM to send a message to the DSP, the DSP to return an updated message. Then I receive a series of ASSERTS. Which I assume are from the GetBuffer() call. Perhaps the HelloWorld program is configured to really small memory or queue sizes? I'm sending maybe about 400 bytes.

I have something like this:

// Create the object used to send messages to the DSP
    lpMessageOutbound = new tcIPCOutbound((char*)"DSPMSGQ0");

// Wait for the DSP to finish initialization (really just waiting for first message, which indicates DSP set up ok)
    while(false == gbDone) {
        sleep(3); //printf("waiting for DSP\n");
    }

// Reset bool in preparation for next received message from DSP
    gbDone = false;

// Get a buffer for a message to the DSP
    lpMessageBuffer = (char*)lpMessageOutbound->GetBuffer(sizeof(messageA2D));

allTypes messageA2D;
    messageA2D.library.header.command = eWriteToDSP;
    messageA2D.library.header.type = eLibrary;
    messageA2D.library.FeatureCount = 0;
    messageA2D.library.SQCBatchSize = 9;

// Copy the message to the dsplink buffer
    memcpy(lpMessageBuffer, &messageA2D, sizeof(messageA2D));
    // Send the message to the DSP
    printf("Sending a message to the DSP.\n");
    lpMessageOutbound->SendMessage(lpMessageBuffer);

Now to send another message, I was calling lpMessageBuffer = (char*)lpMessageOutbound->GetBuffer(sizeof(messageA2D)); again. But this is where the ASSERTs occur.
Assertion failed (((drvObj != NULL) && (IS_OBJECT_VALID (drvObj, SIGN_DRV))) || ((drvObj NULL) && (cmdId CMD_PROC_ATTACH))). File : drv_api.c Line : 501
Assertion failed (((drvObj != NULL) && (IS_OBJECT_VALID (drvObj, SIGN_DRV))) || ((drvObj NULL) && (cmdId CMD_PROC_ATTACH))). File : drv_api.c Line : 501
inbound:GPPMSGQ1: Status = 0x80008002
inbound:GPPMSGQ1: Terminating

Would it be possible for you to post a copy of your example code, including the BIOS configuration files?

If you want you could send it directly via email offline...

-Mike

I think these are the files you need. Basically, just the HelloWorld files. Let me know if you need anything else.

Various small errors contributed to the problem. things seem to work better now. I can send & Recv 3 messages and I discovered the debugMsg print queue as well.