STM32F103C8T6 using St-link v2 doesn't flash on Ubuntu (works properly on windows) #1024
Comments
Nightwalker-87
added
component/st-flash
needs/investigation
needs/testing
os/linux
programmer/STLINK/V2
|
I have the same chip (on a bluepill-board) and may be able to test in this scenario soon. Please give me some time. |
|
For me, everything works as expected with v1.6.1 on Ubuntu 16.04 with a bluepill: |
|
That is actually what I had in mind regarding my bluepill board used on Debian Bullseye... |
|
I see... I just can say that i tried from scratch again, with same results (pointing to 0x8000000 and 0x0800000) After that i installed platformio, i been able to flash from there successfully, so no hardware failure is related imho. |
|
What's very unusual about the information in the first post above is that a flash size of 0 bytes is reported: The flash size should be reported as 65536 bytes (64 KiB). The device ID reported is 0x0410 which is correct. The revision ID reported is 0x2000 which is valid. The revision ID reported is a little unusual in my opinion as I would expect an STM32F103C8T6 that was manufactured within the last few years to have a revision ID of 0x2003. Nevertheless, 0x2000 is valid. The STM32F103C8T6 has a 16-bit flash size register at location 0x1ffff7e0. The content of this register should be 0x40 (64) indicating that the device has 64 KiB flash. STLink relies on the value of this register. I'm not familiar with PlatformIO or how it flashes devices. However, you do mention that you can flash the STM32F103C8T6 with PlatformIO. This means that you could implement a program that examines the content of the flash size register to confirm whether or not it's value is 0x40. If the value is 0x40, we have made no progress. If the value is 0, it would help to explain the issue. |
|
@marcosQuesada: You were using an old version of the tools previously (referring to your output). Please try it again with v1.6.1 and compare the result with @fivdi. |
|
Hi @Nightwalker-87
|
|
About PlatformIO workaround, It's a plugin for Visual Studio, and uses OpenOCD in the backgrounds to flash, those are the logs during flashing: Maybe that warning could help: Warn : STM32 flash size failed, probe inaccurate - assuming 128k flash |
|
@marcosQuesada: Thx for the update. Indeed it looks as if your MCU comes with 128k flash which is not the standard configuration and thus not detected properly by the tools. What comes to my mind is, that you can try our As far as I can remember, the issue that causes this is that some F103C8T6 technically ship with 128k though only 64k are addressable per default (as compliant with the specs). To make use of the full memory available in this case was the intention for implementing the mentioned option. You can give it a try to see if it helps in your case. However I see that the detection routine could see some improvements here though... |
|
Flashing using --flash options seems to flash properly, but fails on validation. The bluepill remains the same, so erasing has been succeed , but has not been updated. That's definitely one step in the correct direction :) |
|
Hmm, I wouldn't assess that writing concluded successfully: 3/57 pages written We need some improvement here as well. 😕 |
|
On Tue, Sep 29, 2020 at 12:27:53PM -0700, nightwalker-87 wrote:
I'd need a STM32F1C8T6 Bluepill (Note: Not to be confused with STM32F1C**B**T6 !)
with 128k to look into this.
What is the "protocol" to send hardware to team members?
(And is it is OK to document that is a separate issue?)
|
|
@stappersg: Eh, we never had the case, and I don't really think it should be common practise, as we don't offer any kind of support for any commercial products. However if anybody feels himself committed to help somebody in a specific issue and arrange sharing of hardware on a personal basis, he / they should be fine with that - but not on behalf of the project. Targeting your point it could be more helpful to gain common recognition or support from ST for this project e.g. resulting in selective free hardware-giveaways or external dev-support or whatever may appear applicable. |
|
Here is what I see on a bluepill that has an STM32F103C8T6 with 128KB of flash. $ st-info --version
v1.6.1
$ st-info --probe
Found 1 stlink programmers
serial: 500024001800003250334d4e
hla-serial: "\x50\x00\x24\x00\x18\x00\x00\x32\x50\x33\x4d\x4e"
flash: 131072 (pagesize: 1024)
sram: 20480
chipid: 0x0410
descr: F1xx Medium-density
$ st-flash --reset write blinky.bin 0x8000000
st-flash 1.6.1
2020-09-30T22:44:54 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 128 KiB flash in at least 1 KiB pages.
file blinky.bin md5 checksum: e378e365fc9787922c1d3514fb7d8d3e, stlink checksum: 0x0000c4a8
2020-09-30T22:44:54 INFO common.c: Attempting to write 688 (0x2b0) bytes to stm32 address: 134217728 (0x8000000)
2020-09-30T22:44:54 INFO common.c: Flash page at addr: 0x08000000 erased
2020-09-30T22:44:54 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-09-30T22:44:54 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-09-30T22:44:54 INFO flash_loader.c: Successfully loaded flash loader in sram
1/1 pages written
2020-09-30T22:44:54 INFO common.c: Starting verification of write complete
2020-09-30T22:44:54 INFO common.c: Flash written and verified! jolly good!
$ The flash size register at location 0x1ffff7e0 contains the value 0x80 which corresponds to 128KB. What's also of interest is the following text in section stm32f1x on page 100 of the OpenOCD User’s Guide,
|
|
Thank you @fivdi. Digging around i found that the explanation to that error is: "Your BluePill board contains a CS32F103C8T6 chip, a Chinese clone instead of a real STM32F103C8T6." |
|
Ah, it's that (#833) old problem again - and the chip is marked as "STM32F103C8T6" instead of "CKS32F103C8T6"? |
|
Correct, chip is marked as STM32F103C8T8 |
Nightwalker-87
added
general/documentation
status/no-bug
and removed
needs/investigation
labels
|
It is really annoying to see that these fake-chips are still on the market. @marcosQuesada Thank you very much for your help. |
|
@Nightwalker-87 Thank you so much for your time and even more for your patience. |
|
Related to #855. |
Nightwalker-87
added
status/duplicate
status/no-bug
status/resolved
and removed
status/no-bug
labels
Thank you for giving feedback to the stlink project.
NOTICE: Please read and follow instructions in #906 before submitting a ticket. This feature request will be deleted without notice when not enough information is provided! So please ensure that all fields are filled out.
In order to allow developers and other contributors to isolate and target your respective issue, please take some time to fill out each of the following items appropriate to your specific problem:
Futher we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:
Commandline-Output:
Expected/description:
I reviewed all issues related to this "Unknown memory region", many of them point to a bad cable connection between st-link and bluepill (SCLK SDIO), but, i tested everything on windows 10 too, and i am able to flash successfully, so connection must be fine.
Everything else seems to be well recognized, as:
Maybe is my fault, but i don't know what else to do, i even installed everything from scratch in a different ubuntu machine (18.04) with same results.
Thank you for your support.
The stlink project maintainers
The text was updated successfully, but these errors were encountered: