Why I lose communication with BlueNRG-2 via SWD?

[Piotr Romaniuk]

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

[Tesla DeLorean]

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.

[Piotr Romaniuk]

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.

Regards,

Piotr

[Tesla DeLorean]

Posted on May 12, 2018 at 14:01

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

[Winfred LU · Accepted solution]

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 accessis no longer possible. To recover this situation, it is recommended to force IO7 pin high and hardware reset thedevice in order to force execution of the updater code (see Section 3.23 Pre-programmed bootloader). The usercan then connect with SWD interface and erase the device Flash memory.

Best Regards,

Winfred

[Tesla DeLorean]

Posted on May 14, 2018 at 05:34

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

Ok, but you're physically experiencing it NOT WORKING, these are complicated devices and interact with themselves in ways that a few bullet-points doesn't adequately capture.

You've either got to stop doing certain things so you can debug in the way you want, or you need to change the way you debug to accommodate the behaviour of the device.

Some times the act of observation alters the outcome of a test/experiment.

[Piotr Romaniuk]

Posted on May 14, 2018 at 07:49

Hi Clive,

I hoped that ST-Link device may be a reason.The debugger does not look very professional and has issues while is working.I wanted to be surethat there is or not hardware obstacle.

I needed a debuger for checking processor state, and doing that as non-invasive as is it possible. I thought that connection to processor by debug port would be such method.I just have very mean issue with waking up (

https://community.st.com/0D50X00009Xkht1SAB

). I use extensively other methods of debugging as you mention.

Thank you for your comments.

Regards,

Piotr