RTOS/TM4C1290NCZAD: Configuring zero latency interrupt in uartecho_DK_TM4C129X_TI_TivaTM4C129XNCZAD example project causes a crash

Todd - thank you - appreciated.

May we ask the name & location of the supporting document - which enabled your response?       To my best knowledge - (at least for the 4C123 series) - no such guidance appears.     (it is expected that such a document originated from ARM - yet they have many - and you've found/know the one "in play.")

In addition - if it is likely that other limitations or special handlings are required - would it not make sense for those to be "listed" - and well publicized - so that (many, other) posters do not fall (one after another) to such trap?

Thanks again...

Thank you - and surely that unification makes sense - for those likely to accept/bow to, "single vendor" (always & only.)

Appreciate your comments & insights.

You might consider that users such as my firm - required to select/support ARM MCUs from multiple sources (i.e the best source under that product/project's "selection criteria matrix") - will (necessarily) AVOID any such "vendor-locked" methods - as they prove "non-transferable."      (and will prevent Re-use, and further "build" upon such "broad" (multi-source) MCU knowledge base) 

ToddMullanix said:

It's for those use cases that we recommend using (what SYS/BIOS calls) zero-latency interrupts (with the noted restrictions).

A side note for other's reference. Other RTK/RTOS implementations will call these non-managed interrupts. The TI nomenclature here is somewhat odd and even a touch misleading.

Many RTKs implement a multi-leveled approach to interrupt handling involving

1. Unmanaged interrupts
   1. Normal interrupts. Do not save RTK context and so cannot make RTK calls or only a very restricted set of one or two (Say setting a semaphore). These have low overhead but since they cannot communicate with the main application very well are restricted in their use.
2. Managed interrupts
   1. This is the general purpose interrupt structure. They have sufficient context saved to allow a use of a subset of RTK calls. Typically that subset would include semaphores, FIFOs, queues etc.. They rely on triggering other threads to do the majority of the work within the RTKs priority scheme.
3. High/interrupt/Fast priority threads
   1. Special high priority threads that can be triggered by a managed interrupt. They have access to the full RTK set of calls.
4. Normal real time threads

Any particular RTK/RTOS  may have some subset of the above variations.

Robert

Hi,

Thank you very much for your responses.

I was able to configure GPIO P1 pin interrupt as zero latency. However, I could not get it to work when I was configuring the P1 pin using TI-RTOS's GPIO_init() function and related structures(please see the code below). Only when I configured the P1 pin using direct Tivaware calls (example below) I was able to use it as zero latency int.

This does not work:

GPIO_PinConfig gpioPinConfigs[] = {
    /* Input pins */
    /* DK_TM4C129X_BUTTON_SELECT */
   GPIOTiva_PP_1 | GPIO_CFG_IN_PU,
    /* DK_TM4C129X_BUTTON_UP */
    GPIOTiva_PN_3 | GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_RISING,
    /* DK_TM4C129X_BUTTON_DOWN */
    GPIOTiva_PE_5 | GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_RISING,



    /* Output pins */
    /* DK_TM4C129X_LED_G */
    GPIOTiva_PQ_7 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
    /* DK_TM4C129X_LED_B */
    GPIOTiva_PQ_4 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
    /* DK_TM4C129X_LED_R */
    GPIOTiva_PN_5 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW
};

GPIO_CallbackFxn gpioCallbackFunctions[] = {
    NULL,  /* DK_TM4C129X_BUTTON_SELECT */
    NULL,  /* DK_TM4C129X_BUTTON_UP */
    NULL   /* DK_TM4C129X_BUTTON_DOWN */
};


const GPIOTiva_Config GPIOTiva_config = {
    .pinConfigs = (GPIO_PinConfig *)gpioPinConfigs,
    .callbacks = (GPIO_CallbackFxn *)gpioCallbackFunctions,
    .numberOfPinConfigs = sizeof(gpioPinConfigs)/sizeof(GPIO_PinConfig),
    .numberOfCallbacks = sizeof(gpioCallbackFunctions)/sizeof(GPIO_CallbackFxn),
    .intPriority = 7 << 5
};


......

	/* Initialize peripheral and pins */
    GPIO_init();
	
	// Configure zero latency int
	Error_Block eb;
    Error_init(&eb);

    Hwi_Params params;
    Hwi_Params_init(&params);
    params.enableInt = true;
    params.priority = 1 << 5;

    Hwi_create(INT_GPIOP1, SelectButtonCb, &params, &eb);

And this works:

	
	GPIO_PinConfig gpioPinConfigs[] = {
    /* Input pins */
    /* DK_TM4C129X_BUTTON_SELECT */
   //GPIOTiva_PP_1 | GPIO_CFG_IN_PU,
    /* DK_TM4C129X_BUTTON_UP */
    GPIOTiva_PN_3 | GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_RISING,
    /* DK_TM4C129X_BUTTON_DOWN */
    GPIOTiva_PE_5 | GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_RISING,



    /* Output pins */
    /* DK_TM4C129X_LED_G */
    GPIOTiva_PQ_7 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
    /* DK_TM4C129X_LED_B */
    GPIOTiva_PQ_4 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
    /* DK_TM4C129X_LED_R */
    GPIOTiva_PN_5 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW
};


GPIO_CallbackFxn gpioCallbackFunctions[] = {
    //NULL,  /* DK_TM4C129X_BUTTON_SELECT */
    NULL,  /* DK_TM4C129X_BUTTON_UP */
    NULL   /* DK_TM4C129X_BUTTON_DOWN */
};

/* The device-specific GPIO_config structure */
const GPIOTiva_Config GPIOTiva_config = {
    .pinConfigs = (GPIO_PinConfig *)gpioPinConfigs,
    .callbacks = (GPIO_CallbackFxn *)gpioCallbackFunctions,
    .numberOfPinConfigs = sizeof(gpioPinConfigs)/sizeof(GPIO_PinConfig),
    .numberOfCallbacks = sizeof(gpioCallbackFunctions)/sizeof(GPIO_CallbackFxn),
    .intPriority = 7 << 5
};

.......


    /* Initialize peripheral and pins */
    GPIO_init();


    // Select button configuration
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOP);
    SysCtlDelay(2);
    GPIOPinTypeGPIOInput(GPIO_PORTP_BASE, GPIO_PIN_1);
    GPIOIntTypeSet(GPIO_PORTP_BASE, GPIO_PIN_1, GPIO_RISING_EDGE);
    GPIOIntEnable(GPIO_PORTP_BASE, GPIO_INT_PIN_1);


    Error_Block eb;
    Error_init(&eb);

    Hwi_Params params;
    Hwi_Params_init(&params);
    params.enableInt = true;
    params.priority = 1 << 5;

    Hwi_create(INT_GPIOP1, SelectButtonCb, &params, &eb);

Is that by design? Or am I missing something?

I also noticed that when I call Hwi_disable() and Hwi_restore inside of zero latency interrupt sometimes it does not work. Normal interrupts either does not get disabled or restored.

Is there any restriction on using these functions from zero latency ints?

Please find my project attached below for reference.

uartecho_zerolatency.zip