Skip to main content
Bogdan Golab
Lead
October 28, 2015
Solved

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

  • October 28, 2015
  • 12 replies
  • 4660 views
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
    This topic has been closed for replies.
    Best answer by Bogdan Golab
    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.

    12 replies

    Bogdan Golab
    Lead
    October 29, 2015
    Posted on October 29, 2015 at 21:19

    I disconnected the reset pin from st-link  - and the result is the same (I had not noticed that the app worked - only debugging was affected since the original description of the problem). In other words - the RESET pin does not affects the st-link behaviour.

    So the problem can be narrowed down to the following: cannot debug in SRAM even though that the app is successfully loaded to the SRAM. SPL based app is not affected. HAL based app (skeleton generated by the CubexMX) is affected.

    I know, I know that the case is very special - who may want to run the code in SRAM, not speaking about debugging the code in SRAM? I am weird person, I know.

    Bogdan Golab
    Bogdan GolabAuthorBest answer
    Lead
    November 5, 2015
    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.