ti.sdo.ipc.SharedRegion: line 302: assertion failure: A_regionInvalid: Region is invalid

Markus,

I am not able to see what's causing your specific problem, but I think you could try a simpler version of this and eliminate the HeapMemMP creation / opening completely.

Just call this:

gbl_com_handles.srHeap = SharedRegion_getHeap (0);

Use this heap directly for registering with MessageQ:

status = MessageQ_registerHeap (gbl_com_handles.srHeap, gbl_app_info.heapId);

Do this on both ARM Cortex A8 & DSP. Remove the code for HeapMemMP_create & HeapMemMP_open.

Regards,
Mugdha

Markus,

I found a potential issue, though it is not in the opening code, but later on:

MessageQ_alloc returns a pointer to a message of type MessageQ_Msg that should be sent to MessageQ_put / MessageQ_get or any other MessageQ APIs that take a pointer to a message. In this case, your DSP code is doing this to return a pointer to your application message:

    return msg+MESSAGEQ_MSGHEADER_SIZE;

This is being passed eventually to MessageQ_put (through function alloc_tele_ack, which type-casts the Ptr to MessageQ_Msg). This is incorrect.

However, the message received from MessageQ_get is being used correctly:

pTelegram = (TelegramP) msg;
switch( pTelegram->TeleHeader.uID )

You should use the message allocated on DSP and sent using MessageQ_put in the same way. Allocate the full message of type TelelgramP, and set fields within the Teleheader by doing pTelegram->Teleheader.uID/ui32PayloadSize/ui16CRC.

That could be why some corruption might be happening, which could cause the assertion of the kind you saw, which indicates that an invalid SharedRegion ID was found, which usually happens when there is some corruption, OR when SharedRegion is not configured correctly. In your case, SharedRegion seems to be configured correctly, so it could be corruption.

Regards,
Mugdha

Hello Mugdha,

thanks for your Help! I see that there is a problem with my message allocation and I will have to look into it. But it is unlikely that it causes the current trouble: For my test, I commented out every message allocation and sending. The part of main looks:

   SysLink_setup ();
   dspcom_load_firmware( szFile );
   dspcom_open();
   dspcom_close();
   SysLink_destroy();
   Osal_printf ("Bye!\n");

On the DSP, II wait for the semaphore:

    Notify_registerEvent( rProcId, 0, APPNOTIFY_EVENT_NO, (Notify_FnNotifyCbck) APPNotify_callbackFxn,  (UArg) semHandle1);
    Semaphore_pend(semHandle1, BIOS_WAIT_FOREVER) ;
    System_printf("\n******APPNotify_callbackFxn *****\n");
    System_printf ("Got App notification ....:\n") ;

I have a breakpoint in the red line. As soon as I step over it, I get the assertion.

In dspcom_open, I don't open/create any messageQs at all, for my test. It does just the block with the HeapMemMP* stuff and the Notify_sendEvent.

I think, I'll create a new zip file tomorrow where I remove all the code that's commented out here. It might make things clearer... And I'll try to rewrite the HeapMemMP stuff, as you suggested.

Many thanks,

Markus

Markus,

In that case, I think you are getting the GateMutex assertion because of the System_printf in the Notify callback function:

ti.sysbios.gates.GateMutex: line 114: assertion failure: A_badContext: bad calling context. See GateMutex API doc for details.

SYS/Bios checks for calling context of GateMutex. It is not permitted to be called from HWI/SWI context. Try commenting out/removing the System_printf and see if you still get the assertion. The SharedRegion assertion could be because of the other things we discussed, but I think the GateMutex assertion should go away when you remove the System_printf from the callback function (which is called by Notify from HWI context). If you absolutely need to call System_printf from HWI context, you will have to use SysMin instead of SysStd here:

var System   = xdc.useModule('xdc.runtime.System');
var SysStd   = xdc.useModule('xdc.runtime.SysStd');
System.SupportProxy = SysStd;

But using SysMin can have other side-effects, so I suggest you simply remove the System_printf from the Notify callback function and put prints in the task function after semaphore is posted instead (it has the same effect without the print in the callback). You will notice that the SysLink sample application does the same.

Regards,
Mugdha

Hello Mugdha,

my callback contains only the Semaphore_post() instruction:

Void APPNotify_callbackFxn (UInt16 procId,UInt16 lineId, UInt32 eventNo,
                            UArg arg, UInt32 payload)
{
    Semaphore_post((Semaphore_Object*)arg);
}

And the printf follows directly after the Semaphore_pend:

Semaphore_pend(semHandle1, BIOS_WAIT_FOREVER) ;
System_printf("\n******APPNotify_callbackFxn *****\n");
System_printf("Got App notification ....:\n") ;

But in any case, I know how I can go on. If I don't succeed, I'll post a much shorter version of the code and maybe you could then haven another look at it.

Thanks for your help!