Fix for breakpoints on F7

[daveatpanic]

I had to make a couple of tweaks to get breakpoints working on the F7 (custom board with an STM32F746). I can't find anything in the Cortex-M7 docs about the type flags disappearing from the F_COMP register, but it only works if I remove it. (I found this in a patch submitted to OpenOCD.) I figured I'd let someone with more experience with the st-util code add the checking for cpu type and all that..

*** stlink-master/gdbserver/gdb-server.c    2015-09-03 01:45:36.000000000 -0700
--- stlink-master-f7/gdbserver/gdb-server.c 2015-09-03 15:28:12.000000000 -0700
*************** static int delete_data_watchpoint(stlink
*** 542,549 ****
      return -1;
  }

! #define CODE_BREAK_NUM    6
! #define CODE_LIT_NUM  2
  #define CODE_BREAK_LOW    0x01
  #define CODE_BREAK_HIGH   0x02

--- 542,549 ----
      return -1;
  }

! #define CODE_BREAK_NUM    8
! #define CODE_LIT_NUM  0
  #define CODE_BREAK_LOW    0x01
  #define CODE_BREAK_HIGH   0x02

*************** static int update_code_breakpoint(stlink
*** 607,613 ****

          stlink_write_debug32(sl, 0xe0002008 + id * 4, 0);
      } else {
!         uint32_t mask = (brk->addr) | 1 | (brk->type << 30);

          DLOG("setting hw break %d at %08x (%d)\n",
                      id, brk->addr, brk->type);
--- 607,613 ----

          stlink_write_debug32(sl, 0xe0002008 + id * 4, 0);
      } else {
!         uint32_t mask = (brk->addr) | 1;

          DLOG("setting hw break %d at %08x (%d)\n",
                      id, brk->addr, brk->type);

[mlu]

The number of code breakpoint comparators and the number of literal comparators can/should? be read from the FP_CTRL register.
The REMAP register and functionality is not implemented for M7, and there are no literal comparators, so its reasonable to assume that the REPLACE bits 30.31 in FP_COMP registers have changed behaviour. That information is unfortunately not freely available from ARM for us mortals.

[mlu]

In RM0385, reference manual for STM32F74xx, section 40.12 it says:
"Programmer’s model for breakpoint comparators is enhanced to allow hardware
breakpoint in full address range." This should indicate that bits 30.31 really are used for breakpoint address and not for breakpoint type. So the logic of the patch is sound and it should be integrated in the code in the right place for M7 cores. Perhaps I have time to do that the coming weekend.

[daveatpanic]

For the record, I'm seeing a bit of weirdness with this "fix": on some breakpoints, it stops on the instruction before the breakpoint address, which means gdb can't continue until the breakpoint is deleted. I haven't had any time to look into this yet, just noting it here in case someone else is seeing the same thing. (Or knows off-hand what the issue might be.)

[mlu]

Can you check if the addresses where the halt is before the intended bp are halfword or word aligned?

The old brk->type field in the FP_COMP register (bits 30:31) could be used to select address match against upper or lower halfword of the always 4 byte aligned address, since bits 0:1 were not used. Now this has been removed so perhaps the FP_COMP register uses halfword aligned addresses. In that case only the first bit of the address should be masked, not the first two bits as is done now.

[daveatpanic]

I couldn't reproduce the breakpoint issue, had no problem stopping at both word-aligned and halfword-aligned addresses on the latest build of my board. Hardware problem, I guess? Who knows..

[daveatpanic]

Oh, ha. I missed the bit at the beginning of update_code_breakpoint() that was clearing the two low bits. I changed that to

stm32_addr_t fpb_addr = addr;
int type = CODE_BREAK_LOW;

and it works much better now. :)

[mlu]

I have created a pull request for M7 breakpoint handling, please test on M7 but also on other targets.

[xor-gate]

As all the code has been merged into master, this problem should not exist anymore. But feel free to open a new issue if still something is remaining. Thanks for all the effort.

[Nightwalker-87]

Fixed with #341.