2018-03-15 12:30 AM
Hello,
my MCU is STM32F103C8T6, which should have 64kB FLASH, but it has been confirmed multiple times, that in fact it has 128kB of FLASH memory (just like STM32F103CBT6). This was also confirmed by me by writing to various FLASH pages (exceeding 64kB) by using standard functions, like:
FLASH_ProgramHalfWord(0x801000, 0xDE); //writes to (START+64kB) addressFLASH_ProgramHalfWord(0x801002, 0xAD); FLASH_ProgramHalfWord(0x801F00, 0xDE); //writes to (START+124kB) addressFLASH_ProgramHalfWord(0x801F02, 0xAD); and then checking this data with STM32 ST-LINK utility.Having explained that first, I have following problem, which is best to explain using different situations:
-Main program code size is 10K & FLASH_START_ADDRESS in linker file is 0x8000000 - I can upload .hex file normally
FLASH (rx) : ORIGIN = 0x08000000
-Main program code size is 10K & FLASH_START_ADDRESS in linker file is 0x800FC00 (10k below 64kB) - I can upload .hex file normallyFLASH (rx) : ORIGIN = 0x0800F800
-Main program code size is 10K & FLASH_START_ADDRESS in linker file is 0x8010000 (right at 64kB) - I can not upload file. I get 'load failed' error,
FLASH (rx) : ORIGIN =
0x8010000
-Main program code size is 10K & FLASH_START_ADDRESS in linker file is 0x801FC00 (10k below 128kB) - I can not upload file. I get 'load failed' error,FLASH (rx) : ORIGIN =
0x801F
C
00
It seems like whenever my program reaches 0x8010000 address (64kB), then I can't upload my code into MCU via Atollic, nor via ST-Link Utility (uploading hex file).How can I solve this problem? Maybe there is some kind of a DEVICE signature check before uploading the code, and it won't upload 100kB code size into 64kB (even though this MCU has 128kB)? Thanks in advance!
#size #flash #load #stm32f103c8t62018-03-15 12:57 AM
my MCU is STM32F103C8T6, which should have 64kB FLASH, but it has been confirmed multiple times, that in fact it has 128kB of FLASH memory (just like STM32F103CBT6).
...
How can I solve this problem?
Just think for a moment.
Is the CBT6 (128k) more expensive than the C8T6 (64k) ?
And if so, what would motivate ST to sell a 128kB Flash die as a 64k device ?
Might it have to do with the large space that flash occupies on the die, and defect probabiltiy ?
2018-03-15 01:50 AM
This is exactly what you get when you rely upon undocumented features!
So you got lucky with a few devices in a few test cases - that is not a justification to assume that all devices will work!
If you need more than 64K, then just get a device that is specified to have the required amount of Flash.
Simples!
2018-03-15 03:38 AM
meyer.frank
,Neil.Andrew
thank you for your answers.I am just curious why I am able to read/write to this 'extra' FLASH sector by hand (by using proper commands in my firmware), but I am not able to upload firmware, which would be located in these 'extra' sectors.This would be risky to use this 'undocummented extra feature' in commercial product.
2018-03-15 03:44 AM
,
,
This has come up frequently before, eg, ,
,2018-03-15 05:00 AM
IMHO the term 'undocumented feature' is very unfortunate.
Most obvious reason is a defect in the second Flash block, that forbids sale as 128kB part.
I would not call that a feature.
2018-03-15 05:58 AM
Did you read the linked post?
As noted, the reason you have 'extra' flash is almost certainly because several variants of this part are actually the same silicon die - the only difference is that the extra features have either not been tested at all, or have failed testing.
Grzegorz Wójcik wrote:
why I am able to read/write to this 'extra' FLASH sector by hand (by using proper commands in my firmware), but I am not able to upload firmware
Who knows? Presumably because the upload relies upon something is not working in that device - but your manual process just 'gets lucky' and happens not to fail...
Again, this is exactly what you should expect when you rely upon undocumented features.
2018-03-15 05:59 AM
The 'undocumented feature' is the fact that there is (or may be) any flash at all beyond the specified (ie, documented) 64K.
2018-03-21 03:24 AM
and another example: