• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 80 subscribers
  • Views 382 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/LP-MSP430FR2476: Debug mode causes MSP430FR2476 LP Out-of-Box application to ignore GPIO interrupts for several seconds

Greg JS
Prodigy 20 points

Part Number: LP-MSP430FR2476

Tool/software: Code Composer Studio

When using an unmodified Out-of-Box sample application inside CCS, the onboard LP debugger seems to disable GPIO interrupts for a few seconds, in a cyclic manner.

To replicate:

  • Compile and run the Out-of-Box sample application, with no modifications.
  • Execute "Debug" (F11).
  • Once the application starts and stops at the first line of code, execute "Resume" (F8).
  • Press the LP buttons: it will take several seconds for the messages to appear.
  • Everything else from the demo still works: the ADC is being read and the LEDs are updated, with PWM color coding fully working.

The issue does not happen when:

  • Running without the debugger enabled or using "Free Run" (Ctrl+F8).
  • Doing step-by-step debugging.
  • Calling "EUSCI_A_UART_transmitData" or writing directly to the TX buffer register inside the "while (1)", either before or after going to LPM0.
  • Sending a byte to the UART, like in the previous item, inside any periodic interrupt routine, such as inside the ADC ISR from the same example.

It seems that keeping the debugger active, by doing step by step debugging or sending bytes to its backchannel UART will prevent the issue from happening. Otherwise, it disables the GPIO interrupts, enables them for a short period, and then disables again for several seconds, repeatedly.

I've checked the demo code up and down: there are no interrupt masking instructions, and once the GPIO interrupts are enabled, they are never touched again.

  • 0
    Guru 102445 points

    I haven't used the OOB application on the FR2476, but I'm guessing it talks to a host GUI over the UART.

    When running the debugger, UART data to the PC "stutters", in that it comes out in bursts with a delay of maybe a few seconds. There appears to be buffering at ~64 bytes, since it's less obvious with longer data streams.

    As it was explained to me (somewhere on the E2E) this is an artifact of sharing the USB between the UART and the debugger.

  • 0 in reply to Bruce McKenney
    Prodigy 20 points

    That's correct. Thanks for the feedback.

    While my post was being authorized, I've executed more tests by changing the demo code to toggle LED1 inside the code that consumes the variable changed by the interrupt. The change is immediate. Connecting a logic analyzer to the UART also confirmed that it's the backchannel UART adapter that's buffering the data when debugging is enabled.

    So the interrupts are working fine, it's just the result of the interrupt execution, the UART output, that was being buffered by the development tool. So in case realtime access to the UART is needed while doing SBW with the board's embedded tool, it's better to plug an UART to USB converter to the pin bar.

**Attention** This is a public forum