RTOS/CC1350: Error handling with the error module and dedicated task in RTOS/sysBIOS, and testing

Very informative and detailed post, thank you!

I've managed to replicate exactly what you did with the memory fault and the error block that was generated. 

My understanding now is that the two args are never going to have a set definition, and are relevant to the type of error generated by Error_raise() and whatever values that wishes to pass. It helps to know that, although it does make it a little trickier to add context to those parameters on fly.

I've attempted to use BIOS.customCCOpts += " -Dxdc_FILE=__FILE__ "; in my release.cfg to test having the file names generated. I'm checking the original Error_Block and also doing a Error_getSite(eb) but still only getting the line number and 'mod' back. I'm not certain f I would need to use this, but I would like to be able to check the footprint hit.

I suppose my main concern is getting out an error ID and mod value, but it doesn't actually help me pin down the source of the error. This, for example, would only vaguely hint at the problem being heap memory related, but I still wouldn't have a great idea where in the application it originated.

In the past, prior to using a custom error handler, I ended up in a hwi exception handler infinite loop. I had always assumed this was as a result of a hwi exception or hard fault, but perhaps that's just where it went for every fault?

Either way, I would love to be able to easily pinpoint the source of the problem easily, but other than potentially a vague message, I don't have any list I could look up to narrow an error down if these id's were reported (I'm sure a HWI Exception could have many triggers, for example). It's the kind of thing that could potentially happen after a long period too, so it's difficult to resolve with trial-and-error changes to the application.

I guess what I'm asking is,

1. what would be the process for pinpointing a random, unexpected error from only an error code and mod value and the two Args?
2. Is this even possible without also having line number and file name?

My end goal here is just to be able to extract error information that allows me to identify problem application code with a good degree of certainty, but I'm still feeling like there could be a fair bit of guessing involved.

Again, many thanks for your original reply, it provided a lot of helpful information despite what my follow-up questions might make you think!

That sounds like a good low-footprint solution. It should be easy enough to make the information more relevant now I understand how, thank you. 

One thing I'm noticing now is that when myErrorFxn() is called it will immediately leap out of this and into the two functions below it, one after another.
For now I have commented out what was inside so they run through regardless and allow myErrorFxn to post a semaphore to unblock the task and process the error. I have also commented out the semaphore_post() in myErrorFxn to follow the series of errors without the task interfering...

void myErrorFxn(Error_Block *eb)
{
    // HWI exceptions are set to re-route here in release.cfg

    // Save the relevant error information
    Types_Site *site;
    Error_Data *args;

    site = Error_getSite(eb);
    args = Error_getData(eb);

    lastError.timestamp = Seconds_get();
    lastError.code = Error_getId(eb)>>16;
    lastError.line = site->line;
    lastError.mod = site->mod;
    lastError.arg0 = args->arg[0];
    lastError.arg1 = args->arg[1];

    // Post the semaphore to being processing the error
    //Semaphore_post(errorHandlerSemHandle);


}

void mySysCallbackAbortFxn(CString str)
{
    //while(1);
    //SysCtrlSystemReset();
}

void mySystemAbortFxn(uint32_t val)
{
    //while(1);
    //SysCtrlSystemReset();
}

Before it jumps into these two functions, in myErrorFxn() I'm getting what you had in your first example, much as I'd expect:
Error: 34, Mod: 47, Line: 307
( HeapMem_E_memory, <modMap key="ti.sysbios.heaps.HeapMem"> )

On leaving myErrorFxn() it enters mySysCallbackAbortFxn(), and the CString is showing "xdc.runtime.Error.raise:.terminating.execution". It then jumps into mySystemAbortFxn().

Following this we're straight back into myErrorFxn, but this time reporting a different error:
Error: 3, Mod: 9, Line 52
( xdc_runtime_Error_E_memory__C,  <modMap key="xdc.runtime.Memory"> )

As it runs through the other two functions again the same as before is reported.

I've tried to use the method you described above in an attempt to pin down and debug this error, and I found the xcd/runtime/memory.c file. It seems that line is from the Memory_alloc() function:

if (block == NULL && (prior || !Error_check(eb))) {
        Error_raise(eb, Error_E_memory, (IArg)heap, (IArg)size);
    }

Is there some sort of overlap with Error_raise() and the sysCallback/SystemAbort error handlers that I haven't considered? It creates a difficult situation where I can't even store the first before the second error interrupts the task again.