TI-RTOS Mailbox_post problem

Milorad Podoaba

Other Parts Discussed in Thread: CC1310

Hi,

I've identified a problem in my software system. At a moment in time, the software doesn't come back from Mailbox_post call.

Here is a preview of my code:

task_key = Task_disable();

mailBoxMsgAvailable = FALSE;
for (i = 0u; i <= size; i++)
{
   idx = i % MAILBOX_MSG_LENGTH;
   mailBoxMessage[idx] = report[i];
   mailBoxMsgAvailable = TRUE;
   
   if (idx == (MAILBOX_MSG_LENGTH - 1))
   {
       Mailbox_post(rflevel2mailbox, mailBoxMessage, BIOS_NO_WAIT);
       mailBoxMsgAvailable = FALSE;
       memset(mailBoxMessage,0,MAILBOX_MSG_LENGTH);
   }
}

if (mailBoxMsgAvailable == TRUE)
{
   Mailbox_post(rflevel2mailbox, mailBoxMessage, BIOS_NO_WAIT);
}

Task_restore(task_key);

The mailbox is working fine for multiple times, but after awhile the software is not coming back from the the last Mailbox_post call.

I've tried to debug what's inside the function but I could see only assembly code so is nearly impossible to see what is going on.

I've tried to change the application code several times but the software is still hangs sometimes sooner sometimes later.

I've also tried to enable debugging feature like task load, task profiling but the code is becoming too large and it doesn't fit in 128k.

If you have any ideas what could cause this problem please let me know.

Regards,

Milorad

over 9 years ago

0 Alan DeMars over 9 years ago

TI__Mastermind 30830 points

Why are you disabling the task scheduler while posting the messages to the Mailbox?

Disabling the Task scheduler by calling Task_disable() will defeat the behavior of blocking calls such as Mailbox_post(), and will corrupt the internal data structures used to manage task scheduling. If you had Asserts enabled in your build (BIOS.assertsEnabled = true), I believe an Assert would have been raised within the call to Mailbox_post() when the internal Semaphore_post() call was invoked within the Mailbox_post() code.

Alan

0 Milorad Podoaba over 9 years ago in reply to Alan DeMars

Intellectual 765 points

Hi Alan,

Removing Task_disable()-Task_restore() calls will not make the problem go away.

I'm using Task_disable because I want to avoid any preemption until the full report is in the mailbox. I'm also checking how much space is available in the mailbox before.

Why would you say that these calls are corrupting some internal data?
The documentation says that these calls are preventing only other task to run. Am I missing something?

In order to make the asserts enabled I would need the BIOS to be in flash memory?
What kind of check would trigger the assert? NULL pointer or others?

Milorad

0 Milorad Podoaba over 9 years ago in reply to Alan DeMars

Intellectual 765 points

I move the BIOS in flash memory.

Now the I see that the software is stuck in this endless loop:

/*
 *  ======== Hwi_excHandler ========
 */
Void Hwi_excHandler(UInt *excStack, UInt lr)
{
    Hwi_module->excActive[0] = TRUE;

    /* spin here if no exception handler is plugged */
    while (Hwi_excHandlerFunc == NULL) {
	;
    }

    Hwi_excHandlerFunc(excStack, lr);
}

I know you can enable HW exception behavior in cfg but all I want to know is why this hardware exception is thrown.

Any ideas?

Milorad

0 Alan DeMars over 9 years ago in reply to Milorad Podoaba

TI__Mastermind 30830 points

Quite often, this is due to reading or writing a peripheral that has not been powered on yet.
The ROV Hwi module's Exception view tab should decode the exception and provide a stack backtrace of the code leading up to the exception. The stack backtrace feature works best if you build using BIOS.libType = BIOS.libType_Debug, which provides the debugger more symbolic debug information.

Alan

0 Milorad Podoaba over 9 years ago in reply to Alan DeMars

Intellectual 765 points

I think I've solved the problem.

I've started to change the compiler optimization level and code-speed trade off setting.
Apparently if I set the optimization level to 2 and trade off to 4or5 the problem is gone.

If I set the trade off between 0-2 the debugger shows following error:

Cortex_M3_0: GEL Output: Memory Map Initialization Complete.
Cortex_M3_0: GEL Output: Board Reset Complete.
Cortex_M3_0: JTAG Communication Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.407.6)
Cortex_M3_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

Probably the CC1310 is resetting.

If I set it to 3, things are starting to look better. But still after awhile the software would be stuck in a strange loop.

This is not the first time I have problems with TI compiler. I do not understand why it has so many issues. If you try to use some optimization it won't be reliable.

Milorad