-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
STM32F103R8: Problems flashing device - unknown core / chip id! 0 #468
Comments
Have you tried release v1.2.0? In the log output it seems it loads to incorrect flash loader to SRAM: |
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 |
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. |
You could try with openocd + gdb if you have a elf file: Use file with
The read operation with st-flash should work because it will not write a flash loader into SRAM. Maybe you could run |
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.
Running with --debug:
|
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. |
Tried the openocd recipe, and it fails to connect from my linux machine (it does connect to other targets I have around though).
|
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).
|
Updated ST-LINK firmware to v27, no change. Changed the
|
I also noticed that despite chip not being recognized, the following lines have changed when trying to read flash:
So it gets a chip ID, but seems to be confused by it? Previously it got 0. |
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:
|
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). |
I have seen also problems when between a usb command the application is quit and restarted then |
No luck with starting from a fresh USB connection.
|
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. |
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? |
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! |
Past week v1.3.1 is released. Maybe you could give that a shot. |
Closing due to inactivity, feel free to comment. |
I tried to reproduce this issue with my CKS32F103C8T6, but without any success and also unsure if this is somehow representative. |
@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.
... |
We conclude that the issue could not be reproduced on two different environments using similar hardware. |
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:
Outputs from st-info and st-flash:
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.
Returns almost immediately. The file is the correct size but does not seem to contain valid readout.
The tool hangs for about 20 seconds before reporting the flash loader run error.
The text was updated successfully, but these errors were encountered: