1. Community Forum
  2. AWE Core
  3. Initializing Processing from awe_fwPacketExecuteArray()

Initializing Processing from awe_fwPacketExecuteArray()

7 posts / 0 new
Log in or register to post comments
Last post
Tue, 05/16/2017
11:15am
pscannell3
#1
Top
#1
Initializing Processing from awe_fwPacketExecuteArray()

I’ve been trying to instantiate a signal flow built in AWE Designer for the SHARC 21469 EZ Kit by passing the generated InitCommands[] array (from generated target files) into the awe_fwPacketExecuteArray() function in my main function just before the main processing loop begins:

 

 // Load initial Signal Flow

    success = awe_fwPacketExecuteArray((UINT32 *) InitCommands, (UINT32) InitCommands_Len);

    while(TRUE)

    {       

                // Process any platform tasks

                awe_pltTick();

               

                // Process any framework tasks

                awe_fwTick();

    }

 

I’m not sure if I should expect any meaningful return value from awe_fwPacketExecuteArray(), but it always returns “0xffffffdf” in this case.

 

So far, I haven’t been able to see any evidence that the signal flow has loaded correctly. The method I’m using to test is connecting to AWE Server & reading system profiling information.

 

I followed the steps listed on P.10 of the latest AWE Core Integration Guide, but is there any other documentation about signal flow instantiation by this method?

Tue, 05/16/2017
11:51am
Matt
Top

Hey Patrick.

At first glance, it looks like you're doing things correctly. Looking in /include/errors.h, I see this is -33, E_AUDIO_ALREADY_STOPPED.  We'll dig into when this happens and and get back to you ASAP.

Tue, 05/16/2017
12:06pm
pscannell3
Top

Thanks for the quick response Matt.

 

Given that error (audio stopped), I removed the third item in my generated array (0x0002001c,        /* PFID_StopAudio */). After removing that line & re-loading the SHARC with updated code, I can see the script executed correctly on the target by checking the system profiling in AWE server. I also noticed the return value for awe_fwPacketExecuteArray() is now 0.

 

Thanks

Tue, 05/16/2017
12:24pm
Matt
Top

Great.  This identifies an incompatibility with the BSP code: At the start of each AWB, we have always had a destroy command. We recently added a StopAudio​ command to ensure we're starting with a known good state in the system.  The problem is that this trips the following error checking code in awe_pltAudioStop():

if (s_AudioRunning == 0)
    {
        return E_AUDIO_ALREADY_STOPPED;
    }

The long-term fix is to remove this error checking from your BSP code. It's now expected that this function will sometimes be called while audio is stopped.

Wed, 05/31/2017
2:00pm
pscannell3
Top

Hi Matt,

 

I just noticed another issue with loading a signal flow via awe_fwPacketExecuteArray() after moving to our own custom hardware (SHARC 21479 based):

 

The return value of awe_fwPacketExecuteArray() is now always E_NO_MORE_OBJECTS (-18).

 

I traced through the execution of the array & noticed the error is first returned during the processing of the first instance of PFID_ClassWire_Constructor; as soon as translateAddr(&retVal, g_PacketBuffer[1]) is called.

 

The strange thing is that this signal flow works if it is loaded from the PC. If I set a breakpoint in PacketAPI.c inside the switch case for PFID_ClassWire_Constructor, I see a return value of 2 (valid since greater than 0) after the call to translateAddr(&retVal, g_PacketBuffer[1]); .

 

Is this another indication of some problem with the BSP?

 

Thanks,

Patrick

Wed, 05/31/2017
2:31pm
Matt
Top

Hm. Does it always do this, or is it Layout dependant. (I presume the former, but just want to confirm.)

We'll take a look.

Wed, 05/31/2017
11:16pm
pscannell3
Top

I've tried 3 layouts and noticed the same issue on each