1. Why the CBT6 exists

The F103 family was built around a single die that could be configured with different flash densities. That is why the C6T6, C8T6 and CBT6 share a package, a pinout and a peripheral set: the differences are memory, not architecture.

For a designer, that is a gift. A board qualified for the C8T6 accepts the CBT6 without a layout change, and the firmware compiles with no driver changes. The only question is whether the memory map still holds.

For a buyer, it is a pricing and availability decision: the 128 KB part costs slightly more, but it removes the risk of a second storage redesign later.

2. The three memory variants

Note what does not change: RAM stays at 20 KB across the C8T6 and CBT6. Doubling the flash does not give the application more stack, heap or buffers. If the limit is RAM, the answer is a different family, not a bigger flash part.

The 32 KB C6T6 is the opposite trade: cheapest, but only viable for a small fixed image. Moving from 32 KB to 128 KB is a fourfold increase and usually resolves the constraint permanently.

What stays identical

Pinout, package, peripheral set, clock tree and debug interface are unchanged across the C6T6, C8T6 and CBT6. The same board, the same crystal, the same SWD header and the same USB circuit work with all three.

That is why the upgrade is often described as "free". The engineering effort is real but bounded: update the linker script, review the partition table, re-run the acceptance tests. No schematic change, no re-layout, no new drivers.

The only peripheral difference worth checking is the flash controller's page geometry, because the page size determines how the emulated EEPROM and the bootloader erase.

In practice the C8T6 and CBT6 are often interchangeable at the distributor level, and the choice comes down to which is available at the time of the build. That flexibility is itself an argument for designing the partition table around 128 KB, so either part can be used without a firmware change.

3. When 64 KB stops being enough

Firmware grows in predictable steps. A project that fit comfortably at 40 KB can cross 64 KB when one of five things happens.

A network stack is added. Even a compact TCP/IP stack with TLS consumes tens of kilobytes.

A display and font set is added. A few Chinese or Japanese glyph sets can exceed the entire application budget.

OTA staging is added. Dual-bank updates need room for a second image, or at least a compressed one.

Logging or configuration storage moves into flash. Emulated EEPROM pages reduce the usable application space.

Debug symbols or a bootloader grow. The bootloader occupies the bottom of flash whether or not anyone measures it.

What actually consumes the extra 64 KB

It helps to see where the space goes before deciding. A typical connected application on this class of MCU breaks down roughly like this: bootloader 16 KB, application code 30–50 KB, a compact TCP/IP stack 12–20 KB, TLS 15–25 KB, a file system and configuration 4–8 KB, and an OTA staging area equal to the image size.

Add those numbers and the ceiling arrives quickly. A 45 KB application with TLS and dual-bank staging needs more than 128 KB before any logging or font data. That is why the 64 KB part feels adequate on the bench and then runs out during integration.

The same arithmetic explains why "just enable TLS" is a storage decision as much as a security one. Cipher suites and certificate stores are not free.

4. The migration work

The most common mistake is changing the linker script and forgetting the partition table. The board then programs correctly but the OTA update writes past the staging region, or the bootloader refuses an image it considers too large.

Endurance and emulated EEPROM

Flash is not EEPROM. The F103 flash is rated for a limited number of erase cycles, typically in the ten-thousand range per page. A configuration block written on every power-down will exhaust a page long before the product's service life ends.

Emulated EEPROM solves this with two techniques. First, it writes to a fresh location instead of overwriting, so wear spreads across a page or a block. Second, it keeps a small index in RAM and rewrites the index only when the page is full.

Both techniques consume flash proportional to the number of variables and the wear-leveling depth. On a 64 KB part, this can be a meaningful fraction of the budget; on the CBT6, the extra space makes a deeper wear-leveling scheme affordable.

If the product logs data continuously, consider an external FRAM or a small SPI flash rather than wearing the MCU's internal flash. The cost is modest and the reliability gain is large.

Clock, wait states and perceived performance

A larger flash does not make the MCU faster, but it can change the number of flash wait states the code runs with. At 72 MHz the F103 needs wait states on both densities; the difference appears when code is placed at different addresses or when the prefetch buffer behaves differently.

For most applications this is invisible. For cycle-counted loops, bit-banged interfaces and tight control loops it can matter, and the acceptance test should include the timing-sensitive paths rather than only functional checks.

If the design runs below 48 MHz, wait states are usually zero and the difference disappears entirely. That is one reason many industrial designs deliberately run slower than the maximum.

5. Flash size at runtime

The F103 reports its flash size in a register that firmware can read. That is useful for a platform that ships with either 64 KB or 128 KB parts, and it is also a trap: code that hardcodes page counts or sector addresses will misbehave on a different density.

If the product may ship with both variants, read the size at boot and configure the storage layer from it. If it ships with only one, assert the expected size in manufacturing test so a wrong reel is caught before assembly.

OTA design options

Four patterns are common, and their flash cost differs sharply.

Dual bank. Two full image slots plus a bootloader. Safe and simple, but needs twice the image size. On 128 KB, a 40 KB image with dual-bank staging consumes 80 KB before data.

