• State Resolved
  • Locked Locked
  • Replies 25 replies
  • Subscribers 80 subscribers
  • Views 3030 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/MSP432P401R: Program hangs waiting for changes even after the change occurs

Steven Hunter
Intellectual 420 points

Part Number: MSP432P401R

Tool/software: Code Composer Studio

I have had this happen waiting for an input bit to change and also waiting for a variable to change that is changed in an interrupt routine. If I Pause the program and Run again immediately, it works fine.

The part waiting for a bit to change is a very short while loop and is identical to another while loop waiting for a different bit to change on a different port. I have checked the port direction register and it is correct.

The part waiting for a variable to change is a null loop waiting for the test variable to change. It works fine for the first change, but not later. Again, pausing and running again gets it through.

  • 0
    TI__Guru**** 244380 points
    Hello Steven

    Can you please attach a simplified version of your code? Also please let us know which SimpleLink SDK version you are using, whether your application is using TI Drivers or DriverLib function calls.
  • 0 in reply to Amit Ashara
    Intellectual 420 points

    This hangs until I Pause and then Resume:

         uint32_t chargeCount = 0;

         while(chargeCount == 0){

              if ((P6->IN & BIT6) == BIT6) {

                   chargeCount++;

              }

         }

    This works fine:

    uint32_t risingEdgeCount = 0;

               // waiting for current to exceed upper threshold

              while(risingEdgeCount != 1){

                   if ((P2->IN & BIT6) == BIT6){

                         risingEdgeCount++;

                   }

              }

    The first piece of code works the second time through the function.

  • 0 in reply to Amit Ashara
    Intellectual 420 points
    I forgot to mention that the pins being read have been verified through the debugger to be defined as inputs, and the input bits are high.
  • 0 in reply to Steven Hunter
    TI__Guru**** 244380 points
    Hello Steven,

    Are the variables declared as global? Also did you try to put a break point at the increment statement to see if the condition is being executed?
  • 0 in reply to Amit Ashara
    Intellectual 420 points

    As shown in the code, the variables are declared immediately before they are used.

    I put a statement to write to the Red LED on the LaunchPad just before the "if statement" and it does not execute.

    The second time I go through this function, it usually works.

    It is like the processor is going to sleep and not waking up. I have a T32 timer interrupt handler that should wake it up. The user interface interrupt routine continues to work.

  • 0 in reply to Steven Hunter
    Guru 95685 points
    Are you using SleepOnIsrExit? That could produce symptoms similar to this.
  • 0 in reply to Steven Hunter
    Expert 2220 points

    See if change this makes any difference.

    volatile uint32_t chargeCount = 0;

  • 0 in reply to Steven Hunter
    TI__Guru**** 244380 points
    Hello Steven,

    In addition to the inputs from the forum member, could you specify if the loop is run in main or inside an interrupt handler. Inside an interrupt handler you do not need to create a while loop as the interrupt should wake up the CPU and the status should be set for the bit.
  • 0 in reply to Amit Ashara
    Intellectual 420 points

    This loop is in main.

  • 0 in reply to Steven Hunter
    Expert 2220 points
    Where else is the value of chargeCount changed? Please show all code that touches this variable.
  • 0 in reply to quark
    Intellectual 420 points
    That is the only place. It was set up to allow some filtering. I reduced the test value to make sure that it worked.
  • 0 in reply to Steven Hunter
    Expert 2220 points
    In the first loop, if you change P6 with P2, does the code stop hanging? If yes, check that P6 bit6 is initialized correctly, it should be like P2.
  • 0 in reply to Steven Hunter
    TI__Guru**** 244380 points

    8561.gpio_input_interrupt.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    /* --COPYRIGHT--,BSD
    * Copyright (c) 2017, Texas Instruments Incorporated
    * All rights reserved.
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the distribution.
    *
    * * Neither the name of Texas Instruments Incorporated nor the names of
    * its contributors may be used to endorse or promote products derived
    * from this software without specific prior written permission.
    *
    * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
    * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
    * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
    * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
    * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
    * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
    * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
    * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
    * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
    * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
    * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    * --/COPYRIGHT--*/
    /*******************************************************************************
    * MSP432 GPIO - Input Interrupt
    *
    * Description: This example demonstrates a very simple use case of the
    * DriverLib GPIO APIs. P1.1 (which has a switch connected to it) is configured
    * as an input with interrupts enabled and P1.0 (which has an LED connected)
    * is configured as an output. When the switch is pressed, the LED output
    * is toggled.
    *
    * MSP432P401
    * ------------------
    * /|\| |
    * | | |
    * --|RST P1.0 |---> P1.0 LED
    * | |
    * | P1.1 |<--Toggle Switch
    * | |
    * | |
    *
    ******************************************************************************/
    /* DriverLib Includes */
    #include <ti/devices/msp432p4xx/driverlib/driverlib.h>
    /* Standard Includes */
    #include <stdint.h>
    #include <stdbool.h>
    int main(void)
    {
    /* Halting the Watchdog */
    MAP_WDT_A_holdTimer();
    /* Configuring P1.0 as output and P1.1 (switch) as input */
    MAP_GPIO_setAsOutputPin(GPIO_PORT_P1, GPIO_PIN0);
    MAP_GPIO_setOutputLowOnPin(GPIO_PORT_P1, GPIO_PIN0);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Hello Steven

    I modified the gpio_input_interrupt example from the latest MSP432P4 SDK (see attached main code). The code that you mentioned works fine w/o the need to halt and resume. I ran the code in CCS with ARM Compiler.

  • 0 in reply to Amit Ashara
    Intellectual 420 points
    My code is in main, not in an interrupt routine.

    I am not familiar with the MAP_GPIO functions that you used. Are those standard? Where can I find info on them?
  • 0 in reply to quark
    Intellectual 420 points
    This did not help. I also tried moving the declaration to the beginning of main, but that did not help.
  • 0 in reply to Steven Hunter
    TI__Guru**** 244380 points
    Hello Steven

    From you very first post "I have had this happen waiting for an input bit to change and also waiting for a variable to change that is changed in an interrupt routine." and the subsequent post that it is in Interrupt routine, I deduced the example.

    Secondly, the MAP_GPIO functions are available as part of the driverlib examples in the SDK. Can you please modify the example code that I provided to replicate the issue?
  • 0 in reply to Steven Hunter
    Guru 95685 points

    Try not using it (i.e. SleepOnIsrExit), since it can cause symptoms like this.

    [Edit: Added antecedent.]

  • 0 in reply to Bruce McKenney
    Intellectual 420 points
    I put in breakpoints to try to debug code, but when I single step, it jumps around all over. It jumps several lines up or down and then back again.
  • 0 in reply to Steven Hunter
    Guru 95685 points
    This sounds like the optimizer at work. You can try -O0 or (what I do) just live with it.

    Did this start happening when you stopped using SleepOnIsrExit? It may actually indicate that your program is operating (more) properly.
  • 0 in reply to Bruce McKenney
    Intellectual 420 points
    It single steps properly now.
    It still stops in the main routine. It really looks like it is going to sleep, but hitting Pause and Run gets it going.
  • 0 in reply to Steven Hunter
    Guru 95685 points
    You haven't given us much context, so we're all really just guessing. How big is your program? Is it something you can post? Even just main()?
  • 0 in reply to Bruce McKenney
    Intellectual 420 points
    I masked off the SleepOnExit bit and now it works!!!!
    I don't know why it worked before with SleepOnExit enabled, but I don't care.
    Thank you for all of your time. I really appreciate the help that all of you gave me.
  • 0 in reply to Steven Hunter
    Guru 95685 points
    SleepOnIsrExit is hazardous unless your (entire) program is architected to use it.

    In general, once you enter that mode you shouldn't count on main() to accomplish anything -- maybe it will, maybe it won't, depending on when interrupts go off.

    I'm glad you're running again.
  • 0 in reply to Bruce McKenney
    Intellectual 420 points
    Thanks for the advice. I was considering trying to get SleepOnIsrExit working again in my UART handler so that it wouldn't interfere with a function that delays for a certain amount of time based on a Timer32 interrupt. Now, I will just check a flag set in the Timer32 interrupt handler. If it woke from sleep for some other reason, back to sleep until the Timer32 interrupt. No more SleepOnIsrExit for me.

**Attention** This is a public forum