DM6437 hexAIS before flashburn

Would someone from TI be able to look at this because it is very important to us. I can provide our OUT file if necessary.

I have found that when I remove all the files (C and C++) from the project and leave only the "main" the hexAIS runs OK without run-time exceptions.

My project has about 30 or so files. Most are C++ including the "main" which is compiled as a C++ unit.

Is there some internal limit in hexAIS? The exception does seem related to an index out of bounds related to a filename in the hexAIS utility. My it also be related to the number of functions in the project?

I cannot see how not having files in a project enables hexAIS to work and adding files causes hexAIS to generate an exception.

The problem is not related to the xDM framework and codecs because I can build and hexAIS the dm6437 demo (that comms with the PC to do file decode etc) and when I removed the files from my own project the codec links / includes in the TCF and CFG are still present.

Would TI be able to look at this.

Thanks.

I build the project up until all files are present (with parts of main commented out that call other code) and found that hexAIS works OK.

I then started to add back (uncomment) code into main function and the file itself. Sometimes hexAIS fails.

(1) I have found hexAIS fails when a function that is set up in the TCF and implemented in the main file calls a C++ class instance or static function. For example, the following causes hexAIS to fail:

void TestNetworkTask()
{
 // NOTE: Parameter not used
 NetworkManager::NetworkStackTask(0);  
}

TestNetworkTask is the "Task function" for TSK0 in the TCF: It sets up the network. When the line "NetworkManager::NetworkStackTask(0)" is commented out then hexAIS works OK. NetworkManager is a C++ class and NetworkStackTask is a static function of the class. Why is hexAIS objecting to this?

I have also attempted to "hide" the C++'ness by wrapping the call in an extern "C" function within the NetworkManager CPP file and externing it from main. However, hexAIS also objects to this.

(2) Same problem with a PRD function in main that calls a C++ function via its class instance, i.e. ClassName::Instance()->Function(). The function is empty and hexAIS still objects.

(3) In the main function itself creation of some class instances is OK with hexAIS but others cause the hexAIS to fail. It seems completely arbitrary but I am wondering if it is related to C++ classes that contain a "TSK_create": i.e. their instance will ask for task creation but of course it will not happen until after main has returned.

Does hexAIS have problems when looking at C functions that call C++ class instances?

Does hexAIS have problems with creation of C++ class instances in main where the instance contains a TSK_create?

Note that this software runs on the DM6437 target from DDR2 via JTAG.

Also note that most of this software is used on a C6457 target that we have built with our own boot loader and the main is very similar and the software boots from flash and runs with no problems.

May not be the only problem but confirmed TSK_create in a C++ class seems to be a problem for hexAIS.

Part of my main is like this:

void main(void)
{
    ...

    Monitor::Instance();

    ....
}

main creates an instance (singleton) of the C++ class Monitor whose partial code (singleton instance and constructor) is as follows:

Monitor* Monitor::Instance(void)
{
    if (!Self)
    {
        Self = new Monitor();
    } // if

    return Self;
}

Monitor::Monitor(void)
{
    ....
    Handle = TSK_create((Fxn)Monitor::TaskFunction, &Attributes, 0, this);
    ....
}

If the TSK_create is present then hexAIS exceptions. If the TSK_create is commented out then hexAIS works OK.

I've looked at some different combinations of TSK_create lines to see what works with hexAIS and what does not. Note that Monitor::TaskFunction is a static member function.

 Handle = TSK_create((Fxn)Monitor::TaskFunction, &Attributes, 0, this); // hexAIS fails
 Handle = TSK_create((Fxn)NULL, &Attributes, 0, NULL); // hexAIS OK
 Handle = TSK_create((Fxn)Monitor::TaskFunction, &Attributes, 0, NULL); // hexAIS fails
 Handle = TSK_create((Fxn)NULL, &Attributes, 0, this); // hexAIS OK

So hexAIS objects to the TSK_create passing a static member function of a C++ class.

