Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26950 > unrolled thread

stm32f103rct6 with more ram then expected

Back to article view | Back to comp.arch.embedded

Contents

  stm32f103rct6 with more ram then expected kristoff <kristoff@skypro.be> - 2017-06-26 01:42 +0200
    Re: stm32f103rct6 with more ram then expected raimond.dragomir@gmail.com - 2017-06-25 21:33 -0700
    Re: stm32f103rct6 with more ram then expected Uwe Bonnes <bon@hertz.tu-darmstadt.de> - 2017-06-26 12:09 +0000
      Re: stm32f103rct6 with more ram then expected rickman <gnuarm@gmail.com> - 2017-06-26 10:46 -0400
        Re: stm32f103rct6 with more ram then expected lasselangwadtchristensen@gmail.com - 2017-06-26 10:11 -0700
        Re: stm32f103rct6 with more ram then expected Allan Herriman <allanherriman@hotmail.com> - 2017-06-27 11:23 +0000
          Re: stm32f103rct6 with more ram then expected rickman <gnuarm@gmail.com> - 2017-06-27 11:49 -0400
    Re: stm32f103rct6 with more ram then expected Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2017-06-30 15:03 +0200

#26950 — stm32f103rct6 with more ram then expected

Hi,


Some time ago, I boght a cheap devboard from a  well known Chinese 
webshop with a STM32F103RCT6 chip on it.

According to the datasheets, that chip has 48 KB of RAM and 256 KB of 
flashrom.

However, when using the linux arm-gdb and the st-util and st-info, they 
say that the chip actually has 64 KB of RAM (so more then exptected).


Using gdb (writing to memory and reading back from it), it does look at 
there is indeed 64 KB of RAM in the chip, ... but I do not find any 
reference to that chip with 64 KB of RAM.


Anybody any idea what is going on here?

The datasheet does mention this:
1. 64 KB RAM for 256 KB Flash are available on devices delivered in CSP 
packages only.

but the "T6" (at the end of full name) indicates that it is a 
LQFP64-package, no WLCSP64. (and, indeed, it is a LQFP chip).

Or does "CSP" mean something else? (Customer Special ???)


2/ Or could it be that this chip was originally intended as a ..."RD" or 
"RE" chip (384 or 512 KB of flash, 64 KB of RAM) where that the 
post-production quality-check showed that the upper half of the flash is 
bad, ...  so instead of just trowing it away, it is sold as a "RC" chip 
(256 KB of flash)?


3/ Or is this a counterfeit?


Did somebody already have simular experience?
Any ideas?



Cheerio! Kr. Bonne.

[toc] | [next] | [standalone]

#26956

luni, 26 iunie 2017, 02:42:02 UTC+3, kristoff a scris:
> Hi,
> 
> 
> Some time ago, I boght a cheap devboard from a  well known Chinese 
> webshop with a STM32F103RCT6 chip on it.
> 
It might be a "GD" device.
Google "GD STM32" if you want to know more. I don't know details.

[toc] | [prev] | [next] | [standalone]

#26959

kristoff <kristoff@skypro.be> wrote:
> Hi,
> 
> 
> Some time ago, I boght a cheap devboard from a  well known Chinese 
> webshop with a STM32F103RCT6 chip on it.
> 
> According to the datasheets, that chip has 48 KB of RAM and 256 KB of 
> flashrom.
> 
> However, when using the linux arm-gdb and the st-util and st-info, they 
> say that the chip actually has 64 KB of RAM (so more then exptected).
> 
> 
> Using gdb (writing to memory and reading back from it), it does look at 
> there is indeed 64 KB of RAM in the chip, ... but I do not find any 
> reference to that chip with 64 KB of RAM.
> 
> 
> Anybody any idea what is going on here?
> 
> The datasheet does mention this:
> 1. 64 KB RAM for 256 KB Flash are available on devices delivered in CSP 
> packages only.
> 
> but the "T6" (at the end of full name) indicates that it is a 
> LQFP64-package, no WLCSP64. (and, indeed, it is a LQFP chip).
> 
> Or does "CSP" mean something else? (Customer Special ???)
> 
> 
> 2/ Or could it be that this chip was originally intended as a ..."RD" or 
> "RE" chip (384 or 512 KB of flash, 64 KB of RAM) where that the 
> post-production quality-check showed that the upper half of the flash is 
> bad, ...  so instead of just trowing it away, it is sold as a "RC" chip 
> (256 KB of flash)?
> 
> 
> 3/ Or is this a counterfeit?
> 
> 
> Did somebody already have simular experience?
> Any ideas?

