cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F103C8T6 load problem when code exceeding 64kB FLASH

Grzegorz Wójcik
Associate II
Posted on March 15, 2018 at 08:30

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) address

FLASH_ProgramHalfWord(0x801002, 0xAD);

FLASH_ProgramHalfWord(0x801F00, 0xDE); //writes to (START+124kB) address

FLASH_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 normally

FLASH (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 #stm32f103c8t6
8 REPLIES 8
AvaTar
Lead
Posted on March 15, 2018 at 08:57

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 ?

Posted on March 15, 2018 at 09:50

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!

Grzegorz Wójcik
Associate II
Posted on March 15, 2018 at 11:38

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.

Posted on March 15, 2018 at 10:44

 ,

 ,

This has come up frequently before, eg, ,

 ,
Posted on March 15, 2018 at 12:00

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.

Posted on March 15, 2018 at 12:58

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.

Posted on March 15, 2018 at 12:59

The 'undocumented feature' is the fact that there is (or may be) any flash at all beyond the specified (ie, documented) 64K.

Posted on March 21, 2018 at 10:24

and another example:

https://community.st.com/0D50X00009Xkaj9SAB