So I tried to "hide" the C++ class member static TaskFunction from the TSK_create as follows:

extern "C"
{
    void MonitorTaskFunction(Arg id_arg, Monitor* MonitorInstance)
    {
        Monitor::TaskFunction(id_arg, MonitorInstance);
    }
}

and instead do Handle = TSK_create((Fxn)MonitorTaskFunction, &Attributes, 0, this); so that the C function is called.

hexAIS still exceptions!

Then tried using the project option of parsing the main as a C file (the project is C++) and hiding the C++ class instances within extern'ed functions that are declared as extern "C" etc.

hexAIS does not like this either.

I now wonder if it is not the TSK_create per-se but is somehow related to what is called from within the task function.

After a bit of experimenting I put the following call StreamManager::Instance()->Status in the Monitor::TaskFunction. The Status function takes about 6 parameters. HexAIS fails.

However, if I have only StreamManager::Instance(), i.e. get the instance pointer but do nothing with it then hexAIS is OK.

I looks like hexAIS is objecting to calls to C++ singletons in external classes to the task function itself, or is this a coincidence and really it is objecting to the number of parameters to the function.

It makes no difference if I create the singleton in main before the Monitor singleton is created, e.g.

StreamManager::Instance();
Monitor::Instance();

I have also found somewhere else where when a call with 6 parameters is commented out hexAIS is OK but exceptions if the call is left in. The call is within the task function of another C++ class.

So, is there something inside hexAIS that limits the number of calls and / or parameters to a function within a task function?

I now believe that there is a correlation between hexAIS exceptions and the number of parameters in a function in a call path.

I have managed to get hexAIS to work OK without exceptions by making the following changes, although note that the software is not operational because of the changes I have had to make: i.e. it compiles and hexAIS does not exception but the software cannot run in this state.

(1)

main calls
Monitor::Instance() which performs
new Monitor::Monitor which does a TSK_create passing
void Monitor::TaskFunction(Arg id_arg, Monitor* MonitorInstance) as a parameter

The TaskFunction calls
Bool Monitor::OutputIsOK(LgUns currentTime) which calls
Bool Monitor::CheckStreamType(Int TypeOfStream, LgUns currentTime, Int* StreamCount) which calls
StreamManager::Instance()->Status

The StreamManager::Status has the following parameters (perhaps the actual types are not important but the number of parameters might be)

void StreamManager::Status
 (Int TypeOfStream,
  Int ID,
  BlockingQueuePool::BlockingQueuePoolDataType::BlockingQueuePoolStatusType* Status,
  BlockingQueue::BlockingQueueFailureDataType* FailureData,
  BlockingQueue::BlockingQueueBufferStatisticsType* BufferStatistics,
  BlockingQueue::BlockingQueueMetaDataType* MetaData,
  Synchroniser::SynchroniserStatusType* SynchroniserStatusData)

(2)

main calls
StreamManager::Instance()->RegisterStreamType which performs
new BlockingQueuePool which does a TSK_create passing
void BlockingQueuePool::TaskFunction(Arg id_arg) as a parameter

The TaskFunction calls
QueueData[id_arg][i]->Queue->Status

The BlockingQueuePool::Status has the following parameters (perhaps the actual types are not important but the number of parameters might be)

BlockingQueue::BlockingQueueStatusType BlockingQueue::Status
 (LgUns* LastPutTime,
  LgUns* LastGetTime,
  BlockingQueueBufferStatisticsType* BufferStatistics,
  BlockingQueueFailureDataType* FailureData,
  BlockingQueueMetaDataType* MetaData,
  Synchroniser::SynchroniserStatusType* SynchroniserStatusData)

(3)

TestNetworkTask is called by the DSP/BIOS TCF, which then calls
NetworkManager::NetworkStackTask which calls
NC_NetStart which has as a parameter
NetworkOpen which calls
DaemonNew which has as a parameter
NetworkManager::dtask_tcp which calls
HTTP_Status::Instance()->BuildStatusPage which is guaranteed to call other functions in its call path that have many parameters

I'm guessing that hexAIS is parsing the call path from main (perhaps only for TCF functions and tasks that are dynamically created) and is failing when it meets functions that have more than a specific number of parameters?

What I also find strange is why would hexAIS bother itself with call paths and parameters anyway: Note that hexAIS does not fail for example when the (for example) "Status" call exists in the code, it only fails when it is actually called in a call path initiated by main or TCF functions.

FYI I am building in debug mode.

I managed to get a hex file into the DM6437 using hexAIS but note that a lot is missing from the software because of the remaining problems in hexAIS as specified above.

Now I have another question: Is hexAIS inserting some sort of version checking code into the hex file?

My code runs in DDR2 over JTAG fine and in the TCF I use

environment['xdc.cfg.check.fatal'] = 'false';

in order to change version checking errors into warnings only.

On the target when emifa fast booting I have done a non-invasive connect in CCS (i.e. without running GEL) and loaded symbols in order to see what is going on.

The dissassembly shows that the code is in a tight loop around "versret" as follows:

8439F380          BIOS_init, BIOS_init, $package/cfg/DM6437_VideoDecoder_x64Pcfg.s62:2469:2506$:
8439F380 06D75BF9            CMPLTU.L1X    A26,B21,A13
8439F384 01C21CEA ||         MVKH.S2       0x84390000,B3
8439F388 01F9CE2A            MVK.S2        0xfffff39c,B3
8439F38C 00A902A8            MVK.S1        0x5205,A1
8439F390 00004000            NOP           3
8439F394 0188402A            MVK.S2        0x1080,B3
8439F398 01BC54F6            STW.D2T2      B3,*SP--[2]
8439F39C          versret$329$:
8439F39C 000C0362            B.S2          B3
8439F3A0 01C21EEA            MVKH.S2       0x843d0000,B3
8439F3A4 01FCB82A            MVK.S2        0xfffff970,B3
8439F3A8 00928C6E            LDW.D2T2      *+B14[4748],B1

Inspection of B3 shows the value 8439f39c and PC is 8439f39c according to the register view (and the green arrow shows the same in the dissassembly view).

Call stack shows $package/cfg/DM6437_VideoDecoder_x64Pcfg.s62:2469:2506$()

Inspection of the module shows it is the following:

;; MODULE INITIALIZATION
 .sect ".sysinit"
 .global BIOS_init, _BIOS_init
BIOS_init:
_BIOS_init:
 GBL_preamble
 GBL_init
 SEM_init
 ... etc

The green (PC) arrow is pointing to GBL_init so it's already executed GBL_preamble.

I don't understand why there is a tight loop going on at versret when my code runs OK from DDR2 on JTAG.

Is hexAIS invasively putting in some version checking code?

I notice that if I connect with GEL after the DM6437 has booted from flash and then "restart" the software reaches main OK.

I require an answer on this from TI because I have now reached an urgent decision point: Attempt to use hexAIS or abandon it and write my own bootloader that sets up PLL1/2, power domains, DDR2 and does a EMIFA ROM direct boot from 0x42000000.

I have got the image generated by hexAIS to boot by correcting some DDR2 timings in the INI file to match those that the GEL produces.

However, in order to get hexAIS to build the image I have had to comment out sections of code so the code runs but parts of it are not operational. It appears to be related to functions with many parameters but I have found cases where it is not and is quite arbitrary.

I started going through the code trying to find out what specifically hexAIS is objecting to and I considered re-architecting the code. However, I have no confidence that small code changes or a re-compile would always result in hexAIS operating correctly.

As I have already stated to the TI help [THREAD ID:1-B96VBU] reference number #1-680565010 I can provide an OUT file if required so that TI engineers can find out why hexAIS exceptions.

Now completely abandoned use of hexAIS and written my own multstage bootloader which works very well!