TMS320F280049C: Apparent bug in breakpoint execution when run from a DSS script

Hi,

Our expert will get back ASAP.

Thanks,

Saravanan

Hello Thomas,

Thank you for providing the excellent test case. It is always so helpful to work with a customer provided test case.

I tried a few things. I first ran the DSS script as is. Then I ran the script with CCS visibility enabled so I can visually see the debugger actions as the script runs. Then I simply ran the executable from CCS manually.

The behavior across all three instances were consistent.

After program load:

-Target is run

-Breakpoint 3 is reached.

-Target is run

-Breakpoint 5 is reached.

-Program exits.

What different behavior do you see?

Thanks

ki

The test results mentioned in my original post were executed using C2000 compiler version 10.4. Test results from the DSS script console were:

Resuming DSP execution.
[11:06:33.860] Break Point #2 reached! VALID_CASE_1
Resuming DSP execution.
[11:06:33.901] Break Point #3 reached! INVALID_GPIO_INPUTS
Resuming DSP execution.
[11:06:33.950] Break Point #5 reached! TEST_IS_DONE
[11:06:33.968] Test Session Completed!
Session Terminated!

This morning I ran the DSS test example against C2000 compiler version 12. Results were the same as above. 

I thought optimization level may be playing a part. When project optimization level was off, I got the results above. When I changed the optimization level to 0 and ran the test, the test script console shows: 

Restarting Target.
Resuming DSP execution.
[10:57:51.124] Break Point #2 reached! VALID_CASE_1
Resuming DSP execution.
[10:57:51.160] Break Point #1 reached! VALID_CASE_0
Resuming DSP execution.
[10:57:51.208] Break Point #5 reached! TEST_IS_DONE
[10:57:51.228] Test Session Completed!
Session Terminated!

In both cases, the if clauses do not appear to be executing correctly. What can be different between your environment and mine that could cause the different behavior? What optimization level are you using?

These are my results:

Thomas Cox said:

In both cases, the if clauses do not appear to be executing correctly. What can be different between your environment and mine that could cause the different behavior? What optimization level are you using?

Note I am using the executable as provided in the zip. I did not rebuild it at all. Hence it would be the same compiler version and optimization that you used to build the project.

Thanks

ki

I repeated my test with different optimization settings, OFF in one case and 0 in the other for both compiler versions. The results for both compiler version 10.4 and compiler version 22. 22.6 are the same as stated above for both versions of the compiler.

We have not addressed the important question: What can be different between your environment and mine that could cause the different behavior?

Thomas Cox said:

We have not addressed the important question: What can be different between your environment and mine that could cause the different behavior?

We are using the same CCS version (10.4), the same target (F28379D LaunchPad) and (I assume) the same debug connection (on-board XDS100v2).

Since I am not rebuilding the project but simply using the executable that you built, the compiler versions/options do not come into play.

The only other main things to look at is the TI Emulator pack version and C2000 device support package. I doubt these would impact the execution flow but I suppose it is worth looking into.

For me, the version are:

C2000 device support: 6.2.0

TI Emulator pack: 9.4.0.00129

You can find the versions under: 'Help -> About Code Composer Studio -> Installation Details (button) -> Installed Software (first tab)'

ki

Ki - My device support version is 6.1.0. TI Emulator pack version is 9.3.0.00058. How would I go about updating these components?

By the way, I have run the same test using CCS version 12, compiler version 22.6.  In that environment, device support version is 6.8.0.0 and TI Emulator pack version is 9.9.0.00040. Breakpoint behavior using CCS version 12 on the test project I sent you is exactly like my results under CCS version 10.4.

Thomas Cox said:

My device support version is 6.1.0. TI Emulator pack version is 9.3.0.00058. How would I go about updating these components?

See: https://software-dl.ti.com/ccs/esd/documents/users_guide_10.4.0/ccs_updates.html#manually-checking-for-updates

If I get identical, but bad results, using either CCS version 10 or version 12, it looks like the C2000 device support version and TI Emulator pack version are not what is causing the difference in our DSS script execution. What other factor(s) might be able to cause this kind of effect?

I'd like to clarify some things to myself:

1) Regarding my results when I run the test case - are those the expected results that you are unable to reproduce with the same test case?

2) Your original post mentions that when running from the CCS debugger, everything works as expected. Do you mean manually running the steps yourself? Or do you mean running the script from the Scripting Console inside the IDE?

Thanks

ki

Ki - The results you get are the expected correct results if you have not manipulated either of the two GPIO inputs. To get one of the two valid results, one GPIO input must be high, and the other low. If both are high or both are low, the combination is considered invalid. 

My DSS test results appear to indicate that the firmware took an impossible path through the if / else cases. Breakpoints 1 and 2 are at the two out of the 4 possible  results from reading the 2 GPIO inputs that are considered valid. Breakpoint 3 is the default case if neither valid combination is found, i.e. the GPIO inputs are in one of the two possible invalid combinations. Breakpoint 5 signals exit from the if / else structure. Breakpoint 4 was to catch a fatal error, but it is not implemented in the test script I sent you.

The DSS script defines breakpoints at firmware locations marked by an asm("<breakpoint_label>:") statement. When I run the test from the CCS debugger, I define breakpoints at the firmware source code line preceding each asm statement. So the two tests are not exactly equivalent, but they should both hit only one of the 3 possible if / else cases and a test completed breakpoint.. It should never be possible to hit both of the valid cases, or to hit both one of the valid cases and the invalid case. Yet you can see from the script console printouts, both those failures occur repeatedly and consistently in my environment across two different versions of CCS.

That I can change the behavior of the failure by changing optimization level is not too surprising. But regardless of optimization level, if both GPIO inputs are at the default high value due to the internal pull-up, the script SHOULD produce the results you got.

I reviewed the firmware source and realized that I had forgotten to flesh out the GpioInit function. I borrowed the code below from the blinky example program. I think it should be sufficient to make sure the two GPIO pins being used are defined as inputs, and are configured with internal pull-ups.

void GpioInit( void )
{
	// Disable pin locks.
	GPIO_unlockPortConfig(GPIO_PORT_A, 0xFFFFFFFF);
	GPIO_unlockPortConfig(GPIO_PORT_B, 0xFFFFFFFF);
	GPIO_unlockPortConfig(GPIO_PORT_C, 0xFFFFFFFF);
	GPIO_unlockPortConfig(GPIO_PORT_D, 0xFFFFFFFF);
	GPIO_unlockPortConfig(GPIO_PORT_E, 0xFFFFFFFF);
	GPIO_unlockPortConfig(GPIO_PORT_F, 0xFFFFFFFF);

	// Enable GPIO Pullups.
	Device_enableUnbondedGPIOPullups();
}

After this change to the source file GpioInitCheck.c , there was no change in my results when running the DSS script.

Glad to hear you were able to find the root cause of the issue and thanks for the update!

Thomas Cox said:

Can a compiler expert at TI take a look at these test results, and see if DSS use of asm text labels as breakpoint markers can be corrected in situations where the asm statement is the last source code line in an if / else case?

Can you create a new thread for this (you can reference this thread for context in the new thread)? It will be easier more me to escalate to our compiler expert this way.

Thanks

ki

I'll to that. Thanks.

Ki - the new post is up. The title is Apparent bug in firmware if/else execution using asm breakpoint labels from a DSS script.

Thanks. I have brought the thread to the attention of our complier expert.