Keil 5.16a - STM32F103C8 debugging issue (cannot connect the target)

Bogdan Golab · ‎2015-10-28

Posted on October 28, 2015 at 23:17

Hi,

I've being using Keil for a few years. I have no issues with debugging when Standard Peripheral Library is used on the same core and same st-link device.

===

I wanted to play with Cubex and HAL and noticed that as long has HAL_init() is used I am experiencing ST-link issues when I want to debug the app. I get 'Cannot connect to the target' error. The ST-Link firmware is up-to-date. There is no problem when SPL is used for the same purpose.

The application is very simple - just blinking (I wanted to start using the HAL drivers).

Does anyone have similar issues?

Thanks,

Bogdan

Bogdan Golab · ‎2015-11-05

Posted on November 05, 2015 at 17:12

I finally SOLVED the problem. The SWD is disabled by default by STM32Cube generated code.

The code upload was working fine but after starting the code the SWD was disabled immediately as a result of HAL_MspInit() function, and further communication with the MCU was prevented.

There was:

__HAL_AFIO_REMAP_SWJ_DISABLE();

To fix the issue we need to have:

__HAL_AFIO_REMAP_SWJ_NOJTAG();

The right code is generated once you enable debugging (part of SYS settings) in STM32Cube.

View solution in original post

Tesla DeLorean · ‎2015-10-28

Posted on October 29, 2015 at 00:56

Does your target have NRST connected?

Does selecting the ''connect under reset'' debugger option permit connection?

Pulling up BOOT0?

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

Bogdan Golab · ‎2015-10-29

Posted on October 29, 2015 at 09:20

nRST is pulled-up by 10kohm + 100nF to the ground.

In this case ''Connect under reset'' does not help (I used this solution for STM32F100 Discovery board and in this case it worked).

I tried to pull up the boot0 a few times but it did not help.

===

Again, what is strange for me:

Simple blinking app can be uploaded (can connect the target) when SPL is used BUT fails when HAL_init() is used (app skeleton generated by CubeMX).

It's something about timing (when I played with ST-link speed it took much longer to fail at lower rate). So something happens during the binary downloading to the target, I guess.

===================

Another comment:

when I played with F100 Discovery, I used to have such problems from time to time. In this case flash erase helped & playing with reset button during st-link connection process.

It seems that the current device state (in terms of what was programmed) may impact the st-link programming process. Not sure what are the critical 'components' i.e. what programmed feature affects the st-link.

Does someone know how the current application on the device can affect the st-link programming process? What are the 'fragile' components we should avoid?

Bogdan Golab · ‎2015-10-29

Posted on October 29, 2015 at 12:43

@clive1

I have noticed that you know a lot about st-link related issues (just browsing the ST Forum). Maybe it would be useful and could save your time having st-link faq document.

If you could summarize:

1. all st-link related issues & solutions you know with short explanation why particular solution works

2. well known problems related to app functionality which may impact st-link connectivity (e.g. LP modes, SWI pin reprogramming, etc). I think I had some cases where the app worked fine BUT I needed to erase the flash (using boot0 and/or 'connect under reset' tricks) to have st-link connectivity.

Thanks in advance,

Bogdan

Tesla DeLorean · ‎2015-10-29

Posted on October 29, 2015 at 14:22

I could, but my observation is people just don't bother reading anything these days, and immediately ask their question again anyway. Working the forum is like ''

http://www.imdb.com/title/tt0107048/

''

The question about NRST was related to if it was connect to the debug interface, or not. If it isn't the pod can't reset the device into a known/fixed state.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

Bogdan Golab · ‎2015-10-29

Posted on October 29, 2015 at 15:14

No, the NRST is not connected to the debug interface.

Not sure why the ST does not care about educating people about ST-Link. It always frustrates me - I do not know when it fails. I cannot judge what is my fault (weirdly behavied app using features that ST-link does not like) or poor st-link design.

ST should publish:

1. how the st-link shall be used (when the target should be reset, when to erase the flash, etc)

2. what features to avoid or how to mitigate their impact on the st-link

Can we just collect those cases and establish simple decision tree?

OR

We cannot do it because the st-link is unpredictable?

===

I like STM32 MCUs very much but I hate st-link.

This case is also strange.

Same flash content for both attempts to load the image to the target but it fails when the hal based app is going to be loaded. The SPL app can be loaded w/o any issue.

I said 'loaded' because I wanted to put the binary to the SRAM (I usually do not flash the device when small apps can be fitted into the SRAM).

Bogdan Golab · ‎2015-10-29

Posted on October 29, 2015 at 15:18

I used to use SRAM for debugging purpose for years - so I believe that I know what I do (Targets setting for linker, RAM.ini for debugger, VTOC settings, etc).

When I removed HAL_init() all works fine when it comes to uploading the app and stopping the debugger within SRAM area. Just to confirm that all the stuff related to loading code to SRMA is fine.

Tesla DeLorean · ‎2015-10-29

Posted on October 29, 2015 at 17:56

The ST-LINK is a very cheap solution, it's provided as an alternative for people who won't buy the Segger J-Link devices for several hundred dollars. As such it's not a ''commercial'' solution, with the robustness that would imply.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

Bogdan Golab · ‎2015-10-29

Posted on October 29, 2015 at 19:10

Unfortunately STM32 is my hobby (I graduated in electronics but working in different field) so I cannot afford professional tools:(

Bogdan Golab · ‎2015-10-29

Posted on October 29, 2015 at 20:52

I followed your advice and connected the st-link RESET pin to the target RESET (frankly speaking I used to use Discovery/Nucleo boards earlier and did not care about SWD pins; now I use separate STM32 board and cheap st-link v2 tool) and it seems that the binary file is loaded to the target SRAM and the application is working in the SRAM as expected. HAL_init() is used.

Only debugging does not work (I get: ''Cannot access target. Shutting down debug session''). So it seems that for some reason st-link loose the connectivity with the target after downloading and starting the code.

So I guess the code generated by the CubexMX affects somehow SWD connectivity.