CC2340R5MODA: unexpected configuration appears CPUIRQ0SEL

Part Number: CC2340R5MODA
Other Parts Discussed in Thread: CC2340R5

We have been observing some unexpected behavior on the CC2340R5.

We successfully configured wake-up from standby using a GPIO interrupt (via GPIO_setCallback and GPIO_enableInt). However, in some cases, the device hangs after the GPIO is toggled.

After further investigation, we found that execution ends up in the default ISR for CPUIRQ0 - Exception_handlerSpin() - as configured in ti_freertos_config.c.

While debugging the issue, we noticed that the CPUIRQ0SEL register is set to 0x9 (GPIO_COMB). As far as we are aware, neither our application nor the TI software stack explicitly modifies this register. CPUIRQ5SEL seems to be used for the GPIO_COMB in the GPIOLPF3 module. This unexpected configuration appears to be responsible for the interrupt that eventually leads to the exception handler.

What is particularly strange is that the issue disappears after a power cycle, but reappears after attaching a debugger and issuing a software reset.

 

Do you have any idea what could cause CPUIRQ0SEL to be configured this way after flashing or a software reset? For now, I am running the following at bootloader startup:

EVTSVTConfigureEvent(EVTSVT_SUB_CPUIRQ0, EVTSVT_PUB_NONE);

This workaround resolves the issue, but I would like to understand the root cause. Could this occur through any other means, and are there any other potential side effects or unexpected behaviors we should be aware of?

Any insights would be greatly appreciated.

  • Hello Jan,

    I don't happen to have a MODA at my desk so I want to ask you if this issue also occurs on your end with the driver example gpioshutdown, this example should configure the buttons to shutdown the device then the other button to wake up the device. 

    I know that if a device was set into the shutdown state and your resume from shutdown you need to add an extra step and release latches before continuing the program to make sure the GPIOs work correctly. 

     

      PowerLPF3_ResetReason resetReason = PowerLPF3_getResetReason();
      /* If we are waking up from shutdown, we do something extra. */
      if (resetReason == PowerLPF3_RESET_SHUTDOWN_IO)
      {
          /* Application code must always disable the IO latches when coming out of shutdown */
          PowerLPF3_releaseLatches();
      }

    Thanks,
    Alex F

  • Hi Alex

    Jan opened the thread for me.
    I have tried with the gpioshutdown example, the CPUIRQ0SEL register is not set after sending a software reset, and after a shutdown and wake-up, the system also doesn't hang. Then again, we never do a shutdown procedure, so the PowerLPF3_releaseLatches should not be performed, right? The issue seems to specifically be triggered due to the software reset setting the CPUIRQ0SEL register, so I am confused why it happens in our case, but not in the example.

    Kind regards
    Roeland Benoot

  • Hello Roeland, 

    As a test I just tried the gpioshutdown example and specifically set the register to CPUIRQ0SEL to 0x9 before shutdown, after coming out of shutdown (and releasing latches) the CPUIRQ0SEL is set back to 0x0 this might explain why the shutdown example is fine. If I then comment out the releaseLatches the device will not wakeup after shutdown. 

    Then again, we never do a shutdown procedure, so the PowerLPF3_releaseLatches should not be performed, right?

    Correct. 

    The issue seems to specifically be triggered due to the software reset setting the CPUIRQ0SEL register, so I am confused why it happens in our case, but not in the example.

    Do you happen to have some snippets of code from your application I can borrow in an attempt to replicate? As well as what specific SDK version you are using.

    Thanks,
    Alex F 

  • Hi Alex,

    Whilst I was trying to minimize our application, so I could give a better snippet of code where the issue occurs, I found out that I need to perform certain actions first before the issue occurs. Alas, I have not been able to figure out exactly what triggers it, so I will have to get back to this in 2 weeks.

    Thanks for your responses so far.

    Kind regards,
    Roeland Benoot

  • Hello Roeland Benoot, 

    Thank you for your update, I will wait on your further feedback here.

    Thanks,
    Alex F