1. What actually changes between RBT6, RCT6 and RET6?

All three parts are STM32F103 performance-line microcontrollers built around the same 72 MHz Arm Cortex-M3 core, the same peripheral set, and the same LQFP64 package with a 10 × 10 × 1.4 mm body. The letter after "F103" plus the number encode flash size: RBT6 ships with 128 Kbytes of flash and 20 Kbytes of SRAM, RCT6 ships with 256 Kbytes of flash and 48 Kbytes of SRAM, and RET6 ships with 512 Kbytes of flash and up to 64 Kbytes of SRAM. Nothing about the silicon changes the pin count, the pin assignment or the core peripherals; only the amount of memory on the die changes.

That combination, identical footprint plus more memory, is what makes this a true "capacity upgrade" case rather than a cross-vendor substitution. There is no respin of the board, no new land pattern, and no change to the SWD or JTAG debug header. The work that remains is entirely in firmware: confirming that nothing in the build, the linker script or the flash driver assumed the smaller part's geometry.

ST's own high-density datasheet (DS5792, covering the 256 to 512 Kbyte parts) and the medium-density datasheet both reference the same performance-line family description, and the STM32F103x8/B commercial datasheet states the family is designed for full pin-to-pin, software and feature compatibility. That statement is about the family relationship, not a substitute for checking the specific memory map of the part being targeted.

2. Is the pinout really identical?

Mechanically, yes, for this specific trio. RBT6, RCT6 and RET6 all list an LQFP 64, 10 × 10 × 1.4 mm package option on ST's ordering information pages, with 51 general-purpose I/O pins in that configuration. The same part numbers are also offered in other packages (RBT6 adds a TFBGA64 option, for example), so the package suffix and the exact ordering code must be checked individually. A "same pin count" claim is not the same as a verified footprint match for the specific orderable part in use.

Before committing a board respin decision either way, pull the current datasheet device-information table for the exact orderable code being sourced. ST's catalogue, like most vendors', periodically adds or deprecates specific package options per part number, and the ordering code's suffix (the "T6" here, plus any trailing package or temperature letters) is what a distributor actually stocks against.

3. Why does ST call these different "density" classes?

ST's STM32F10xxx reference manual (RM0008) and flash programming manual (PM0075) divide the STM32F101/F102/F103 family into low-density (16 to 32 Kbytes of flash), medium-density (64 to 128 Kbytes), high-density (256 to 512 Kbytes) and XL-density classes. RBT6 falls in medium-density; RCT6 and RET6 fall in high-density. This is not a marketing label: the density class determines the internal flash array organization, which is the detail that affects firmware.

Specifically, PM0075 states that the main flash memory block is organized as 32 pages of 1 Kbyte for low-density devices, 128 pages of 1 Kbyte for medium-density devices, and 256 pages of 2 Kbytes for high-density devices. The erase granularity, the smallest block the flash controller can erase in one operation, is tied to density class, not to the part's pin-compatible family membership.

4. What is a flash erase page, and why does its size matter?

On-chip flash cannot be rewritten one byte at a time the way RAM can. To change previously programmed bits back from 0 to 1, the flash controller must erase an entire page, and only then can new data be programmed into it. The page is therefore the atomic unit for any in-field update, whether that is a bootloader writing a new application image, a settings block being rewritten, or an over-the-air update staging a new firmware version.

A design built around RBT6 that erases flash in 1 Kbyte units, and stores two independent data blocks 1 Kbyte apart because that was a safe erase boundary on that part, is relying on a property of the medium-density flash array. Moving the same firmware to RCT6 without re-checking this means the erase command now clears 2 Kbytes at a time: the second data block, which the firmware still believes is isolated, sits inside the page that just got erased along with the first.

This failure mode does not look like a flash problem at first. It presents as settings that silently revert, an application partition that corrupts after an update, or an OTA image that boots once and then fails after the next write cycle. Because the symptom shows up during use rather than during flashing, it is easy to spend time looking at timing, power or interrupts before the actual cause, a page-size assumption, is checked.

5. Where does a hardcoded page size break a bootloader?

Three places in a typical firmware build encode an assumption about erase page size, and all three need review when moving between density classes:

1. The linker script's flash region definitions. A custom bootloader/application split often aligns regions to the erase page boundary used during development. If that boundary was chosen as 1 Kbyte on RBT6, the regions are still valid addresses on RCT6, but they no longer align to that part's actual 2 Kbyte erase boundary, which can leave partial pages straddling the application and bootloader regions during an update.
2. The flash driver's erase routine. ST's HAL and standard peripheral library both expose flash erase functions that take a page address, but the page size constant used to calculate how many erase calls are needed, or where the next page starts, is sometimes defined locally in application code rather than read from the part's own memory organization.
3. Any OTA or settings-storage library pulled in from outside the HAL. Third-party flash-based storage libraries frequently default to a configurable page size that must be set per target; silently leaving a 1 Kbyte default in place while sourcing RCT6 silicon reproduces the same corruption risk without any linker-level symptom.

The practical fix in all three cases is the same: locate every reference to the erase page size in the build, confirm it is read from (or explicitly matched to) the target part's actual organization in the current datasheet and PM0075, and re-run a full erase/program/verify cycle across a representative range of addresses, not just the addresses used during the original bring-up.

6. What changes besides flash?

SRAM moves in the same direction as flash but by a larger relative amount: 20 KB on RBT6 versus 48 KB on RCT6 is more than double, and 64 KB on RET6 is more than triple. A design that was tight on RAM on the smaller part gains meaningful headroom for larger buffers, a bigger heap, or additional RTOS tasks. A design that budgeted RAM precisely for RBT6's 20 KB should re-check that any fixed-size static allocations, stack sizes and linker symbols still make sense; moving to a part with more RAM available does not require using all of it, but any code that computed addresses relative to a fixed, smaller RAM size should be reviewed the same way the flash assumptions are.

