Skip to content
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

Option: ignore flash size reported by chip #305

Closed
LupinIII opened this issue Mar 26, 2015 · 7 comments · Fixed by #576
Closed

Option: ignore flash size reported by chip #305

LupinIII opened this issue Mar 26, 2015 · 7 comments · Fixed by #576

Comments

@LupinIII
Copy link

LupinIII commented Mar 26, 2015

I have a small dev board from ebay (like this http://www.ebay.com/itm/321569700934 ; available from many sellers) with a F103C8T6. According to the specs it should have 64k of flash. That is also what st-flash reports when writing to it.
But, and I don't know why this is actually possible, when I use the the "Flash Loader Demonstrator" from ST and flash via UART (setting bootloader pins accordingly) I can select a target "STM32F1_Med-density_128K" from a dropdown list (the only other entry being "STM32F1_Med-density_64K" for a F103C8T6). It is no problem to flash a bin (hex works of course, too, but with a bin it's easy to tell how much you really write) that is larger than 64k. It verifies the contents of the flash and whatever is written to the flash also works after that.
If I try to flash the same bin file with st-flash I get these messages:

INFO: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
INFO: Attempting to write 112892 (0x1b8fc) bytes to stm32 address: 134217728 (0x8000000)
ERROR: addr too high

and the write fails. Obviously it sees a bin that's too large for the flash and stops. But as seen before at least for the chips I have it's totally possible to write more than that sucessfully.

So it would be nice to have an option to either ignore the reported flash size completely or specify it on the command line (so verifying could still work and not stop reading prematurely)

@cabo
Copy link

cabo commented Sep 20, 2015

Here's my little hack for this:

diff --git INDEX/src/stlink-common.c WORKDIR/src/stlink-common.c
index 972c9f3..9f62252 100644
--- INDEX/src/stlink-common.c
+++ WORKDIR/src/stlink-common.c
@@ -475,6 +475,9 @@ int stlink_load_device_params(stlink_t *sl) {
         }
     } else {
         sl->flash_size = flash_size * 1024;
+        /* HACK for STM21F103C8T6 */
+        if (sl->flash_size == 64 * 1024 && getenv("C8T6HACK"))
+          sl->flash_size = 128 * 1024;
     }
     sl->flash_pgsz = params->flash_pagesize;
     sl->sram_size = params->sram_size;

So you call e.g., st-util as

C8T6HACK= st-util

and magically you get

INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes

I did this as an environment variable because setting an option may require changes in tons of Makefiles, build environments etc.; it is much less work to just set the environment variable before starting those.

@cabo
Copy link

cabo commented Oct 6, 2015

BTW, that hack is now available in my fork https://github.com/cabo/stlink
(I'm not doing a pull request yet because I'd like to understand whether and how much that hack should be generalized to other chips.)

@xor-gate xor-gate closed this as completed May 4, 2016
@ghost
Copy link

ghost commented May 13, 2016

