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.

LPSTK-CC1352R: strange problems with debugger

Part Number: LPSTK-CC1352R
Other Parts Discussed in Thread: SEGGER, SYSCONFIG, LAUNCHXL-CC1352R1

Good afternoon everyone, I'm experiencing some strange new problems on the LPSTK-CC1352R board I have.
Until yesterday, it worked just fine, but then, inexplically, it started having some issues regarding the timer and uart2.

It's actually quite difficult to describe, but it looks like that the debug reset and shutdown do not work properly anymore. What I mean is that, they do reset and shutdow the debugger, but then the code won't work properly anymore, with some unpredictable behaviour, ranging from being stuck in the function "HwiP_dispatch" or not calling the interrupts anymore. Even stranger than this, sometimes it will work as expected and some other times it will behave like this. I also noticed that turning off the board helps most of the times and that it will surely have problems if the debugger is resetted of shutdown while the timer or uart2 are still operating (not stopped).

The code I'm testing these problems on was already tested and it worked just fine. These problems surface even when using TI own examples.
For example, let's take a no-rtos example with the time interrupt, having it have a led blink each second. This is a standard TI example and it worked no problem before, but now, most of the times, these problems will pop up.

I'm having a hunch that it has to do with the battery alimentation, however, even after changing them with fresh new ones the problems did not go away.
Did somebody have a similar experience before? It is driving me crazy.

  • Hi Matteo,

    I haven't heard about this behavior before.

    Could you provide some more details, preferably steps to reproduce?

    - Can you show your debugger setup

    - What do you meant by "debug reset and shutdown"?

    Cheers,

    Marie H

  • Thank you for your response.

    To answer your questions, here's a simple way that gave me this odd behaviour.
    Take TI own example called "timerled" from the SimpleLink CC13xx CC26xx SDK. The only modification I have done to it is to copy the timerled.c code in a No-RTOS environment (like the one from the "gpiointerrupt" example).
    Before I experienced these problems, it worked just fine. The example is a simple one, it basically starts a timer and it lets a led blink every 1s. After these problems started occurring, this simple example started acting strange too.

    My debugger setup is the same as the default one (I'm using CCS version 12.1.0.00007), with the following exceptions:
    - "Halt the target before any bebugger access (will impact servicing of interrupts)" checkbox is checked.
    - The optimization level is -O0.
    - Added "-ffunction-sections -fdata-sections" to the compiler flags (if missing).
    - Added "-Wl,--gc-sections" to the linker flags (if missing).

    It probably shoud be noted that I'm using a Segger J-Link and that the compiler version is GNU v9.2.1 (Linaro).

    Lastly, by "debug reset and shutdown" I respectively mean the "Restart" (the yellow semicircular arrow topped by a green play icon/triangle) and "Terminate" (the red square) buttons from the bar at the top of the debug view.

  • Hi Matteo,

    Thank you for the detailed description.

    1. To restart the program in a debug session, please use the Board reset button:

    2. Which version of the SimpleLink CC13xx/CC26xx SDK are you using?

    3. I'm wondering whether this is related to the switch between TI RTOS timer and nortos. However if you are using one of the newer SDKs, DPL (driver porting layer) should handle this. Are you ultimately planning to use TI RTOS?

    Cheers,

    Marie H

  • Hi Maria.

    I will try to use the "Board Reset" button for now on. I'm going to do some tests with it later, to see if it helps, and then I'll let you know the results.
    EDIT: I actually do not have those options. That button only gives me the "CPU Reset" and "Core Reset" options.

    As for the version of the SimpleLink CC13xx/CC26xx SDK that I'm using, the one I have tested it on is the 6.30.00.84 version.

    Lastly, I'm actually planning on remaining on nortos, so I'm trying to avoid using TI RTOS.

    However, keep in mind that I've worked on this board for months before experiencing these strange problems, meaning that all these things (how to restart the program in a debug session, the SDK version and nortos) didn't affect me in the past.

  • Hi Matteo,

    The reset options may be set by the Segger debugger, Have you reached out to the Segger team with this issue?

    If you post your code I can run it on a LaunchPad and see if I can reproduce the issue. I'm not sure what else I can do to help you move forward.

    Cheers,

    Marie H

  • Hi Marie,

    Ok, I'll now post the code for that timerled No-RTOS example I was talking about earlier.
    Everything else is as I described so far (versions, debugger setup, etc).

    main_nortos.c file

    /*
     * Copyright (c) 2017-2020, 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.
     */
    
    /*
     *  ======== main_nortos.c ========
     */
    #include <stdint.h>
    #include <stddef.h>
    
    #include <NoRTOS.h>
    
    #include <ti/drivers/Board.h>
    
    extern void *mainThread(void *arg0);
    
    /*
     *  ======== main ========
     */
    int main(void)
    {
        Board_init();
    
        /* Start NoRTOS */
        NoRTOS_start();
    
        /* Call mainThread function */
        mainThread(NULL);
    
        while (1) {}
    }
    


    timerled.c file
    /*
     * Copyright (c) 2016-2020, 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.
     */
    
    /*
     *  ======== timerled.c ========
     */
    
    #include <stddef.h>
    
    /* Driver Header files */
    #include <ti/drivers/GPIO.h>
    #include <ti/drivers/Timer.h>
    
    /* Board Header file */
    #include "ti_drivers_config.h"
    
    /* Callback used for toggling the LED. */
    void timerCallback(Timer_Handle myHandle, int_fast16_t status);
    
    /*
     *  ======== mainThread ========
     */
    void *mainThread(void *arg0)
    {
        Timer_Handle timer0;
        Timer_Params params;
    
        /* Call driver init functions */
        GPIO_init();
        Timer_init();
    
        /* Configure the LED pin */
        GPIO_setConfig(LED1, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);
    
        /* Turn off user LED */
        GPIO_write(LED1, CONFIG_GPIO_LED_OFF);
    
        /*
         * Setting up the timer in continuous callback mode that calls the callback
         * function every 1,000,000 microseconds, or 1 second.
         */
        Timer_Params_init(&params);
        params.period        = 1000000;
        params.periodUnits   = Timer_PERIOD_US;
        params.timerMode     = Timer_CONTINUOUS_CALLBACK;
        params.timerCallback = timerCallback;
    
        timer0 = Timer_open(TIMER, &params);
    
        if (timer0 == NULL)
        {
            /* Failed to initialized timer */
            while (1) {}
        }
    
        if (Timer_start(timer0) == Timer_STATUS_ERROR)
        {
            /* Failed to start timer */
            while (1) {}
        }
    
        return (NULL);
    }
    
    /*
     * This callback is called every 1,000,000 microseconds, or 1 second. Because
     * the LED is toggled each time this function is called, the LED will blink at
     * a rate of once every 2 seconds.
     */
    void timerCallback(Timer_Handle myHandle, int_fast16_t status)
    {
        GPIO_toggle(LED1);
    }
    


    Also, on my sysconfig file I have configured the launchpad red led (named LED1) and a 32 bit timer (named TIMER).

    As always, keep in mind that, this simple example with this exact setup worked just fine until last month, when these strange problems started occurring.

  • Just wanted to let you know that we have reproduce the issue and are working on this.

    BR

    Siri

  • Thanks. I'm looking forward to hear more about your future findings on this.

    Speaking of this, I've also recently experienced a similar problem on the LAUNCHXL-CC1352R1 board (this time used without the SEGGER J-Link) using the restart button on the debug window. On this latter board, however, the debug window manages to show to me the "Board Reset" option (which wasn't present when I debugged LPSTK-CC1352R) and it works as Marie expected, but it does not resolve the issue in the long run, only in the current issue.

  • Siri, Matteo, 

    Just want to confirm - the issue was also reproduced using the onboard XDS110 of the LAUNCHXL-CC1352R1 board using CCS 12.1.0?

    Thanks

    ki

  • Exactly.

    EDIT: Today I started working on the LP-CC1312-R7 board and I actually tested if it behaved the same on this issue. After some tests, I can confirm that LP-CC1312-R7 behaved just like LAUNCHXL-CC1352R1 did (with XDS110 and CCS 12.1.0).

  • I can reproduce the issue on the custom (non-RTOS based) timer led example when I restart. It only seems to occur with that example. All other examples do not exhibit the issue.

    A note about "restart". The debugger simply sets the program counter to the entry point of the loaded application. Nothing else happens. If the program fails to run correctly after that, I do not have an explanation as to why.  Usually the device gets into bad state and a system/board reset will resolve it (which it does for me also). Why it gets into a bad state is unknown. But it is typically some issue with the application itself. Given that only this custom/modified example has the issue, I suspect the root cause is coming from that. I don't have the device knowledge to provide much more insight than that.

  • Siri - can you reproduce this issue on standard (unmodified) SDK examples also?

  • One thing of note is that, before December 22nd it worked just fine for me; for whatever reason these problems started occurring after that date.
    Furthermore, the modified timerled example was just one instance (the simplest one) of that problem occurring to me, other NO-RTOS programs of mine (which, once again, worked just fine before December 22nd) started having the same issues at the same time, and not just with the timer peripheral, but also with the uart2 one, as I explained further back into this thread.

  • other NO-RTOS programs of mine (which, once again, worked just fine before December 22nd) started having the same issues at the same time, and not just with the timer peripheral, but also with the uart2 one, as I explained further back into this thread.

    Are the other NO-RTOS programs ones that have been modified or are they the original SDK examples? Can you reproduce this with standard SDK examples?

  • I'm talking about NO-RTOS programs of mine that I have modified starting from examples. I haven't tried on other standard SDK examples.

  • I tested with the pwmled2 example and do not get the issue.

    The issue due to the fact the restart button sets the program counter to the entry point of the loaded application and doesn't do a device reset. The timer interrupt is still enabled and the timer is still running when the restart is performed because only the program counter was changed and the device wasn't reset.

    When the resume button is pressed and the timer interrupt occurs, in the HwiP_dispatch() function the obj pointer is set to a null value because in the HwiP_dispatchTable array the pointer for the timer interrupt isn't set.

    To avoid this issue the CPU reset button should be used to restart the device.

  • Ok, this makes sense in a way, and on the LP-CC1312-R7 and LAUNCHXL-CC1352R1 boards there is actually a "Board Reset" option that "solves" the issue.
    However, the LPSTK-CC1352R board did not have that option (or, at least, I did not get it, I don't know if it stems from the fact that I was using a SEGGER J-LINK) and it also presented that issue with the "Terminate" option and shutting down the board did not always help. Not to mention that everything worked just fine on it before December 22nd, including the "Restart" option. Furthermore, the program did not always get stuck on HwiP_dispatch during this issue, sometimes it also seemed to work as expected with the exception of interrupts never triggering at all.
    But I think we are on the right track here.

  • However, the LPSTK-CC1352R board did not have that option (or, at least, I did not get it, I don't know if it stems from the fact that I was using a SEGGER J-LINK)

    I believe you need to use the separate J-Link control panel to access some more advanced debug features. Please check the documentation for the ocntrol panel for more details.

    ki