Skip to main content
Piotr Romaniuk
Piotr Romaniuk
Senior
May 12, 2018
Solved

Why I lose communication with BlueNRG-2 via SWD?

  • May 12, 2018
  • 2 replies
  • 1083 views
Posted on May 12, 2018 at 06:46

Hi,

I am able to communicate with BlueNRG-2 either by ST-Link Utility or by Atollic GDB. 

Unfortunatelly, when I start regular work of DTM firmware, these tools lose communication.

What is the reason of that?

Is it caused by going the BlueNRG into sleep mode?

How can I solve this problem?

Having debuger is crucial for bug finding.

Kind regards,

Piotr Romaniuk
    This topic has been closed for replies.
    Best answer by Winfred LU
    Posted on May 14, 2018 at 05:24

    Hi

    Piotr Romaniuk,

    Yes, it is because when BlueNRG-2 entering sleep or standby state, the debug port is not powered.

    There is a workaround for this, as described in datasheet 3.21.1 Debugging tips

    http://www.st.com/resource/en/datasheet/bluenrg-2.pdf

     

    There are certain situations where debug access is disabled and the chip cannot be accessed, including:

    • application that disables debug pins

    • application that set the device in sleep or standby state, in which the debug port is not powered.

    These cases are common during application development and device can end up in a state where debug access

    is no longer possible. To recover this situation, it is recommended to force IO7 pin high and hardware reset the

    device in order to force execution of the updater code (see Section 3.23 Pre-programmed bootloader). The user

    can then connect with SWD interface and erase the device Flash memory.

    Best Regards,

    Winfred

    2 replies

    Tesla DeLorean
    Tesla DeLorean
    Guru
    May 12, 2018
    Posted on May 12, 2018 at 12:13

    If the interface pins turn off or the internal logic shuts down you will lose connectivity. When debugging it might help to set DBGMCU bits, and stop the code from going into some of the low power and sleep modes. The behaviour of WFI can also be defined to turn things off when waiting for the next interrupt.

    There are many ways to debug things, beyond the need to single step everything to see how it works, consider using a USART to output state and telemetry, dump registers, so you can see how the system behaves without a debugger attached (they are often invasive) and how the system traverses power states, resets, etc and how your code flows and interacts with things.

    Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
    Piotr Romaniuk
    Piotr RomaniukAuthor
    Senior
    May 12, 2018
    Posted on May 12, 2018 at 13:52

    I rather expected that Debug Cell of ARM Cortex can be still controlled even if CPU is in WFI state.

    [updated]: See description from Cortex-M0 documentation.

    0690X0000060B9AQAU.png

    Regards,

    Piotr
    Tesla DeLorean
    Tesla DeLorean
    Guru
    May 12, 2018
    Posted on May 12, 2018 at 14:01

    There are situations where it can't and that was the point.

    Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
    Winfred LU
    Winfred LUAnswer
    ST Employee
    May 14, 2018
    Posted on May 14, 2018 at 05:24

    Hi

    Piotr Romaniuk,

    Yes, it is because when BlueNRG-2 entering sleep or standby state, the debug port is not powered.

    There is a workaround for this, as described in datasheet 3.21.1 Debugging tips

    http://www.st.com/resource/en/datasheet/bluenrg-2.pdf

     

    There are certain situations where debug access is disabled and the chip cannot be accessed, including:

    • application that disables debug pins

    • application that set the device in sleep or standby state, in which the debug port is not powered.

    These cases are common during application development and device can end up in a state where debug access

    is no longer possible. To recover this situation, it is recommended to force IO7 pin high and hardware reset the

    device in order to force execution of the updater code (see Section 3.23 Pre-programmed bootloader). The user

    can then connect with SWD interface and erase the device Flash memory.

    Best Regards,

    Winfred

    Terms & ConditionsAccessibility statement