The core, the clock tree, the GPIO structure and the communication peripherals (I2C, SPI, I2S, USART, USB, CAN) do not change between these three parts. The electrical specifications, operating voltage range and timing for those peripherals are set by the performance-line family design, not by the memory density, so a peripheral-level qualification does not need to be repeated purely because of the flash upgrade.

7. What must be verified before upgrading the part?

A density upgrade on this family is safe once five items have been checked against the specific target part's current datasheet and the flash programming manual, not assumed from the pin compatibility alone.

1. Orderable package code. Confirm the exact LQFP64 ordering code for the target density is current and available from the intended source; package options can differ across the density range for a given vendor.
2. Flash erase page size. Confirm whether the bootloader, OTA library or settings storage assumes a fixed page size, and update that constant to match the target part's density class (1 Kbyte for medium-density, 2 Kbyte for high-density).
3. Linker script region alignment. Re-check that application and bootloader regions align to the new erase page boundary, not just to a valid flash address.
4. RAM-relative addressing. Review any code that computed buffer locations or stack limits relative to a specific SRAM size rather than using the toolchain's linker symbols.
5. Full erase/program/verify test. Run the complete update path, including a simulated interrupted write if the application supports fail-safe updates, before qualifying the new part for production.

Document which specific part (RBT6, RCT6 or RET6) a given firmware build targets, and avoid shipping a single binary across density classes without an explicit page-size check inside the flash driver itself.

8. Are there pin-compatible alternatives outside the ST family?

Second-source STM32F103-compatible parts exist from other vendors and are generally sold against the same LQFP64 pin arrangement for equivalent densities, following the same logic as the earlier STM32F103C8T6 cross-reference guide on this site. The caution is identical here: pin compatibility is a mechanical claim about the package, and it does not by itself establish an identical flash controller, an identical erase page size, or identical flash programming timing. Confirm the specific vendor's own programming manual for the erase page size and flash access cycle configuration before assuming a second-source part behaves like the ST original at the firmware level.

9. What belongs in the sourcing request?

When sourcing a density upgrade, a request that names the exact target part gets a usable answer faster than one that only states a flash size. A supplier can confirm stock against the full orderable code, but a bare "256 KB STM32F103" does not specify the package, the temperature grade or the exact suffix.

Useful fields are the full orderable part number (including the package and temperature suffix), the quantity per build with annual volume, whether the design is moving from a specific smaller part (state the exact source part number), and whether the current firmware's flash erase routine has already been updated for the target density class. Where only the target density matters and either RCT6 or RET6 would work, say so; where a specific RAM size is required, state it rather than requesting "the biggest available."

For current availability on this family, search the STM32F103RCT6 listing, the STM32F103RBT6 listing and the STM32F103RET6 listing on chip-seek.com. These pages return live catalogue results rather than a stock claim; confirm quantity and date code against the quotation. The earlier STM32F103C8T6 cross-reference guide and STM32F103CBT6 guide cover the smaller LQFP48 members of the same family for projects that have not committed to the 64-pin footprint. A multi-line sourcing request can be submitted through the BOM and RFQ form.

Frequently asked questions

Can I use the same firmware binary on RBT6 and RCT6 without changes? Only if the firmware already reads flash geometry from the part's own definitions rather than hardcoding a page size. Most bring-up code written for a single target does hardcode it, so review the flash driver and linker script before reusing the binary.

Is the LQFP64 footprint actually identical across RBT6, RCT6 and RET6? Yes, for the LQFP 64, 10 × 10 × 1.4 mm package listed in each part's current ST ordering information. Confirm the specific orderable code for the target part, since package availability can change over a product's lifecycle.

What is the difference between medium-density and high-density in ST's terminology? It is a flash capacity class defined in ST's RM0008 reference manual: medium-density covers 64 to 128 Kbytes of flash, high-density covers 256 to 512 Kbytes. The class determines the flash array's internal organization, including the erase page size.

Does more SRAM require any firmware changes by itself? No. Unused RAM does not need to be used. The review is only needed for code that computed addresses or limits relative to the smaller part's fixed RAM size rather than using linker-provided symbols.

Do the ADC, timers, USB and CAN peripherals change between these three parts? No. The core peripheral set, electrical specifications and clock tree are set by the performance-line family design and do not change with memory density on this trio.

What happens if the erase page size is wrong in production firmware? Adjacent data within the same physical erase page can be unintentionally cleared when one region is erased, which typically presents as corrupted settings or a failed update rather than an immediate programming error.

Sources

• Cover photograph: Raimond Spekking, STMicroelectronics STM32F107RBT6 LQFP64 package photograph, CC BY-SA 4.0. Chip-seek cropped and arranged the cover under the same licence. The photograph shows the same LQFP64 package family and is not a photograph of an STM32F103RBT6, RCT6 or RET6 specifically, nor inventory evidence.
• ST STM32F103RB product page: flash size, SRAM, package options and ordering information.
• ST STM32F103RC/RD/RE datasheet, DS5792: high-density performance-line family description, flash and SRAM capacity, package information.
• ST STM32F103RE product page: flash size, SRAM and LQFP64 package confirmation.
• ST PM0075, STM32F10xxx Flash memory microcontrollers programming manual: flash module organization, page size by density class, low/medium/high-density definitions.
• ST STM32F103x8/B datasheet: performance-line family pin-to-pin, software and feature compatibility statement.

Need help sourcing the right density?

Working with the 48-pin family instead? The STM32F103C8T6 cross-reference guide covers the smaller LQFP48 package.