CC1352R: Code works only when debugger is connected

Erwin Ahlers

Part Number: CC1352R

Hi,

I have (again) the issue that the code works only when connected with the debugger. Looking in the forum this seems to happen no too seldom. Unfortunately also very seldom with a good answer.

I read something about HW issues with the debugger connection. But can that be? I have even no idea. what's the difference from processor point of view running code from internal flash with and without connected debugger.

Here is my actual problem:

I use a HW timer to get some timing information. The value is read by HWREG(GPT0_NONBUF_BASE + GPT_O_TAR);
Now I have a wait function that waits for some ticks:

#pragma FUNCTION_OPTIONS("--opt_level=0")
void Tbl_Hw::waitTicks(uint32_t nTicks)
{
    uint32_t startValue = HWREG(GPT0_NONBUF_BASE + GPT_O_TAR);
    uint32_t actValue;
    do
    {
        actValue = HWREG(GPT0_NONBUF_BASE + GPT_O_TAR);
    }
    while ((actValue-startValue) < nTicks);
}

And I have a signal function that uses my LED

void Tbl_Hw::SignalPoint(int nSignals)
{
    switchRedOff();
    //switchGreenOn();
    wait_ms(300);
    while (nSignals > 0)
    {
        nSignals--;
        switchBlueOn();
        wait_ms(200);
        switchBlueOff();
        wait_ms(200);
    }
    wait_ms(700);
}

This SignalPoint function is then called in the destructor of a temporary instance of a class. When I run this program then with a connected debugger I see the blue LED lighting. But when the debugger is disconnected, the LED stays dark.

I thought about some optimization, that my wait loop is removed from the compiler. Therefore I inserted the function options pragma. But that seems not to make a difference. Even when I run it with debugger, the debugger downloads the program to the target and executes it. Disconnecting the debugger and performing a power cycle starts then the same program, still located in intern flash. So that can also not be the root cause.

Any idea what I could do to get it also running when the debugger is not connected?

Greetings
Erwin

over 5 years ago

0 TER over 5 years ago

TI__Guru**** 317180 points

The chip is not able to go down to standby when the debugger is connected. Hence if your board for some reason has a setup that cause problems in standby this could cause the program to run when the debugger is connected and not otherwise.

- Do you have a 32 kHz xtal on your board

- Which LF clock source have you setup to be used?

0 Erwin Ahlers over 5 years ago in reply to TER

Intellectual 570 points

To make it clear, my functionality is:

void A::foo(void)
{
   TB B;    //Create an instance of object B
   B.doSomething()
}

void A::foo2(void)
{
   foo();
   //At the end of foo the destructor of B is called.
   //In this destructor the blue LED is switched on for some time

   doSomethingElse();  //In doSomethingElse the red LED is switched on
}

So normally I see first the blue LED and then the red LED, which is the case when the debugger is connected.

Without debugger I see only the red LED. That means the processor doesn't go to sleep or also doesn't crash. It simply works except the signalling of the destructor. So I'm not sure whether the destructor is called at all, even it should. To proof this I should connect an oscilloscope to the blue LED pin. If the timing in the destructor gets crasy without debugger and a on time of 200mSec is now 20µSec this should be visible in the osczilloscope. But my eyes would not see the blue. But connecting the oscilloscope is not so easy.

Erwin

0 TER over 5 years ago in reply to Erwin Ahlers

TI__Guru**** 317180 points

That does not answer any of my questions. I need to know the HW you are running code on and how you have set up the LF clock sources.

In addition, why are you reading registers directly and not using the driver?

0 Erwin Ahlers over 5 years ago in reply to TER

Intellectual 570 points

Sorry.

The HW is our customer design with CC1352R Processor. There is a 32kHz and a 48MHz crystal connected. So LF is driven from this 32kHz crystal.

The functionality is part of my customized bootloader and runs directly in the resetISR function even bevore the jump to _c_int00. As this bootloader should also work, when all of the remaining flash pages are erased most of the driver functions cannot be used. I use only direkt register access or rom functions. The SetupTrimDevice function I call at the beginning of my bootloader handling is also a copy from the SDK sources except that the rom functions are called directly. The normal driver/SDK functions do first some assert check which is implemented in the flash before calling rom functions. So with empty flash this part is not existing and therefore they are not working.

My interpretation from what I see by observing the LEDs is that the function of B (see my code above) is called, the code doesn't stop as the final signalling after B was done, but the signalling in the destructor of B is only visible when it runs with debugger.

Hope that helps in understanding

Erwin

0 Elin W over 5 years ago in reply to Erwin Ahlers

TI__Genius 14845 points

Hi Erwin,

Which version of the SDK are you using and which example have you based your application on?

Are you using a separate BIM? On-chip or off-chip?

Thanks,
Elin

Sub-1 GHz

Sub-1 GHz forum

CC1352R: Code works only when debugger is connected