STM32F103R8: Problems flashing device - unknown core / chip id! 0 #468

kgoba · 2016-09-16T08:24:09Z

Programmer/board type: Stlink/v2-onboard (STMF4DISCOVERY board)
Programmer firmware version: e.g STSW-LINK007 2.27.15
Operating system: Linux Ubuntu 16.04
Stlink tools version and/or git commit hash: 7023a9a and also earlier versions
Stlink commandline tool name: st-info / st-flash
Target chip (and optional board): STM32F103R8 ("Blue Pill" board)

I am using stm32f103r8 device (64k flash, 20k RAM) with a ST-LINK/V2 programmer (Discovery board with F407VG). I have multiple boards like these (http://wiki.stm32duino.com/index.php?title=Blue_Pill) and none of them seems to work with stlink. I have connected the GND/SWDIO/SWCLK and RESET pins to the SWD connector. Using this setup has worked for other chips. Problems include:

not being able to read the flash correctly
not being able to write the flash at all
reporting wrong Flash size

Outputs from st-info and st-flash:

$ st-info --probe
Found 1 stlink programmers
 serial: 533f6d06493f55573224113f
openocd: "\x53\x3f\x6d\x06\x49\x3f\x55\x57\x32\x24\x11\x3f"
  flash: 26230784 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

Stlink recognizes the chip, though somewhat incorrectly, reporting 26230784 bytes of flash. I am not sure about the chipid, as I don't know the correct value.

$ st-flash read orig.bin 0x8000000 0x10000
2016-09-16T11:14:25 INFO /home/karlis/build/stlink/src/common.c: Loading device parameters....
2016-09-16T11:14:25 INFO /home/karlis/build/stlink/src/common.c: Device connected is: F1 Medium-density device, id 0x20036410
2016-09-16T11:14:25 INFO /home/karlis/build/stlink/src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x1904000 bytes (25616 KiB) in pages of 1024 bytes

Returns almost immediately. The file is the correct size but does not seem to contain valid readout.

$ st-flash write orig.bin 0x8000000
2016-09-16T11:17:24 INFO /home/karlis/build/stlink/src/common.c: Loading device parameters....
2016-09-16T11:17:24 INFO /home/karlis/build/stlink/src/common.c: Device connected is: F1 Medium-density device, id 0x20036410
2016-09-16T11:17:24 INFO /home/karlis/build/stlink/src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x1904000 bytes (25616 KiB) in pages of 1024 bytes
2016-09-16T11:17:24 INFO /home/karlis/build/stlink/src/common.c: Attempting to write 65536 (0x10000) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x0800fc00 erased
2016-09-16T11:17:26 INFO /home/karlis/build/stlink/src/common.c: Finished erasing 64 pages of 1024 (0x400) bytes
2016-09-16T11:17:26 INFO /home/karlis/build/stlink/src/common.c: Starting Flash write for VL/F0/F3 core id
2016-09-16T11:17:26 INFO /home/karlis/build/stlink/src/flash_loader.c: Successfully loaded flash loader in sram
2016-09-16T11:17:46 ERROR /home/karlis/build/stlink/src/flash_loader.c: flash loader run error
2016-09-16T11:17:46 ERROR /home/karlis/build/stlink/src/common.c: stlink_flash_loader_run(0x8000000) failed! == -1

The tool hangs for about 20 seconds before reporting the flash loader run error.

The text was updated successfully, but these errors were encountered:

xor-gate · 2016-09-16T08:46:31Z

Have you tried release v1.2.0? In the log output it seems it loads to incorrect flash loader to SRAM:
Starting Flash write for VL/F0/F3 core id

xor-gate · 2016-09-16T09:02:20Z

Maybe you should first try to mass-erase and then flash. I have seen some problems with this. And for some people it resolves the issue for flashing: #356

kgoba · 2016-09-16T10:51:49Z

Thanks for the quick response. I switched to v1.2.0 and tried mass-erasing, and it seemed to have some effect (the preloaded blinking LED code is gone), but it did not help the other problems. Flash size is still reported around as 25616 kB, reading the flash still gives wrong binary image and writing to flash reports the same problem.

xor-gate · 2016-09-16T11:44:40Z

You could try with openocd + gdb if you have a elf file:

Use file with openocd -f <file>

source [find interface/stlink-v2.cfg]
transport select hla_swd
source [find target/stm32f1.cfg]
reset_config srst_only

The read operation with st-flash should work because it will not write a flash loader into SRAM. Maybe you could run st-flash with --debug.
As I am not sure what is causing the problems. The report of the flash size is also not good.

kgoba · 2016-09-16T12:02:03Z

In the meanwhile I hooked up the same setup to a Windows machine and used the original STM32 ST-Link utility. It complained immediately that the chip had a readout protection. Ok, that might explain some of the flash reading problems. Removed the protection, managed to do an erase, read and flashed another blinker code. The code runs fine.

Now the story gets a twist here. I connect it back to my linux machine, and st-info does not detect any chip any more.

$ st-info --probe
Found 1 stlink programmers

$ st-flash read orig.bin 0x8000000
2016-09-16T14:58:43 INFO /home/karlis/build/stlink/src/stlink-common.c: Loading device parameters....
2016-09-16T14:58:43 WARN /home/karlis/build/stlink/src/stlink-common.c: unknown chip id! 0

Running with --debug:

$ st-flash --debug read orig.bin 0x8000000
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: stlink current mode: debug (jtag or swd)
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: stlink current mode: debug (jtag or swd)
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_reset ***
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** looking up stlink version
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: st vid         = 0x0483 (expect 0x0483)
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: stlink pid     = 0x3748
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: stlink version = 0x2
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: jtag version   = 0x18
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: swim version   = 0x0
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c:     notice: the firmware doesn't support a swim interface
2016-09-16T15:01:37 INFO /home/karlis/build/stlink/src/stlink-common.c: Loading device parameters....
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_core_id ***
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: core_id = 0x00000000
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_read_debug32 0 is 0xe0042000
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_read_debug32 0 is 0x40015800
2016-09-16T15:01:37 WARN /home/karlis/build/stlink/src/stlink-common.c: unknown chip id! 0
2016-09-16T15:01:37 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_close ***

kgoba · 2016-09-16T12:12:40Z

The original STM32 ST-Link Utility also had struggle determining flash size initially before Readout protection was removed. I don't know the details of this mechanism, but it could be related. After removing the protection, the original utility now shows 64k flash correctly and allows reading/flashing without a glitch, but still no luck on linux.

kgoba · 2016-09-16T12:14:26Z

Tried the openocd recipe, and it fails to connect from my linux machine (it does connect to other targets I have around though).

$ openocd -f config.ocd 
Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
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
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
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 v24 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.892743
Error: init mode failed (unable to connect to the target)
in procedure 'init' 
in procedure 'ocd_bouncer'

xor-gate · 2016-09-16T12:23:25Z

If OpenOCD can't connect correctly then we are a bit out of luck (for now). As the OpenOCD project has many users and maintainers it works 90% of the time. Maybe the reset configuration is not correct. As I can see your JTAG firmware is v24 probably you should update your programmer to v27 (as I have seen weird behaviour with opensource tools).

reset_config trst_and_srst trst_pulls_srst srst_nogate connect_assert_srst

See http://openocd.org/doc/html/Reset-Configuration.html

kgoba · 2016-09-16T12:41:32Z

Updated ST-LINK firmware to v27, no change. Changed the reset_config to your suggestion and voila, openocd can connect.

$ openocd -f config.ocd 
... snip ...
Info : STLINK v2 JTAG v27 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.901598
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

kgoba · 2016-09-16T12:44:32Z

I also noticed that despite chip not being recognized, the following lines have changed when trying to read flash:

2016-09-16T15:43:28 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_read_debug32 a05f0000 is 0xe0042000
2016-09-16T15:43:28 WARN /home/karlis/build/stlink/src/stlink-common.c: unknown chip id! 0xa05f0000

So it gets a chip ID, but seems to be confused by it? Previously it got 0.

kgoba · 2016-09-16T12:48:23Z

Also interesting, when I connect with openocd and exit with Ctrl-C, if followed by a st-flash command, its behaviour seems to change. It reads the chip ID and core ID (and still fails to read the flash). When I repeat the same st-flash command, it fails with the unknown chip id error. I hope it helps to track down the problem:

$ st-flash --debug read orig.bin 0x8000000
... snip ...
2016-09-16T15:46:13 INFO /home/karlis/build/stlink/src/stlink-common.c: Loading device parameters....
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_core_id ***
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: core_id = 0x1ba01477
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_read_debug32 20036410 is 0xe0042000
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_read_debug32 0 is 0x1ffff7e0
2016-09-16T15:46:13 INFO /home/karlis/build/stlink/src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2016-09-16T15:46:13 INFO /home/karlis/build/stlink/src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0 bytes (0 KiB) in pages of 1024 bytes
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: stlink current mode: debug (jtag or swd)
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: stlink current mode: debug (jtag or swd)
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_force_debug_mode ***
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_status ***
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c:   core status: running
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_exit_debug_mode ***
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_write_debug32 a05f0000 to 0xe000edf0
2016-09-16T15:46:13 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_close ***

xor-gate · 2016-09-16T12:48:24Z

Probably because there is something wrong with the reset the device id is the address of the register where the devid is located (this is when the programmer is unable to read a sane value from the register, it returns the address trying to read).

xor-gate · 2016-09-16T12:50:41Z

I have seen also problems when between a usb command the application is quit and restarted then texane/stlink tools are unable to send commands. You should try to replug the programmer and start st-flash with a read.

kgoba · 2016-09-16T13:10:31Z

No luck with starting from a fresh USB connection.

$ st-flash --debug --reset read orig.bin 0x8000000
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: stlink current mode: dfu
2016-09-16T16:09:54 INFO /home/karlis/build/stlink/src/stlink-usb.c: -- exit_dfu_mode
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_exit_dfu_mode ***
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: stlink current mode: mass
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_enter_swd_mode ***
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_reset ***
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** looking up stlink version
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: st vid         = 0x0483 (expect 0x0483)
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: stlink pid     = 0x3748
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: stlink version = 0x2
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: jtag version   = 0x1b
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: swim version   = 0x0
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c:     notice: the firmware doesn't support a swim interface
2016-09-16T16:09:54 INFO /home/karlis/build/stlink/src/stlink-common.c: Loading device parameters....
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_core_id ***
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: core_id = 0x00000000
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_read_debug32 0 is 0xe0042000
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_read_debug32 0 is 0x40015800
2016-09-16T16:09:54 WARN /home/karlis/build/stlink/src/stlink-common.c: unknown chip id! 0
2016-09-16T16:09:54 DEBUG /home/karlis/build/stlink/src/stlink-common.c: *** stlink_close ***

xor-gate · 2016-09-16T13:18:43Z

It seems some inconsistency how openocd handles reset and how st-flash does it (just guessing). I have no clue, because as you say on other targets it works as expected. Maybe for now you should stick with openocd for this misbehaving target :-( and hope someone else can dig deeper and come up with a solution.

xor-gate · 2017-01-14T14:12:49Z

I had to reread the whole thread to try to understand why you having problems big time with this target. Probably you did not made any progress?

kgoba · 2017-01-14T20:30:05Z

Haven't worked with that board since then. I will probably give it a try again in few weeks and report back. Thanks for looking into it!

xor-gate · 2017-03-01T19:16:29Z

Past week v1.3.1 is released. Maybe you could give that a shot.

xor-gate · 2017-03-29T05:42:51Z

Closing due to inactivity, feel free to comment.

Nightwalker-87 · 2021-05-17T22:37:25Z

I tried to reproduce this issue with my CKS32F103C8T6, but without any success and also unsure if this is somehow representative.
@Ant-ON Do you have a similar board in your F-Series set of boards to test and review?

Ant-ON · 2021-05-22T19:20:22Z

@Nightwalker-87 I have a blue pill with such the STM32F103C8. Everything is displayed well:

st-flash 1.7.0-18-g22fba02
2021-05-22T23:40:12 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
...

Nightwalker-87 · 2021-05-24T08:06:13Z

We conclude that the issue could not be reproduced on two different environments using similar hardware.
Also there were no general issues reported for variants of the STM32F103 MCU chipset regarding the described problem.
Well possible that the used hardware was faulty or maybe even affected by counterfeit (see respective section in our tutorial).
Against this background I am closing this issue now as resolved.

xor-gate added os/linux target/stm32f1 error/flash-loader component/st-flash labels Sep 16, 2016

xor-gate added the needs/investigation label Jan 14, 2017

xor-gate added this to the Unplanned (Contributions Welcome) milestone Jan 14, 2017

xor-gate added the needs/issuer-feedback label Mar 1, 2017

xor-gate closed this as completed Mar 29, 2017

stlink-org locked and limited conversation to collaborators May 7, 2017

Nightwalker-87 modified the milestones: Unplanned (Contributions Welcome), Next Feb 19, 2020

Nightwalker-87 changed the title ~~Problems flashing STM32F103R8 device~~ STM32F103R8: Problems flashing device Mar 31, 2020

Nightwalker-87 modified the milestones: Feedback required, Device issues, Flash-loader errors Mar 31, 2020

Nightwalker-87 removed the needs/issuer-feedback label Apr 14, 2020

Nightwalker-87 mentioned this issue Oct 17, 2020

st-flash: respect --connect-under-reset option #1051

Merged

Nightwalker-87 modified the milestones: c) Flash loader run errors, a) Old issues Mar 11, 2021