It is clear that ST produces much less chip variants than they sell. However
you don't know what you get beside that what is promised by the original
data sheets. Are add-ons
- still availabe on the next chip you buy?
- where add-ons tested bad during production?
- where add-ons tested at all?

For a check F103xB vs F103xE, check for the presence of the additional
devices, like ADC3, FSMC, SDIO, TIM5, SPI2, UART4/5 etc.

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

[toc] | [prev] | [next] | [standalone]

#26960

Uwe Bonnes wrote on 6/26/2017 8:09 AM:
> kristoff <kristoff@skypro.be> wrote:
>> Hi,
>>
>>
>> Some time ago, I boght a cheap devboard from a  well known Chinese
>> webshop with a STM32F103RCT6 chip on it.
>>
>> According to the datasheets, that chip has 48 KB of RAM and 256 KB of
>> flashrom.
>>
>> However, when using the linux arm-gdb and the st-util and st-info, they
>> say that the chip actually has 64 KB of RAM (so more then exptected).
>>
>>
>> Using gdb (writing to memory and reading back from it), it does look at
>> there is indeed 64 KB of RAM in the chip, ... but I do not find any
>> reference to that chip with 64 KB of RAM.
>>
>>
>> Anybody any idea what is going on here?
>>
>> The datasheet does mention this:
>> 1. 64 KB RAM for 256 KB Flash are available on devices delivered in CSP
>> packages only.
>>
>> but the "T6" (at the end of full name) indicates that it is a
>> LQFP64-package, no WLCSP64. (and, indeed, it is a LQFP chip).
>>
>> Or does "CSP" mean something else? (Customer Special ???)
>>
>>
>> 2/ Or could it be that this chip was originally intended as a ..."RD" or
>> "RE" chip (384 or 512 KB of flash, 64 KB of RAM) where that the
>> post-production quality-check showed that the upper half of the flash is
>> bad, ...  so instead of just trowing it away, it is sold as a "RC" chip
>> (256 KB of flash)?
>>
>>
>> 3/ Or is this a counterfeit?
>>
>>
>> Did somebody already have simular experience?
>> Any ideas?
>
> It is clear that ST produces much less chip variants than they sell. However
> you don't know what you get beside that what is promised by the original
> data sheets. Are add-ons
> - still availabe on the next chip you buy?
> - where add-ons tested bad during production?
> - where add-ons tested at all?
>
> For a check F103xB vs F103xE, check for the presence of the additional
> devices, like ADC3, FSMC, SDIO, TIM5, SPI2, UART4/5 etc.

I've wondered how MCU makers handle the *huge* proliferation of feature 
combinations.   The FPGA guys used to claim that was why they couldn't offer 
FPGAs with CPUs, the huge proliferation of part numbers (combos of FPGA 
size, memory size, CPU speed...) making all parts more expensive.  So how do 
the MCU guys do it?  Well, I guess that's how, they don't produce separate 
dies for each PN, they just test them for the features they are selling... 
just like the FPGA guys.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#26961

