Skip to main content
Richard Peters
Richard Peters
Associate II
June 6, 2018
Question

Dectecting the presence of a debugger on STM32F767 does not work

  • June 6, 2018
  • 5 replies
  • 1490 views
Posted on June 06, 2018 at 10:00

Hello all!

I'm trying to detect whether a debugger is attached to my program. I've read in other threads (like this one: 

https://community.st.com/thread/25890?commentID=69875&sharpcomment

  ) that there is a register in the SCB named DHCSR (Debug Halt Control and Status Register) which is used by debuggers who set bit 0 when they attach. 

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/CEGCJAHJ.html

  gives more details about this register.

However, when I read out that register on my Nucleo-F767ZI board, bit 0 is always set to 1. Of course it should be 1 when I launch my program from System Workbench, but when I disconnect the debugger and reset the microcontroller, bit 1 is still set. The contents of DHCSR is different when debugging or not debugging (when debugging, it is 0x1000d, when not debugging, it is 0x1010001), but I expected the least significant bit to be 0 when not debugging.

I use this code to read out DHCSR:

volatile unsigned int* const SCB_DHCSR = (volatile unsigned int *)0xE000EDF0;

if (*SCB_DHCSR & 1)

    ...

Am I doing something wrong? Is this a peculiarity with the STM32F767?

null
    This topic has been closed for replies.

    5 replies

    Tesla DeLorean
    Tesla DeLorean
    Guru
    June 6, 2018
    Posted on June 06, 2018 at 13:37

    On the CM7 you usually have to unlock access to ITM and DWT registers

    Equivalent code to this for assorted LAR in debug peripherals

    volatile unsigned int *DWT_LAR      = (volatile unsigned int *)0xE0001FB0; //address of the register

    *DWT_LAR = 0xC5ACCE55; // unlock

    Might dig into this later.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Richard Peters
    Richard PetersAuthor
    Associate II
    June 6, 2018
    Posted on June 06, 2018 at 13:59

    Thanks for the quick response! I gave it a try, but unfortunately even with the st-link disconnected I get a read out of 0x1010001, indicating that it thinks a debugger is attached.

    Tesla DeLorean
    Tesla DeLorean
    Guru
    June 6, 2018
    Posted on June 06, 2018 at 14:11

    Are you pulling the ST-LINK jumpers in the test case? I might expect the mbed firmware to probe the device

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Richard Peters
    Richard PetersAuthor
    Associate II
    June 6, 2018
    Posted on June 06, 2018 at 14:46

    Yes, I've removed the two jumpers connecting the SWD lines from ST-LINK to the STM32F767. By the way, I've upgraded the ST-LINK device with the J-LINK software, but since I've removed the jumpers that shouldn't matter.

    Richard Peters
    Richard PetersAuthor
    Associate II
    June 12, 2018
    Posted on June 12, 2018 at 07:49

    I've figured out what was going on: Although the debugger sets that specific bit in SCB_DHCSR, it is never reset to 0, not even by a hard reset. When power is removed though, the bit is reset. With this behaviour, the bit indicates whether a debugger /is/ attached /or has been/ attached since the last power up. Well, works good enough for my purpose.

    Terms & ConditionsAccessibility statement