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.
stm32f103rct6 with more ram then expected
Started by ●June 25, 2017
Reply by ●June 26, 20172017-06-26
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.
Reply by ●June 26, 20172017-06-26
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 ---------
Reply by ●June 26, 20172017-06-26
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
Reply by ●June 26, 20172017-06-26
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
Reply by ●June 27, 20172017-06-27
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
Reply by ●June 27, 20172017-06-27
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
Reply by ●June 30, 20172017-06-30
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