Den mandag den 26. juni 2017 kl. 16.47.01 UTC+2 skrev rickman:
> Uwe Bonnes wrote on 6/26/2017 8:09 AM:
> > kristoff <kristoff@skypro.be> wrote:
> >> Hi,
> >>
> >>
> >> Some time ago, I boght a cheap devboard from a  well known Chinese
> >> webshop with a STM32F103RCT6 chip on it.
> >>
> >> According to the datasheets, that chip has 48 KB of RAM and 256 KB of
> >> flashrom.
> >>
> >> However, when using the linux arm-gdb and the st-util and st-info, they
> >> say that the chip actually has 64 KB of RAM (so more then exptected).
> >>
> >>
> >> Using gdb (writing to memory and reading back from it), it does look at
> >> there is indeed 64 KB of RAM in the chip, ... but I do not find any
> >> reference to that chip with 64 KB of RAM.
> >>
> >>
> >> Anybody any idea what is going on here?
> >>
> >> The datasheet does mention this:
> >> 1. 64 KB RAM for 256 KB Flash are available on devices delivered in CSP
> >> packages only.
> >>
> >> but the "T6" (at the end of full name) indicates that it is a
> >> LQFP64-package, no WLCSP64. (and, indeed, it is a LQFP chip).
> >>
> >> Or does "CSP" mean something else? (Customer Special ???)
> >>
> >>
> >> 2/ Or could it be that this chip was originally intended as a ..."RD" or
> >> "RE" chip (384 or 512 KB of flash, 64 KB of RAM) where that the
> >> post-production quality-check showed that the upper half of the flash is
> >> bad, ...  so instead of just trowing it away, it is sold as a "RC" chip
> >> (256 KB of flash)?
> >>
> >>
> >> 3/ Or is this a counterfeit?
> >>
> >>
> >> Did somebody already have simular experience?
> >> Any ideas?
> >
> > It is clear that ST produces much less chip variants than they sell. However
> > you don't know what you get beside that what is promised by the original
> > data sheets. Are add-ons
> > - still availabe on the next chip you buy?
> > - where add-ons tested bad during production?
> > - where add-ons tested at all?
> >
> > For a check F103xB vs F103xE, check for the presence of the additional
> > devices, like ADC3, FSMC, SDIO, TIM5, SPI2, UART4/5 etc.
> 
> I've wondered how MCU makers handle the *huge* proliferation of feature 
> combinations.   The FPGA guys used to claim that was why they couldn't offer 
> FPGAs with CPUs, the huge proliferation of part numbers (combos of FPGA 
> size, memory size, CPU speed...) making all parts more expensive.  So how do 
> the MCU guys do it?  Well, I guess that's how, they don't produce separate 
> dies for each PN, they just test them for the features they are selling... 
> just like the FPGA guys.
> 

many years ago I worked at place that was bitten by that, 
Someone had made an error and used a part of ram that was only there because 
the part were the same die as a bigger part. 

eventually volume got so big the manufacturer made a new smaller die, 
resulting in the code failing and production halting 



 

[toc] | [prev] | [next] | [standalone]

#26963

On Mon, 26 Jun 2017 10:46:59 -0400, rickman wrote:

