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.

SIMPLELINK-MSP432-SDK: Enabling the GPIO interrupt causes the I2C failure after 30 hours

Part Number: SIMPLELINK-MSP432-SDK

Hi Folks,

I am using MSP432P401R with FreeRTOS. When I configure the GPIO to handle the interrupt, the I2C read failure happens on I2C slave device after 30 hours since boot.

Way to configure the GPIO interrupt:

GPIO_setConfig(Board_GPIO_BUTTON0, GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_FALLING);

/* install Button callback */
GPIO_setCallback(Board_GPIO_BUTTON0, gpioButtonFxn0);

/* Enable interrupts */
GPIO_enableInt(Board_GPIO_BUTTON0);

Is there any reason that GPIO interrupt configuration can cause this kind of failure?

Regards,

Amit

  • After debugging further we found that when GPIO_setCallback is commented, the I2C failure is not observed. So somehow GPIO_setCallback is causing the I2C failure after ~30 hours.

    Also when the interrupt handler is empty the issue happens around 7h 45 mins and if the handler have some code then issue happens at ~30h.

  • Hello Amit,

    Does the issue go away just when you disable the interrupt but leave the callback?    Do you think it's a runtime issue / stack memory leak?  Have you checked your Stack pointer at failure?

    Unfortunanly the MSP432 is not recommended for new designs and the MSP432 SDK is no longer being maintained or updated.  There isn't much debugging I'll be able to do on my side.  

    Thanks,

    JD

  • Thanks JD for response. 

    "Does the issue go away just when you disable the interrupt but leave the callback?"

    Ans: Yes

    Do you think it's a runtime issue / stack memory leak?  Have you checked your Stack pointer at failure?

    Ans: When the issue happens the failure occurs for 1 sec then I2C communication starts working fine. How to check stack pointer? I cannot run application in debugging mode.

    Is there any other way to configure the interrupt? I am using FreeRTOS project.

    Regards,

    Amit

  • What is the (enabled) pin connected to? Do you have reason to suspect it is (ever) triggering?

    FreeRTOS imposes a maximum priority on your ISRs, which (skimming the code) TI-Drivers doesn't seem to know about. I don't have my materials here, but whenever I enable an interrupt I use something like (from memory):

    > NVIC_SetPriority(PORT1_IRQn, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY); 

    My experience is that violating this causes FreeRTOS to crash (not recover), which doesn't quite fit your symptom. Are you using the Watchdog (WDT)?

  • The interrupt is not triggered and still the I2C failures occurs at ~30 hours.

    Yes watchdog timer is configured.

    What is happens when GPIO_setCallback is called which we can relate to the issue?

  • I don't use TI-drivers, but the relevant source (on my system) is in:

    C:\ti\simplelink_msp432p4_sdk_3_40_01_02\source\ti\drivers\gpio

    so you can check for conflicts there. I dug it up since I wondered whether it clears the port pin IFG (it does). What it does seems fairly straightforward, though GPIO_init() creates a Semaphore, and I wonder whether that cooperates properly with FreeRTOS.

    I asked about the watchdog since if the system locked up (for whatever reason) the watchdog would "fix" the condition after some time, so we can consider "fatal" errors in the diagnosis.

  • Hi JD,

    If I register interrupt using "GPIO_CallbackFxn" in "GPIOMSP432_Config" structure the issue is not observed. What can go wrong with GPIO_setCallback mechanism?

    Regards,

    Amit

  • Hey Amit,

    So you are saying if you statically define the callback function in the GPIO_CallbackFxn element, your code works.  But if you dynamically set it with the GPIO_setCallback() function it breaks eventually?  

    I was reading about both in the TI drivers GPIO documentation, found in the SDK here: https://dev.ti.com/tirex/explore/node?node=ANw0S9TRUnZu6GuxbMlzjA__J4.hfJy__LATEST  

    The only real difference should be that one is static when building the project vs one being dynamically loaded.  Functionally, I'd expect both to work the same.  When run dynamically, could the pointer be held in RAM and somehow be corrupted/overwritten after a long period of time? 

    Thanks,

    JD 

  • Did you also set the appropriate portCallbackInfo[].pinindex[] element? GPIO_init sets this to CALLBACK_INDEX_NOT_CONFIGURED, so if you don't (manually) set it your callback won't be called.

  • The callback is set properly, and the handler is called when the signal is asserted. The issue happens in normal condition when signal is not asserted. We read sensor data over I2C, that works fine and after ~30 hours we see I2C failure for 1 sec and then again I2C communication starts working fine.