Nightwalker-87 changed the title ~~STM32F103R8: Problems flashing device~~ STM32F103R8: Problems flashing device - unknown core id! 0 / chip id! 0 Apr 4, 2021

Nightwalker-87 changed the title ~~STM32F103R8: Problems flashing device - unknown core id! 0 / chip id! 0~~ STM32F103R8: Problems flashing device - unknown core / chip id! 0 Apr 4, 2021

Nightwalker-87 modified the milestones: Old issues, v1.6.3 Apr 4, 2021

Nightwalker-87 self-assigned this May 2, 2021

Nightwalker-87 assigned Ant-ON May 17, 2021

Nightwalker-87 added status/resolved-verified status/resolved and removed needs/testing labels May 24, 2021

Nightwalker-87 modified the milestones: v1.7.1, v1.7.0, Resolved questions & general issues May 24, 2021

Nightwalker-87 added the status/no-bug label May 24, 2021

Nightwalker-87 closed this as completed May 24, 2021

Nightwalker-87 modified the milestones: Resolved questions & general issues, (2011-2021) Resolved questions & general issues May 24, 2021

Nightwalker-87 mentioned this issue Aug 14, 2021

Unknown chip id 0! #620

Closed

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

STM32F103R8: Problems flashing device - unknown core / chip id! 0 #468

