CCS/TMS320F28379D: Breakpoints Don't Work in Unlocked Processor

Hi Ed,

Ed Sanders said:

But when I try to set a breakpoint, CCS says, with the Console Output below, that it can’t do it. But it appears to do it anyhow because the icon on the line where I tried to set it is there and not greyed out.

Ed Sanders said:

C28xx_CPU1: Trouble Setting Breakpoint with the Action "Remain Halted" at 0x84381: (Error -1066 @ 0x84381) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 8.2.0.00004)

C28xx_CPU1: Breakpoint Manager: Retrying with a AET breakpoint 

What happened here is that CCS first tried to set a software breakpoint at address 0x84381. It failed because (I assume) that address is in Flash. So the debugger then tried a hardware breakpoint and that was successful. I assume that the debugger memory map is not set (default startup gel file is not being used), otherwise the debugger would not have tried with a software breakpoint first.

So far nothing wrong here.

Ed Sanders said:

However, when the code executes and goes through that routine, the breakpoint does not trigger. I know that the breakpoint should have been hit because it is on the very first assembly instruction in that routine, and after putting some debug code in the routine, I can see that it was run. Is there something else I need to do to make the breakpoints work after unlocking?

First check to see if "Skip all Breakpoints" option is enabled:

https://e2e.ti.com/support/tools/ccs/f/81/p/962924/3557794#3557794

If not, are you trying to set the breakpoint while the target is running? If so, you may be running into this known issue in 28x devices:

https://sir.ext.ti.com/jira/browse/EXT_EP-9781

Thanks

ki

Hi Ki,

Ki

So far nothing wrong here.

You are right that the debugger memory map is not set. The only gel file I am using is one which will unlock the device – nothing more. If I’m reading our normal gel file correctly, F28379D_Memory_Map is the routine which sets the memory map. It is called from OnTargetConnect. The intent of this setup is to attach without disturbing anything and unlock the processor. That seems to be working well. Am I correct in thinking that it won’t change the basic behavior of not affecting the system if I add a call to FWU379D_Memory_Map at OnTargetConnect?

Memory Mapping Page

Good info. Is this part of the information which will be going away at the end of the month?

Ki

First check to see if "Skip all Breakpoints" option is enabled

I checked and the “Skip all Breakpoints” option is off.

Ki

If not, are you trying to set the breakpoint while the target is running? If so, you may be running into this known issue in 28x devices

I am not trying to set any breakpoints when the target is running. In fact, to set the breakpoint, I needed to stop the target because I was setting it from the disassembly window.

 Good info in the link. Thank you.

 Ed

Ed Sanders said:

Am I correct in thinking that it won’t change the basic behavior of not affecting the system if I add a call to FWU379D_Memory_Map at OnTargetConnect?

Setting up the debugger memory map is not essential. But if you want to do it, I would add it to StartUp(). Since setting up the debugger memory map does not access the target, it should be fine.

Ed Sanders said:

Good info. Is this part of the information which will be going away at the end of the month?

No. Only information on https://processors.wiki.ti.com/ will go away. 

Ed Sanders said:

I checked and the “Skip all Breakpoints” option is off.

Ed Sanders said:

I am not trying to set any breakpoints when the target is running.

Hmm. Those are usually the key factors in breakpoints not triggering. 

I'm not sure what else could cause the breakpoint to not trigger. Could you try breakpoints in another function (that gets executed) and see if any of those will trigger?

Can you also set your breakpoint and then run the command in the link below to get a list of all the breakpoints set?

https://e2e.ti.com/support/tools/ccs/f/81/p/628691/2325434#2325434

Ki

I would add it to StartUp().

I did, and it seems to be working when I attach without affecting the system. Thank you.

Ki

Can you also set your breakpoint and then run the command in the link below to get a list of all the breakpoints set?

Unfortunately, I needed to give up the hardware which was duplicating the issue. I’ve tried to replicate this on a completely different setup – same processor. And now I can’t duplicate it. That being said, I did notice from another article you sent me that ANASTOP is 1 at the breakpoint, and 0 when I simply let it run. I tried the scripting console suggestion from the link, and I can see the returned information. When I set a breakpoint, I can see information about that breakpoint in the output. I will keep this until I can duplicate the issue again.

Thank you again for all your help Ki,

Ed

Ok, keep me posted if you see the issue again on your original setup

ki