> Uwe Bonnes wrote on 6/26/2017 8:09 AM:
>> kristoff <kristoff@skypro.be> wrote:
>>> Hi,
>>>
>>>
>>> Some time ago, I boght a cheap devboard from a  well known Chinese
>>> webshop with a STM32F103RCT6 chip on it.
>>>
>>> According to the datasheets, that chip has 48 KB of RAM and 256 KB of
>>> flashrom.
>>>
>>> However, when using the linux arm-gdb and the st-util and st-info,
>>> they say that the chip actually has 64 KB of RAM (so more then
>>> exptected).
>>>
>>>
>>> Using gdb (writing to memory and reading back from it), it does look
>>> at there is indeed 64 KB of RAM in the chip, ... but I do not find any
>>> reference to that chip with 64 KB of RAM.
>>>
>>>
>>> Anybody any idea what is going on here?
>>>
>>> The datasheet does mention this:
>>> 1. 64 KB RAM for 256 KB Flash are available on devices delivered in
>>> CSP packages only.
>>>
>>> but the "T6" (at the end of full name) indicates that it is a
>>> LQFP64-package, no WLCSP64. (and, indeed, it is a LQFP chip).
>>>
>>> Or does "CSP" mean something else? (Customer Special ???)
>>>
>>>
>>> 2/ Or could it be that this chip was originally intended as a ..."RD"
>>> or "RE" chip (384 or 512 KB of flash, 64 KB of RAM) where that the
>>> post-production quality-check showed that the upper half of the flash
>>> is bad, ...  so instead of just trowing it away, it is sold as a "RC"
>>> chip (256 KB of flash)?
>>>
>>>
>>> 3/ Or is this a counterfeit?
>>>
>>>
>>> Did somebody already have simular experience?
>>> Any ideas?
>>
>> It is clear that ST produces much less chip variants than they sell.
>> However you don't know what you get beside that what is promised by the
>> original data sheets. Are add-ons - still availabe on the next chip you
>> buy?
>> - where add-ons tested bad during production?
>> - where add-ons tested at all?
>>
>> For a check F103xB vs F103xE, check for the presence of the additional
>> devices, like ADC3, FSMC, SDIO, TIM5, SPI2, UART4/5 etc.
> 
> I've wondered how MCU makers handle the *huge* proliferation of feature
> combinations.   The FPGA guys used to claim that was why they couldn't
> offer FPGAs with CPUs, the huge proliferation of part numbers (combos of
> FPGA size, memory size, CPU speed...) making all parts more expensive. 
> So how do the MCU guys do it?  Well, I guess that's how, they don't
> produce separate dies for each PN, they just test them for the features
> they are selling... just like the FPGA guys.


As an example of what the FPGA guys do, Xilinx's Zynq 7 family has ten 
members.  I'm fairly sure there are only six unique dies though.  I base 
this on things like features, configuration bitstream size, DC specs, etc.

XC7Z007S & XC7Z010 are the same
XC7Z012S & XC7Z015 are the same
XC7Z014S & XC7Z020 are the same
XC7Z030
XC7Z035 & XC7Z045 are the same
XC7Z100