Compressed staging. The downloaded image is stored compressed and expanded in place at boot. Saves space, adds a decompression step and a failure mode if the decompressor is interrupted.

External staging. The image is stored in an external SPI flash, and the MCU copies it internally. Adds a component but removes the internal space constraint entirely.

No staging. The device downloads and writes directly, typically with a recovery bootloader. Cheapest in flash, riskiest in the field.

Whichever pattern is chosen, the partition table must be fixed before the firmware is written. Changing it later invalidates every device in the field.

Firmware compatibility checks

Four checks catch most migration problems before they reach the field.

Device ID. The firmware's startup code may branch on the ID; add the new value explicitly.

Flash size register. Assert the expected value in manufacturing test, so a wrong-density reel is rejected at programming time.

Vector table offset. If the bootloader relocates the application, confirm the offset matches the new partition table.

EEPROM emulation page count. The number of pages reserved for configuration must match the new layout, or the last page will overlap the application.

6. Second sources at 128 KB

The same rules from the 64 KB article apply: pin compatibility is mechanical, and the firmware must be validated. With a larger flash, one extra item appears — the flash programming algorithm and the erase granularity can differ, which affects both production time and the OTA design.

Also verify the recovery path. If the bootloader supports DFU over USB or UART, test a recovery from a corrupted application image on the new density, because the DFU descriptor often encodes the maximum image size.

Debug access is unchanged, but the option bytes are worth a check: read-out protection, watchdog behaviour and boot pin configuration are stored in flash and can differ in default state between lots. Confirm them on the fixture rather than on the bench.

Production programming and traceability

Switching density changes the programming image and, often, the fixture. Three items should be verified on the line.

Image size and checksum. The programmer must accept the larger image, and the checksum stored in the bootloader area must match.

Read-back verification. A full verify after programming catches a wrong-density reel immediately, instead of at first boot.

Unique ID logging. The 96-bit unique ID ties a device to a production record. Logging it makes field returns traceable and helps identify a bad lot.

7. Test plan

When 128 KB is still not enough

If the projected image is above about 100 KB, the next step is not another F103 variant — it is a different family. The F103's Cortex-M3 at 72 MHz and 20 KB of RAM becomes the constraint before the flash does.

Options include the 256 KB class in the same family, a Cortex-M4 part with more RAM and a floating-point unit, or an external QSPI flash with execute-in-place support. Each is a platform decision with its own certification and firmware cost.

The practical rule: choose the density that covers the next two years of features, not the current image size. Requalifying the same board twice is more expensive than buying a slightly larger part from the start.

A five-year product story

Consider a controller designed in 2021 with a 40 KB image on the C8T6. By 2023 the image reached 58 KB after adding a web interface. By 2024, TLS pushed it past 64 KB, and the team compressed fonts to fit.

In 2025 the OTA staging area no longer fit. The fix at that point was a board revision, a new partition layout and a field migration — all avoidable if the design had started on the CBT6 for a few cents more.

That is the argument for headroom: not that the extra flash will be used immediately, but that the cost of running out is measured in re-spins rather than in cents.

8. Cost and planning

The price difference between the C8T6 and CBT6 is small. The decision is not about unit cost; it is about whether the extra 64 KB removes a future redesign.

Three signals argue for the CBT6: the current image is above 45 KB, the roadmap includes a network stack or a display, or the product has a multi-year life. Two signals argue to stay at 64 KB: the image is stable and small, and the volume is high enough that cents matter.

If the image is already near 100 KB, skip to the 256 KB class. Qualifying a 128 KB part and then moving again in a year is the most expensive path.

A decision rule for new designs

Write down three numbers before choosing: current image size, expected size in two years, and whether OTA is required. If the answer to OTA is yes, add the image size again. If the projected total is above 90 KB, start at 128 KB or higher.

For a fixed-function product with no connectivity and no OTA, 64 KB is usually plenty and the C8T6 remains the cheaper choice. The mistake is assuming a product will stay fixed for five years.

9. FAQ

Is CBT6 a drop-in for C8T6?

Physically and functionally yes. The firmware needs the linker script and partition table updated for the larger flash.

Does RAM increase?

No. Both parts have 20 KB. If RAM is the constraint, a bigger flash part will not help.

Can I move back to C8T6 later?

Only if the image fits in 64 KB. Plan the partition table so a downgrade is possible without a code change.

Do second sources have the same flash size register?

Usually a compatible register exists, but the value and the granularity can differ. Read the datasheet for the exact part.

What is the most common migration bug?

Updating the linker script but not the OTA partition table, which produces updates that write outside the staging area.

Should I order CBT6 for a new design?

If the image is under 32 KB and stable, C8T6 is fine. If there is any chance of growth — a web interface, TLS, logging or OTA — start at 128 KB and avoid a second design cycle.

Supply notes

Availability at this density is better than at 32 KB, because more designs use it. Keep one approved second source and confirm that its flash programming algorithm matches your production fixture; the image is the same, but the tooling may not be. Check it before you place the order.

10. Sources

• ST STM32F103CB product page: st.com
• GigaDevice GD32F103 documentation: gigadevice.com