SWD/JTAG disabled by the flashing?

[mrdROb]

Solution

[env:genericSTM32F103C8]
platform = ststm32
board = genericSTM32F103C8
framework = arduino
upload_protocol = stlink
build_flags = -DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG=1

---

Just installed Atom+PlatformIO, configured my first arduino project with following settings: [env:genericSTM32F103C8] platform = ststm32 board = genericSTM32F103C8 framework = arduino upload_protocol = stlink

The code is simple Blink example. Successfully uploaded the code, but after that I am not able to connect to STM32. It says: st-flash 1.3.1 2017-08-03T17:33:39 INFO src\common.c: Loading device parameters.... 2017-08-03T17:33:39 WARN src\common.c: unknown chip id! 0xa05f0000 *** [upload] Error -1

St-link GUI is not able to connect also. When I hit Reset on the board, I am able to connect via ST-LINK GUI, and able to clear the FLASH. After that I can use PlatformIO once again, and after that it locks chip communication again. When I manually flash the same .bin - the same happens again - chip locks. So there is something inside the .bin file, blocking the communication. I found some explanation where the guy does not use Platformio, but says he found out CMSIS/HAL initialization blocks SWD communication. I feel like this is probably my case. But how to fix this?

P.S. I also tried the same Blink example through standard Arduino - and it flashes as many times as needed without blocking.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/47900101-swd-jtag-disabled-by-the-flashing?utm_campaign=plugin&utm_content=tracker%2F38219470&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F38219470&utm_medium=issues&utm_source=github).

[ubis]

Can you add the following line into your platformio.ini file and report back with the results: build_flags = -DVECT_TAB_ADDR=0x8000000 -DSERIAL_USB -DGENERIC_BOOTLOADER

Also it would be good if you could provide me your build log(without these additional build flags) with pio run -v in pastebin.

[mrdROb]

Here is the paste from "pio run -v" before applying the fix - https://pastebin.com/cTcQXzF4 And after - https://pastebin.com/rdLfq7ej

Solution did not fix the problem

[mrdROb]

P.S. Not sure if it worth mentioning, but if I hold Reset button while flashing, I get other error: st-flash 1.3.1 2017-08-04T18:01:22 INFO src\common.c: Loading device parameters.... 2017-08-04T18:01:22 INFO src\common.c: Device connected is: F1 Medium-density device, id 0x20036410 2017-08-04T18:01:22 INFO src\common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0 bytes (0 KiB) in pages of 1024 bytes Unknown memory region *** [upload] Error -1 [ERROR] Took 1.65 seconds

[ubis]

I've looked over build flags and the only difference was that there are a few libraries used which shouldn't. Please keep these build_flags and add build_unflags, so your platformio.ini would look like this:

[env:genericSTM32F103C8]
platform = ststm32
board = genericSTM32F103C8
framework = arduino
upload_protocol = stlink
build_flags = -DSERIAL_USB -DGENERIC_BOOTLOADER
build_unflags = -lc -lstdc++ -lnosys

Still, there is one additional c lib left in linker flags, which is set in stm32duino platform file.

@ivankravets Any chance to remove it within build_unflags? I remember we had to use double -lc because with one it couldn't compile. Now it seems like it's fine. Also Arduino environment doesn't even use this flag at all, so it should be removed.

[mrdROb]

Used these options, with no success. The device still locks after single firmware upload.

[cxubrix]

Hi, this looks like relates to https://github.com/platformio/platformio-core/issues/1078 maybe there is some useful info in logs e.g. why st-link version changes for second upload. Not sure if I need to create a new issue, might be a duplicate

[ivankravets]

@cxubrix we have updated st-link package today. Could you try pio update and upload again?

[cxubrix]

@ivankravets had the same error with latest st-link package.

[ubis]

That version change is indeed wierd. However, I think this is related to build flags, rather than st-link itself. As far as I can see, this happens only on F103C8 + Arduino + ST-Link. In order to verify it, @cxubrix could try to use different framework(mbed for example) and flash it with st-link.

[cxubrix]

@ubis Just tried mbed framework and it flashes fine every time, but since genericSTM32F103C8 did not support mbed freameform on pio, I used configuration below.

[env:nucleo_f103rb]
platform = ststm32
board = nucleo_f103rb
framework = mbed
upload_protocol = stlink

log:

[09/25/17 21:10:11] Processing nucleo_f103rb (upload_protocol: stlink; platform: ststm32; board: nucleo_f103rb; framework: mbed)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
Collected 22 compatible libraries
Looking for dependencies...
No dependencies
Uploading .pioenvs\nucleo_f103rb\firmware.bin
st-flash 1.3.1
Flash page at addr: 0x08002c00 erased
 11/11 pages written2
017-09-25T21:10:15 INFO src\common.c: Loading device parameters....
2017-09-25T21:10:15 INFO src\common.c: Device connected is: F1 Medium-density device, id 0x20036410
2017-09-25T21:10:15 INFO src\common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2017-09-25T21:10:15 INFO src\common.c: Attempting to write 11900 (0x2e7c) bytes to stm32 address: 134217728 (0x8000000)
2017-09-25T21:10:16 INFO src\common.c: Finished erasing 12 pages of 1024 (0x400) bytes
2017-09-25T21:10:16 INFO src\common.c: Starting Flash write for VL/F0/F3 core id
2017-09-25T21:10:16 INFO src\flash_loader.c: Successfully loaded flash loader in sram
2017-09-25T21:10:16 INFO src\common.c: Starting verification of write complete
2017-09-25T21:10:16 INFO src\common.c: Flash written and verified! jolly good!

