RTOS/CC1310: Custom error function and error storage on hard fault

Craig Easdale

Part Number: CC1310

Tool/software: TI-RTOS

I'm sure this isn't an unusual problem, but I haven't found anything so far that helps me solve the problem.

I want to be able to log errors to memory when one happens, so I can then trigger a soft reset to allow the device to continue function while allowing me to review the error later.

I've set up an error function in my release.cfg file, so any hard fault will be routed through the error module to this function. My plan is to then use the NVS driver to store some flags, and possible a string to memory.
My project is based around the WSN example, and this function resides in the main file which also houses the main() function.

void myErrorFxn(Error_Block *eb)
{

    // HWI exceptions are set to re-route here in release.cfg

    uint32_t error = 8; // Random value

    // Intialise NVS to store the error
    NVS_Params_init(&nvsErrParams);
    nvsErrHandle = NVS_open(1, &nvsErrParams);
    if (nvsErrHandle == NULL) {
        System_abort("NVS init fail\n");
    }

    uint32_t status = NVS_write(nvsErrHandle, 0, &error, sizeof(error), NVS_WRITE_ERASE);
    if(status != NVS_STATUS_SUCCESS){
        // If this happens we've got bigger problems!
        System_abort("NVS read error");
    }

    NVS_close(nvsErrHandle);

    // Then restart
    SysCtrlSystemReset();

}

I'm unable to get a non-null handle back when I call NVS_open(), despite this working fine elsewhere. The only other time I open this particular NVS region is to read it in the main task to read the memory contents, where it is then closed again immediately.

Is it just not possible to re-open a driver after a hwi exception/hard fault? If so, how can this type of incident be logged?

over 5 years ago

0 AB over 5 years ago

TI__Mastermind 19125 points

Hello Craig,

You cannot call that function from swi context. I would recommend doing all init else where (preferably on its own separate task with higher priority than the application), and inside the errorFxn you can post a semaphore.

This new task with high priority you created should pend on said semaphore forever (meaning it wont do anything until you post it) and when this error function posts it, it will service it. After the semaphore is pend goes through I would do all the writes you need. and then reset.

Regards,
AB

0 Craig Easdale over 5 years ago in reply to AB

Expert 2160 points

Hi AB,

Is this a fairly standard method to deal with monitoring system faults?
I guess I had assumed that the occurrence of a fault like this would prevent tasks from running as normal.

And in terms of posting the semaphore for the other task to act upon... To do this from another location would it be enough to extern the semaphore handle from this new 'error processing task' file?

0 Craig Easdale over 5 years ago in reply to Craig Easdale

Expert 2160 points

Hello, still waiting for a follow up on this.

0 AB over 5 years ago in reply to Craig Easdale

TI__Mastermind 19125 points

Hello,

Yes, this is a fairly standard method to verify system faults. CCS has other tools you can also use to help you pin point the issue.

As for the semaphore, yes, all you need is to extern the handle and you should be good.

Regards,
AB

0 Craig Easdale over 5 years ago in reply to AB

Expert 2160 points

Thanks for your reply.

For anyone who finds this thread later, I went on to ask some additional questions relating to use of the Error Module here: e2e.ti.com/.../748839

Sub-1 GHz

Sub-1 GHz forum

RTOS/CC1310: Custom error function and error storage on hard fault