This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/SIMPLELINK-MSP432-SDK: Semaphore Post from HWI causes Exception

Part Number: SIMPLELINK-MSP432-SDK

Tool/software: TI-RTOS

I am trying to post a semaphore from my UART HWI and I"m getting an exception:

My setup is as follow:

  • CCS  Version: 7.3.0.00019 
  • XDC Tools 3.50.5.12_core
  • SimpleLink MSP432P4 SDK 2.10.0.14
  • Ubuntu Virtual Box VM Development platform
  • Older "Black" MSP432Pr401R Launchpad Eval Kit

ti.sysbios.knl.Task: line 424: E_spOutOfBounds: Task 0x200099f0 stack error, SP = 0x20008ac4. xdc.runtime.Error.raise: terminating execution

I believe this is because the the HWI's are running as zero-latency interrupts. 

It seems like these interrupts also prevent me from passing a param into the HWI.

Is there any way I can disable the zero-latency interrupt for these, so I can make the OS Calls?

Cfg File Example:

/* ================ Hwi configuration ================ */
var halHwi = xdc.useModule('ti.sysbios.hal.Hwi');
var m3Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
/*
 * Checks for Hwi (system) stack overruns while in the Idle loop.
 *
 * Pick one:
 *  - true (default)
 *      Checks the top word for system stack overflows during the idle loop and
 *      raises an Error if one is detected.
 *  - false
 *      Disabling the runtime check improves runtime performance and yields a
 *      reduced flash footprint.
 */
halHwi.checkStackFlag = true;
//halHwi.checkStackFlag = false;

/*
 * The following options alter the system's behavior when a hardware exception
 * is detected.
 *
 * Pick one:
 *  - Hwi.enableException = true
 *      This option causes the default m3Hwi.excHandlerFunc function to fully
 *      decode an exception and dump the registers to the system console.
 *      This option raises errors in the Error module and displays the
 *      exception in ROV.
 *  - Hwi.enableException = false
 *      This option reduces code footprint by not decoding or printing the
 *      exception to the system console.
 *      It however still raises errors in the Error module and displays the
 *      exception in ROV.
 *  - Hwi.excHandlerFunc = null
 *      This is the most aggressive option for code footprint savings; but it
 *      can difficult to debug exceptions. It reduces flash footprint by
 *      plugging in a default while(1) trap when exception occur. This option
 *      does not raise an error with the Error module.
 */
m3Hwi.enableException = true;
//m3Hwi.enableException = false;
//m3Hwi.excHandlerFunc = null;

/*
 * Enable hardware exception generation when dividing by zero.
 *
 * Pick one:
 *  - 0 (default)
 *      Disables hardware exceptions when dividing by zero
 *  - 1
 *      Enables hardware exceptions when dividing by zero
 */
m3Hwi.nvicCCR.DIV_0_TRP = 0;
//m3Hwi.nvicCCR.DIV_0_TRP = 1;

/*
 * Enable hardware exception generation for invalid data alignment.
 *
 * Pick one:
 *  - 0 (default)
 *      Disables hardware exceptions for data alignment
 *  - 1
 *      Enables hardware exceptions for data alignment
 */
m3Hwi.nvicCCR.UNALIGN_TRP = 0;
//m3Hwi.nvicCCR.UNALIGN_TRP = 1;

/***** Some Other Stuff ****/
halHwi.dispatcherAutoNestingSupport = false;
var halHwi0Params = new halHwi.Params();
halHwi0Params.instance.name = "hHwiEusciA2";
halHwi0Params.arg = 2;
halHwi0Params.enableInt = false;
halHwi0Params.priority = 3;
Program.global.hHwiEusciA2 = halHwi.create(34, "&Msp432UartIsrA2", halHwi0Params);

var halHwi1Params = new halHwi.Params();
halHwi1Params.instance.name = "hHwiEusciA0";
halHwi1Params.priority = 3;
halHwi1Params.enableInt = false;
Program.global.hHwiEusciA0 = halHwi.create(32, "&Msp432UartIsrA0", halHwi1Params);

  • Hello Mark,

    look at this:
    <install_dir>/simplelink_msp432p4_sdk_2_10_00_14/release_notes_simplelink_msp432p4_sdk_2_10_00_14.html
    "Black" is not supported by this SDK.
  • Hi Tomasz, 

    I appreciate the feedback, but this is not related to silicon or board version.  This issue happens on red and black versions of the board. 

    I have verified that this problem follows the software and not he board, as I recently purchased the "red" version of the board and get the same results.

    This really seems to be related to the the Zero Latency Interrupts.  How do we go about using standard HWI instead of Zero Latency HWI?

  • This is a software issue, not a hardware issue (see below). The problem shows up on both red and black boards.
    It appears to be related to the zero latency HWI vs. the standard HWI.
  • I resolved the issue. I changed the HWI disablePriority to 16, and changed my ISR priorities to something greater than 16.
    This prevented the ISRs from being zero-latency interrupts and allowed me to perform the semaphore posts in the ISR

    var halHwi0Params = new halHwi.Params();
    halHwi0Params.instance.name = "hHwiEusciA2";
    halHwi0Params.arg = 2;
    halHwi0Params.enableInt = false;
    halHwi0Params.priority = 18;  // PRIORITY > m3Hwi.disablePriority, to eliminate zero-latency interrupt
    Program.global.hHwiEusciA2 = halHwi.create(34, "&Msp432UartIsrA2", halHwi0Params);
    
    var halHwi1Params = new halHwi.Params();
    halHwi1Params.instance.name = "hHwiEusciA0";
    halHwi1Params.priority = 18; // PRIORITY > m3Hwi.disablePriority, to eliminate zero-latency interrupt
    halHwi1Params.enableInt = false;
    Program.global.hHwiEusciA0 = halHwi.create(32, "&Msp432UartIsrA0", halHwi1Params);
    
    m3Hwi.disablePriority = 16;  // Lower Disable Priority

  • Hello Mark,

    first of all, I am glad that you have resolved your issue and that you have posted your findings.

    My reply to your post was in good faith.

    Let me put some remarks on your post and findings.

    Your post is dated May 15th.

    The post has 4 replies (3 yours and one of mine) and 78 viewers.

    Conclusion 1: no one wants to invest your own time to investigate issue having an incompatible software stack.

    Conclusion 2: using a "black" edition placed your issues into a s/w incompatibility, not a h/w category.

    I have not tried to investigate your issue after I have found a "black" show stopper.

    From the begin you were right in your findings: "I believe this is because the the HWI's are running as zero-latency interrupts."

    TI-RTOS does not allow to call any SYS-BIOS Scheduler functions from within the zero-latency interrupts.

**Attention** This is a public forum