AM335x starterware debug issue

Hi Will,

What optimization settings were the program built with?

Thanks

ki

Hi Ki,

 Not optimizing.

Will - what exact target are you using? And with which emulator?

I'm also assuming 'isIPR' is resolved to be 'true' and also with the if statement on line 367?

Thanks

ki

Hi ki,

what exact target are you using? And with which emulator?

Will-->General Purpose EVM , XDS100v2

 (http://www.ti.com/tool/TMDXEVM3358)

(https://estore.ti.com/TMDSEMU100v2U-14T-XDS100v2-USB-JTAG-Emulator-14-pin-TI-connector-P1844.aspx)

I'm also assuming 'isIPR' is resolved to be 'true' and also with the if statement on line 367?

Will--> Yes.

Thanks~

Thanks Will.

I cannot reproduce this issue. I have tried several times. If I set a breakpoint at line 355, it halts there inside EDMA3CCComplIsr. I have tried both AM3359 SDK and AM3359 EVM via XDS100v2 onboard emulator.

What exactly do you see when you set the breakpoint only at line 355? Does it simply run without ever halting?

Also, what TI Emulators Pack version do you have? You can check via:

Help -> About Code Composer Studio -> Installation Details

Look under the Installed Software tab.

Thanks

ki

Hi ki,

Thanks you for your help.

TI Emulators is 5.1.232.0.

If I only set a breakpoint at line 355, it halts there inside EDMA3CCComplIsr at the first time. 

I continue to click the resume button(F8), and I can't get into EDMA3CCComplIsr.

Thanks.

I can now reproduce the issue. Basically if a breakpoint is set anywhere before line 372, the issue occurs. It is an odd one. I also reproduced it with CCSv6. We are investigating...

ki

Is there any update on this issue?

Thanks.

Will,

Sorry, but Ki is out in vacation and I am unsure if he already has fully characterized this issue. I was only able to take a look at it today and, just like him, I can't seem to make any sense out of the problem. In my case, though, I randomly stop at breakpoints at that specific function irrespective of the line where it is set and the breakpoint type (hardware or software).

Just to confirm if the function call was being executed more than once, I set a small ETB trace job starting and stopping at the function addresses, and I can verify it is accessed multiple times, which confirms the expected behavior.

Just FYI, I set the PC Trace job (menu Tools --> Hardware Trace Analyzer --> PC Trace) as below:

Ki is back next week and I will be able to sync up with him.

I apologize for the inconvenience,

Rafael

will hsu90429 said:

Is there any update on this issue?

Hi Will,

Sorry for the delay in response. I was away for awhile. The latest status is this:

It doesn't appear to be a debug issue. One theory is that because the function in question is an ISR, halting in an ISR can impact the behavior of the system. According to one of the emulation engineers, It could be that the EDMA might have been triggering off or causing an error during a halt inside the ISR prior to clearing the interrupt and disabling the transfer. We don't know too much about the behavior of the EDMA on the device, I am requesting help from the device experts.

ki

Hi Ki

Thanks for your effort.

Will