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

Groups > comp.arch.embedded > #26965

Re: stm32f103rct6 with more ram then expected

Show all headers | View raw

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

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web