STM32F103R8: Problems flashing device - unknown core / chip id! 0 #468

kgoba commented Sep 16, 2016 •

edited by Nightwalker-87

xor-gate commented Sep 16, 2016 •

edited

xor-gate commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016 •

edited

xor-gate commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016 •

edited

xor-gate commented Sep 16, 2016

kgoba commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016

kgoba commented Sep 16, 2016 •

edited

xor-gate commented Sep 16, 2016

xor-gate commented Sep 16, 2016

kgoba commented Sep 16, 2016

xor-gate commented Sep 16, 2016 •

edited

xor-gate commented Jan 14, 2017

kgoba commented Jan 14, 2017

xor-gate commented Mar 1, 2017

xor-gate commented Mar 29, 2017

Nightwalker-87 commented May 17, 2021

Ant-ON commented May 22, 2021

Nightwalker-87 commented May 24, 2021 •

edited

STM32F103R8: Problems flashing device - unknown core / chip id! 0 #468

STM32F103R8: Problems flashing device - unknown core / chip id! 0 #468

Comments

kgoba commented Sep 16, 2016 • edited by Nightwalker-87

xor-gate commented Sep 16, 2016 • edited

xor-gate commented Sep 16, 2016 • edited

kgoba commented Sep 16, 2016 • edited

xor-gate commented Sep 16, 2016 • edited

kgoba commented Sep 16, 2016 • edited

kgoba commented Sep 16, 2016 • edited

kgoba commented Sep 16, 2016 • edited

xor-gate commented Sep 16, 2016

kgoba commented Sep 16, 2016 • edited

kgoba commented Sep 16, 2016

kgoba commented Sep 16, 2016 • edited

xor-gate commented Sep 16, 2016

xor-gate commented Sep 16, 2016

kgoba commented Sep 16, 2016

xor-gate commented Sep 16, 2016 • edited

xor-gate commented Jan 14, 2017

kgoba commented Jan 14, 2017

xor-gate commented Mar 1, 2017

xor-gate commented Mar 29, 2017

Nightwalker-87 commented May 17, 2021

Ant-ON commented May 22, 2021

Nightwalker-87 commented May 24, 2021 • edited

kgoba commented Sep 16, 2016 •

edited by Nightwalker-87

xor-gate commented Sep 16, 2016 •

edited

xor-gate commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016 •

edited

xor-gate commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016 •

edited

kgoba commented Sep 16, 2016 •

edited

xor-gate commented Sep 16, 2016 •

edited

Nightwalker-87 commented May 24, 2021 •

edited