CCS/CC1352R: Software breakpoints are not set with XDS110 probe

Hello Erwin,

Erwin Ahlers said:

I understood that a breakpoint I set as "breakpoint" in the breakpoint menu would be translated into a software breakpoint. Only the menu item "Hardware Breakpoint" would set a HW breakpoint.

This is not necessarily true. The "Breakpoint" option will use the default setting. The default is to check the debugger memory map to see if the memory address is configured to be writable. If it is, it will use a software breakpoint. If it is not, it will use a hardware breakpoint instead.

Please check what your debugger memory map is configured to.

Erwin Ahlers said:

What I even also don't understand ist the fact that three devices are shown under debug configuration

You can ignore the first two in this case. IcePick is a JTAG route connector, and while the DAP is useful for real-time memory access, CCS will automatically use it under the hood when making debug memory accesses. You are correct that the Cortex-M4 is the main CPU that you want debug access to.

Thanks

ki

Hi John,

that makes sense. As a consequence as long as we run our code only out of the internal flash of CC1352 there is no way to use software breakpoints. As a consequence I can never have more than about 4 breakpoints active at the same time. Or can I have more when I use a different debug probe than the XDS110?

Regards
Erwin

I found the memory map and it proofs that all the flash memory is read only.

In the memory map I found some areas marked as read/write that I can't found in my CC1352 data sheet. Can you tell me what's behind these areas?

0x2100C000 to 0x2100C7FF
0xE000E000 to 0xE000EFFF
0xE00FE000 to 0xE00FEFFF

Following areas are even marked as read only where I don't know what's behind.

0x50001000 to 0x50001FFF
0x50002000 to 0x500027FF
0x50003000 to 0x50004FFF

Regards
Erwin

Erwin Ahlers said:

Or can I have more when I use a different debug probe than the XDS110?

The available number of hardware breakpoints is determined by the device, not the debug probe.

Thanks

ki

Erwin Ahlers said:

In the memory map I found some areas marked as read/write that I can't found in my CC1352 data sheet. Can you tell me what's behind these areas?

0x2100C000 to 0x2100C7FF
0xE000E000 to 0xE000EFFF
0xE00FE000 to 0xE00FEFFF

Following areas are even marked as read only where I don't know what's behind.

0x50001000 to 0x50001FFF
0x50002000 to 0x500027FF
0x50003000 to 0x50004FFF

From the startup GEL file used to cc13x2, I see:

GEL_MapAddStr(0x00000000, 0, 0x00058000, "R", 0); /* Flash */
GEL_MapAddStr(0x10000000, 0, 0x00040000, "R", 0); /* ROM */
GEL_MapAddStr(0x11000000, 0, 0x00002000, "R|W", 0); /* GPRAM */
GEL_MapAddStr(0x20000000, 0, 0x00014000, "R|W", 0); /* SRAM */
GEL_MapAddStr(0x21000000, 0, 0x00001000, "R|W", 0); /* RFC_SRAM */
GEL_MapAddStr(0x21004000, 0, 0x00004000, "R|W", 0); /* RFC_ULL */
GEL_MapAddStr(0x21008000, 0, 0x00000800, "R|W", 0); /* MDM_RAM */
GEL_MapAddStr(0x2100C000, 0, 0x00000800, "R|W", 0); /* RFE_RAM */
GEL_MapAddStr(0x40000000, 0, 0x000E1028, "R|W", 0); /* Peripherals */
GEL_MapAddStr(0x40031000, 0, 0x00001000, "NONE", 0); /* Protected */
GEL_MapAddStr(0x50001000, 0, 0x00000800, "R", 0); /* FCFG1 */
GEL_MapAddStr(0x50002000, 0, 0x00000800, "R", 0); /* FCFG2 */
GEL_MapAddStr(0x50003000, 0, 0x00002000, "R", 0); /* CCFG */
GEL_MapAddStr(0xE0000000, 0, 0x00003000, "R|W", 0); /* CPU_ITM, CPU_DWT, CPU_FPB */
GEL_MapAddStr(0xE000E000, 0, 0x00001000, "R|W", 0); /* CPU_SCS */
GEL_MapAddStr(0xE0040000, 0, 0x00001000, "R|W", 0); /* CPU_TPIU */
GEL_MapAddStr(0xE00FE000, 0, 0x00001000, "R|W", 0); /* CPU_TIPROP */

What some of those comments mean, I am not sure as I am not that familiar with the device. You may be more familiar with them. 

Hope this helps

ki

This indirectly answered my question. I can never have moren than the provided numbe of HW breakpoints.

This is a big drawback for firmware development. To get rid of this limitation I have to attach additional RAM to the HW from where the code is then running, right?

Yes it helps.

Thanks for the general answer. We had the hope to get better debugging support with different debugging equipment. But now we have to live with this limited amount of breakpoints.