The 'S' suffix parts have only one ARM core, which means one of the two 
ARM cores on the die has been disabled.  The parts already have 
(polysilicon?) efuses used for other purposes, so I assume they use a 
hidden set of fuses to disable features.
There would be no cost saving in removing an ARM core (as the die size 
would not change - it's a small area in the corner of the FPGA), but 
there could be a cost saving in not testing one of them.

The user guide says the FPGA fabric size is different, too (e.g. the '007 
supposedly has about 70% of the fabric of the '010) but this is merely a 
software limitation - if it knows the target device is a '007, it won't 
allow it to achieve more than 70% utilisation.

Regards,
Allan

[toc] | [prev] | [next] | [standalone]

#26965

Allan Herriman wrote on 6/27/2017 7:23 AM:
> On Mon, 26 Jun 2017 10:46:59 -0400, rickman wrote:
>
>> Uwe Bonnes wrote on 6/26/2017 8:09 AM:
>>> kristoff <kristoff@skypro.be> wrote:
>>>> Hi,
>>>>
>>>>
>>>> Some time ago, I boght a cheap devboard from a  well known Chinese
>>>> webshop with a STM32F103RCT6 chip on it.
>>>>
>>>> According to the datasheets, that chip has 48 KB of RAM and 256 KB of
>>>> flashrom.
>>>>
>>>> However, when using the linux arm-gdb and the st-util and st-info,
>>>> they say that the chip actually has 64 KB of RAM (so more then
>>>> exptected).
>>>>
>>>>
>>>> Using gdb (writing to memory and reading back from it), it does look
>>>> at there is indeed 64 KB of RAM in the chip, ... but I do not find any
>>>> reference to that chip with 64 KB of RAM.
>>>>
>>>>
>>>> Anybody any idea what is going on here?
>>>>
>>>> The datasheet does mention this:
>>>> 1. 64 KB RAM for 256 KB Flash are available on devices delivered in
>>>> CSP packages only.
>>>>
>>>> but the "T6" (at the end of full name) indicates that it is a
>>>> LQFP64-package, no WLCSP64. (and, indeed, it is a LQFP chip).
>>>>
>>>> Or does "CSP" mean something else? (Customer Special ???)
>>>>
>>>>
>>>> 2/ Or could it be that this chip was originally intended as a ..."RD"
>>>> or "RE" chip (384 or 512 KB of flash, 64 KB of RAM) where that the
>>>> post-production quality-check showed that the upper half of the flash
>>>> is bad, ...  so instead of just trowing it away, it is sold as a "RC"
>>>> chip (256 KB of flash)?
>>>>
>>>>
>>>> 3/ Or is this a counterfeit?
>>>>
>>>>
>>>> Did somebody already have simular experience?
>>>> Any ideas?
>>>
>>> It is clear that ST produces much less chip variants than they sell.
>>> However you don't know what you get beside that what is promised by the
>>> original data sheets. Are add-ons - still availabe on the next chip you
>>> buy?
>>> - where add-ons tested bad during production?
>>> - where add-ons tested at all?
>>>
>>> For a check F103xB vs F103xE, check for the presence of the additional
>>> devices, like ADC3, FSMC, SDIO, TIM5, SPI2, UART4/5 etc.
>>
>> I've wondered how MCU makers handle the *huge* proliferation of feature
>> combinations.   The FPGA guys used to claim that was why they couldn't
>> offer FPGAs with CPUs, the huge proliferation of part numbers (combos of
>> FPGA size, memory size, CPU speed...) making all parts more expensive.
>> So how do the MCU guys do it?  Well, I guess that's how, they don't
>> produce separate dies for each PN, they just test them for the features
>> they are selling... just like the FPGA guys.
>
>
> As an example of what the FPGA guys do, Xilinx's Zynq 7 family has ten
> members.  I'm fairly sure there are only six unique dies though.  I base
> this on things like features, configuration bitstream size, DC specs, etc.
>
> XC7Z007S & XC7Z010 are the same
> XC7Z012S & XC7Z015 are the same
> XC7Z014S & XC7Z020 are the same
> XC7Z030
> XC7Z035 & XC7Z045 are the same
> XC7Z100
>
> The 'S' suffix parts have only one ARM core, which means one of the two
> ARM cores on the die has been disabled.  The parts already have
> (polysilicon?) efuses used for other purposes, so I assume they use a
> hidden set of fuses to disable features.
> There would be no cost saving in removing an ARM core (as the die size
> would not change - it's a small area in the corner of the FPGA), but
> there could be a cost saving in not testing one of them.
>
> The user guide says the FPGA fabric size is different, too (e.g. the '007
> supposedly has about 70% of the fabric of the '010) but this is merely a
> software limitation - if it knows the target device is a '007, it won't
> allow it to achieve more than 70% utilisation.

Certainly the smaller number of chip designs is an advantage when it costs 
millions of dollars to produce a new chip.  The costs the Xilinx guy was 
talking about was mostly the cost of dealing with a large proliferation of 
part numbers which is not addressed by using the same die for multiple 
device part numbers.

Part of the reason I think they have starting including CPUs on FPGAs today 
is that the CPUs are higher end types like the ones used in cell phones 
rather than lower end devices like common MCUs.  With MCUs you expect the 
memory to be on die or at lease in the package.  So that alone is a two or 
three or even four factor for part numbers.  The higher end CPUs are 
typically used with external memory relieving the FPGA maker of dealing with 
a range of memory sizes.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#26978

Hi Kristoff,

yes, this is known: https://github.com/jeelabs/embello/issues/53

Sometimes they come with more memory, and the additional memory should be fine,
at least in the cases I know of.

Same holds true for Lattice FPGAs:

iCE40 HX1K and HX8K are the dies, the HX4K is just an error free HX8K die within
a smaller package. Using Icestorm/Yosys/Arachne, you get the full HX8K capabilities.

Matthias

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web