1

I am developping a new project for STM32 on Keil MDK 5.28, using ARM compiler V6 (the "new" armclang compiler). It's the first time I'm using armclang.

My reset handler is calling the __main symbol. As expected, this is executing some startup code of the Keil C library and then is calling my main function (later on, I will remove the calls to the startup code but right now I want to understand the issue).

The problem is the following: there is a BKPT instruction inside one of the C library function (_sys_open). I didn't set this breakpoint and it doesn't appear in the breakpoint list. I cannot remove it (tried obviously to rebuild everything). So I cannot start a debug session without breaking at this location.

I also tried to uncheck the option "Run to Main".

enter image description here

Do you know where this BKPT instruction comes from and how to remove it ?

Guillaume Petitjean
  • 2,408
  • 1
  • 21
  • 47
  • Try turning off semi hosting if it is on. I am working with armclang at the moment (porting from armv5 compiler). Its a pain in the backside. – Realtime Rik Feb 27 '20 at 10:14
  • The breakpoint (`BKPT`) is probably part of some error handler. Find out the corresponding C source line and see what went wrong. Calling `_sys_open` is suspicious anyways... – Erlkoenig Feb 27 '20 at 12:00
  • Not sure whether that works with µVision/Clang, but with GNU toolchains you could do `addr2line -e YourProgram.elf 0x8000A68` do find the source location of the `BKPT` provided the ELF file contains debugging information. – Erlkoenig Feb 27 '20 at 12:18
  • According to the map file the instruction is in this function. See screen capture. – Guillaume Petitjean Feb 27 '20 at 12:18
  • Yes, but not _where_ in that function. There might be something like`if (some error condition) __asm__ volatile ("BKPT");` in there. You need to find that condition... However, since the `BKPT` appears to be unconditional, it might actually be semihosting-related as Rik said. – Erlkoenig Feb 27 '20 at 12:19
  • @Erlkoenig BKPT how can it be semihosting related. It breaks always and if the debug hardware is disabled it invokes HF. Pointless to have it in the not currently debugged code. It they left it in the production libraries - it only confirms my opinion about Keil and ARM compiler toolchain :) – 0___________ Feb 27 '20 at 12:27
  • Semihosting is of course supposed to _only_ work with debugger attached, as it is (kind of) a debugging/testing feature. When configured correctly, the debugging software on the PC reacts to the breakpoint, accesses PC resources and places the result in µC memory. It would be _your_ fault for compiling/linking with semihosting-enabled C libraries, or not having it enabled in the debugger configuration. – Erlkoenig Feb 27 '20 at 12:32
  • @Erlkoenig, apparently you're right, I've found this note in ARM documentation: "Note ARM processors prior to ARMv7 use the SVC instructions, formerly known as SWI instructions, to make semihosting calls. However, if you are compiling for an ARMv6-M or ARMv7-M, for example a Cortex-M1 or Cortex-M3 processor, semihosting is implemented using the BKPT instruction." – Guillaume Petitjean Feb 27 '20 at 12:44
  • So it looks semihosting is configured by default ? Do you know how to disable it ? – Guillaume Petitjean Feb 27 '20 at 12:44
  • Try [this](http://www.keil.com/support/docs/3614.htm) or [this](http://www.keil.com/support/man/docs/armlib/armlib_chr1358938917495.htm) to disable semihosting. – Erlkoenig Feb 27 '20 at 12:48
  • @Erlkoenig amazing ! Just enabling microlib fixed the issue. It seems like microlib does not use semihosting. I suggest you add an answer to my post. – Guillaume Petitjean Feb 27 '20 at 12:52

1 Answers1

2

Summary of the comments: The breakpoint instruction BKPT is part of the semihosting feature, which is supposed to cooperate with the debugger. Enabling Microlib disables semihosting; see here and here.

Erlkoenig
  • 2,664
  • 1
  • 9
  • 18