[ubis]

@cxubrix Can you try with board = bluepill_f103c8, thanks.

It seems like I was right about build_flags.

[cxubrix]

@ubis works fine with bluepill_f103c8 and mbed

[MabezDev]

Any news on this? What version I can use in the meantime (or rollback platform stm?)?

[ubis]

The solution would be use to the following build_flags, so your platformio.ini configuration would look like this:

[env:genericSTM32F103C8]
platform = ststm32
board = genericSTM32F103C8
framework = arduino
upload_protocol = stlink
build_flags = -std=gnu++11 -MMD -DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG=1 -DSERIAL_USB -DGENERIC_BOOTLOADER 
build_unflags = -lc -lstdc++ -lnosys

Seems like debug ports are disabled if flag CONFIG_MAPLE_MINI_NO_DISABLE_DEBUG isn't defined. I've added other flags just because they do exist under Arduino IDE env.

[MabezDev]

Thanks, in the end I only needed -DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG=1 added to my build flags.

[KubaMiszcz]

same error with stm32cube both jumpers on 0, when i press RST and release when appears: Info : Listening on port 3333 for gdb connections it uploads succesfully but with error:

target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20005000
verified 6424 bytes in 0.146964s (42.687 KiB/s)
** Verified OK **
** Resetting Target **
in procedure 'program'
in procedure 'reset' called at file "embedded:startup.tcl", line 529
in procedure 'ocd_bouncer'

*** [upload] Error 1

if I'm late and not release on time I see:

[04/29/18 00:06:39] Processing genericSTM32F103C8 (platform: ststm32; board: genericSTM32F103C8; framework: stm32cube)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
PLATFORM: ST STM32 > STM32F103C8 (20k RAM. 64k Flash)
SYSTEM: STM32F103C8T6 72MHz 20KB RAM (64KB Flash)
DEBUG: CURRENT(blackmagic) EXTERNAL(blackmagic, jlink, stlink)
Warning! Cannot find a linker script for the required board! Firmware will be linked with a default linker script!
Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF MODES: FINDER(chain) COMPATIBILITY(light)
Collected 0 compatible libraries
Scanning dependencies...
No dependencies
Configuring upload protocol...
AVAILABLE: blackmagic, dfu, jlink, serial, stlink
CURRENT: upload_protocol = stlink
Uploading .pioenvs\genericSTM32F103C8\firmware.elf
GNU MCU Eclipse 64-bits Open On-Chip Debugger 0.10.0+dev-00392-gbe9ef0b0 (2018-01-12-15:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v28 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.196321
Error: init mode failed (unable to connect to the target)
in procedure 'program'
in procedure 'init' called at file "embedded:startup.tcl", line 495
in procedure 'ocd_bouncer'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1
========================================================================== [ERROR] Took 1.84 seconds ==========================================================================
The terminal process terminated with exit code: 1

my ini:

[env:genericSTM32F103C8]
platform = ststm32
board = genericSTM32F103C8
framework = stm32cube
upload_protocol = stlink
[platformio]
include_dir = Inc

those flags in ini files above doesnt help

i try some things from my cfg file in eclipse but it didnt work (but in eclipse i can upload files on the fly):

#
# STMicroelectronics ST-LINK/V1, ST-LINK/V2, ST-LINK/V2-1 in-circuit
# debugger/programmer
#

interface hla
hla_layout stlink
hla_device_desc "ST-LINK"
hla_vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b

# Optionally specify the serial number of ST-LINK/V2 usb device.  ST-LINK/V2
# devices seem to have serial numbers with unreadable characters.  ST-LINK/V2
# firmware version >= V2.J21.S4 recommended to avoid issues with adapter serial
# number reset issues.
# eg.
#hla_serial "\xaa\xbc\x6e\x06\x50\x75\xff\x55\x17\x42\x19\x3f"

#=============FROM ECLIPSE
# This is an ff3 board with a single STM32F103C8Tx chip
#
# Generated by System Workbench for STM32
# Take care that such file, as generated, may be overridden without any early notice. Please have a look to debug launch configuration setup(s)

#source [find interface/stlink-v2.cfg] 

set WORKAREASIZE 0x5000

#transport select "hla_swd"

#set CHIPNAME STM32F103C8Tx 

# Enable debug when in low power modes
set ENABLE_LOW_POWER 1

# Stop Watchdog counters when halt
set STOP_WATCHDOG 1

# STlink Debug clock frequency
set CLOCK_FREQ 4000

# use hardware reset, connect under reset
# connect_assert_srst needed if low power mode application running (WFI...)
#reset_config  srst_nogate connect_assert_srst srst_only
reset_config  srst_nogate connect_assert_srst
set CONNECT_UNDER_RESET 1 

#source [find target/stm32f1x.cfg]
_#^^it generates error :
# embedded:startup.tcl:21: Error: Command/target: STM32F103C8Tx.cpu Exists_