I have same problem with F100C6T6 which should have 4KB of RAM (and don't have TIM4) like written in datasheet. But he have 8KB RAM and TIM4. stlink detects this chip like Low-density with 4KB RAM and i can't access addresses higher than 0x20000FA0 in gdb.

I recompile source without this commit and it solved my problem.
d04fcf5

@xor-gate
Copy link
Member

@potozi thanks for reporting!

obgm added a commit to obgm/RIOT that referenced this issue Oct 24, 2016
The bluepill board[1] is a tiny arduino-like developer board
that is equipped with a powerful STM32F103 MCU. The chip
is officially an STM32F103C8T6 model that in fact appears
to have 128 KiB flash (cf. [2]). Thus it is recommended to
use the patched stlink[3] to flash the firmware.

[1] http://wiki.stm32duino.com/index.php?title=Blue_Pill
[2] stlink-org/stlink#305
[3] https://github.com/cabo/stlink
obgm added a commit to obgm/RIOT that referenced this issue Nov 9, 2016
The bluepill board[1] is a tiny arduino-like developer board
that is equipped with a powerful STM32F103 MCU. The chip
is officially an STM32F103C8T6 model that in fact appears
to have 128 KiB flash (cf. [2]). Thus it is recommended to
use the patched stlink[3] to flash the firmware.

[1] http://wiki.stm32duino.com/index.php?title=Blue_Pill
[2] stlink-org/stlink#305
[3] https://github.com/cabo/stlink
obgm added a commit to obgm/RIOT that referenced this issue Nov 19, 2016
The bluepill board[1] is a tiny arduino-like developer board
that is equipped with a powerful STM32F103 MCU. The chip
is officially an STM32F103C8T6 model that in fact appears
to have 128 KiB flash (cf. [2]). Thus it is recommended to
use the patched stlink[3] to flash the firmware.

[1] http://wiki.stm32duino.com/index.php?title=Blue_Pill
[2] stlink-org/stlink#305
[3] https://github.com/cabo/stlink
@Testato
Copy link

Testato commented Nov 22, 2016

i can confirm that also my BluePIll have 128KBytes

nmeum pushed a commit to beduino-project/RIOT that referenced this issue Feb 17, 2017
The bluepill board[1] is a tiny arduino-like developer board
that is equipped with a powerful STM32F103 MCU. The chip
is officially an STM32F103C8T6 model that in fact appears
to have 128 KiB flash (cf. [2]). Thus it is recommended to
use the patched stlink[3] to flash the firmware.

[1] http://wiki.stm32duino.com/index.php?title=Blue_Pill
[2] stlink-org/stlink#305
[3] https://github.com/cabo/stlink
nmeum pushed a commit to beduino-project/RIOT that referenced this issue Feb 24, 2017
The bluepill board[1] is a tiny arduino-like developer board
that is equipped with a powerful STM32F103 MCU. The chip
is officially an STM32F103C8T6 model that in fact appears
to have 128 KiB flash (cf. [2]). Thus it is recommended to
use the patched stlink[3] to flash the firmware.

[1] http://wiki.stm32duino.com/index.php?title=Blue_Pill
[2] stlink-org/stlink#305
[3] https://github.com/cabo/stlink
nmeum pushed a commit to beduino-project/RIOT that referenced this issue Mar 20, 2017
The bluepill board[1] is a tiny arduino-like developer board
that is equipped with a powerful STM32F103 MCU. The chip
is officially an STM32F103C8T6 model that in fact appears
to have 128 KiB flash (cf. [2]). Thus it is recommended to
use the patched stlink[3] to flash the firmware.

[1] http://wiki.stm32duino.com/index.php?title=Blue_Pill
[2] stlink-org/stlink#305
[3] https://github.com/cabo/stlink
@xor-gate
Copy link
Member

No flash size must normally be read from the chip before making any decision, but currently texane/stlink tools don't do that.

@stlink-org stlink-org locked as off-topic and limited conversation to collaborators Jan 16, 2018
@Nightwalker-87 Nightwalker-87 added this to the v1.6.1 milestone Feb 26, 2020
@Nightwalker-87 Nightwalker-87 modified the milestones: v1.6.1, Feedback required Mar 20, 2020
@Nightwalker-87 Nightwalker-87 changed the title Option: ignore flash size reported by chip [feature] Option: ignore flash size reported by chip Mar 25, 2020
@Nightwalker-87 Nightwalker-87 modified the milestones: v1.6.1, v1.4.0 Mar 31, 2020
@Nightwalker-87 Nightwalker-87 changed the title [feature] Option: ignore flash size reported by chip Option: ignore flash size reported by chip Mar 31, 2020
@stlink-org stlink-org deleted a comment Apr 14, 2020
@stlink-org stlink-org deleted a comment from xor-gate Apr 14, 2020
@stlink-org stlink-org unlocked this conversation Apr 14, 2020
@stlink-org stlink-org locked as resolved and limited conversation to collaborators Apr 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants
@cabo @LupinIII @xor-gate @Testato @Nightwalker-87 and others