1. Varför CBT6 finns

F103-familjen byggdes kring en enda die som kunde konfigureras med olika flashdensiteter. Det är därför C6T6, C8T6 och CBT6 delar kapsel, pinout och periferiuppsättning: skillnaderna är minne, inte arkitektur.

För en konstruktör är det en gåva. Ett kort kvalificerat för C8T6 accepterar CBT6 utan layoutändring, och firmware kompilerar utan drivrutinsändringar. Den enda frågan är om minneskartan fortfarande håller.

För en inköpare är det ett beslut om pris och tillgänglighet: 128 KB-delen kostar något mer, men det eliminerar risken för en senare omdesign av lagringen.

2. De tre minnesvarianterna

Notera vad som inte förändras: RAM ligger kvar på 20 KB för både C8T6 och CBT6. Att dubbla flashminnet ger inte applikationen mer stack, heap eller buffertar. Om begränsningen är RAM är svaret en annan familj, inte en större flash-krets.

32 KB C6T6 är den omvända avvägningen: billigast, men endast användbar för en liten fast programbild. Att gå från 32 KB till 128 KB är en fyrdubbling och löser vanligtvis begränsningen permanent.

Vad förblir identiskt

Pinout, kapsel, periferiuppsättning, klockträd och felsökningsgränssnitt är oförändrade mellan C6T6, C8T6 och CBT6. Samma kort, samma kristall, samma SWD-kontakt och samma USB-krets fungerar med alla tre.

Det är därför uppgraderingen ofta beskrivs som "gratis". Ingenjörsarbetet är verkligt men begränsat: uppdatera länkarskriptet, granska partitionstabellen, kör om acceptanstesterna. Ingen schemändring, ingen ny layout, inga nya drivrutiner.

Den enda periferiskillnaden värd att kontrollera är flash-kontrollerns sidgeometri, eftersom sidstorleken avgör hur den emulerade EEPROM:en och bootloadern raderar.

I praktiken är C8T6 och CBT6 ofta utbytbara hos distributören, och valet handlar om vilken som finns tillgänglig vid byggtillfället. Den flexibiliteten är i sig ett argument för att utforma partitionstabellen kring 128 KB, så att endera komponenten kan användas utan firmwareändring.

3. När 64 KB inte längre räcker

Firmware växer i förutsägbara steg. Ett projekt som fick plats bekvämt vid 40 KB kan passera 64 KB när en av fem saker inträffar.

En nätverksstack läggs till.Även en kompakt TCP/IP-stack med TLS förbrukar tiotals kilobyte.

En display och en uppsättning typsnitt läggs till.Några kinesiska eller japanska glyfuppsättningar kan överskrida hela applikationsbudgeten.

OTA-staging läggs till.Dubbelbanksuppdateringar behöver utrymme för en andra avbild, eller åtminstone en komprimerad sådan.

Loggning eller konfigurationslagring flyttas till flash.Emulerade EEPROM-sidor minskar det användbara applikationsutrymmet.

Debug-symboler eller en bootloader växer.Bootloadern upptar den nedre delen av flash oavsett om någon mäter det eller inte.

Vad som faktiskt förbrukar de extra 64 KB

Det hjälper att se var utrymmet tar vägen innan man bestämmer sig. En typisk ansluten applikation på den här klassen av MCU fördelar sig ungefär så här: bootloader 16 KB, applikationskod 30–50 KB, en kompakt TCP/IP-stack 12–20 KB, TLS 15–25 KB, ett filsystem och konfiguration 4–8 KB samt ett OTA-stagingområde lika stort som avbildningen.

Lägger man ihop de siffrorna nås taket snabbt. En applikation på 45 KB med TLS och dual-bank-staging behöver mer än 128 KB innan någon loggning eller teckensnittsdata finns med. Det är därför 64 KB-komponenten känns tillräcklig på bänken och sedan tar slut under integrationen.

Samma aritmetik förklarar varför "aktivera bara TLS" är ett lagringsbeslut i lika hög grad som ett säkerhetsbeslut. Chiffersviter och certifikatarkiv är inte gratis.

4. Migreringsarbetet

Det vanligaste misstaget är att ändra länkskriptet och glömma partitionstabellen. Kortet programmeras då korrekt, men OTA-uppdateringen skriver förbi stagingområdet, eller så vägrar bootloadern en avbild som den anser är för stor.

Uthållighet och emulerad EEPROM

Flash är inte EEPROM. F103-flashen är specificerad för ett begränsat antal raderingscykler, vanligtvis i storleksordningen tiotusen per sida. Ett konfigurationsblock som skrivs vid varje strömavslag kommer att slita ut en sida långt innan produktens livslängd är slut.

Emulerad EEPROM löser detta med två tekniker. För det första skriver den till en ny plats i stället för att skriva över, så slitaget sprids över en sida eller ett block. För det andra håller den ett litet index i RAM och skriver bara om indexet när sidan är full.

Båda teknikerna förbrukar flash proportionellt mot antalet variabler och slitagespridningsdjupet. På en 64 KB-krets kan detta vara en betydande del av budgeten; på CBT6 gör det extra utrymmet ett djupare slitagespridningsschema överkomligt.

Om produkten loggar data kontinuerligt bör du överväga en extern FRAM eller ett litet SPI-flash i stället för att slita på MCU:ns interna flash. Kostnaden är måttlig och tillförlitlighetsvinsten är stor.

Klocka, väntetillstånd och upplevd prestanda

Ett större flashminne gör inte MCU:n snabbare, men det kan ändra antalet flash-väntetillstånd som koden körs med. Vid 72 MHz behöver F103 väntetillstånd på båda densiteterna; skillnaden uppträder när kod placeras på olika adresser eller när förhämtningsbufferten beter sig olika.

För de flesta applikationer är detta osynligt. För cykelräknade loopar, bit-bangade gränssnitt och snäva reglerloopar kan det spela roll, och acceptanstestet bör omfatta de tidskänsliga kodvägarna i stället för endast funktionella kontroller.

Om konstruktionen körs under 48 MHz är väntetillstånden vanligtvis noll och skillnaden försvinner helt. Det är en anledning till att många industriella konstruktioner medvetet körs långsammare än maximalt.

5. Flashstorlek vid körtid

F103 rapporterar sin flashstorlek i ett register som firmware kan läsa. Det är användbart för en plattform som levereras med antingen 64 KB- eller 128 KB-varianter, och det är också en fälla: kod som hårdkodar sidantal eller sektoradresser kommer att bete sig felaktigt vid en annan densitet.

Om produkten kan levereras med båda varianterna, läs storleken vid uppstart och konfigurera lagringslagret utifrån den. Om den levereras med endast en variant, verifiera den förväntade storleken i tillverkningstestet så att en felaktig rulle upptäcks före montering.

OTA-designalternativ

Fyra mönster är vanliga, och deras flash-kostnad skiljer sig kraftigt.

Dubbel bank.Två fullständiga bildplatser plus en bootloader. Säkert och enkelt, men kräver dubbel bildstorlek. På 128 KB förbrukar en 40 KB bild med dual-bank-staging 80 KB före data.

Komprimerad staging.Den nedladdade avbildningen lagras komprimerad och packas upp på plats vid uppstart. Det sparar utrymme, men lägger till ett uppackningssteg och ett felscenario om uppackaren avbryts.

Extern mellanlagring.Avbildningen lagras i ett externt SPI-flashminne och MCU:n kopierar den internt. Det lägger till en komponent men tar helt bort begränsningen i internt utrymme.

Ingen mellanlagring.Enheten laddar ner och skriver direkt, vanligtvis med en recovery-bootloader. Billigast vad gäller flashminne, riskabelast i fält.

Vilket mönster som än väljs måste partitionstabellen vara fastställd innan firmware skrivs. Att ändra den senare gör varje enhet i fält obrukbar.

Kontroller av firmwarekompatibilitet

Fyra kontroller fångar de flesta migreringsproblem innan de når ut i fält.

Enhets-ID.Firmwarens startkod kan förgrena sig beroende på ID:t; lägg till det nya värdet explicit.

Flashstorleksregister.Verifiera det förväntade värdet i produktionstestet, så att en rulle med fel densitet avvisas vid programmeringen.

Offset för vektortabellen.Om bootloadern flyttar applikationen, bekräfta att offseten matchar den nya partitionstabellen.

Antal sidor för EEPROM-emulering.Antalet sidor som reserverats för konfiguration måste matcha den nya layouten, annars kommer den sista sidan att överlappa applikationen.

6. Sekundärkällor vid 128 KB

Samma regler från artikeln om 64 KB gäller: pinkompatibilitet är mekanisk, och firmware måste valideras. Med ett större flashminne tillkommer en extra punkt — flashprogrammeringsalgoritmen och raderingsgranulariteten kan skilja sig, vilket påverkar både produktionstiden och OTA-designen.

Verifiera även återställningsvägen. Om bootloadern stöder DFU över USB eller UART, testa en återställning från en korrupt applikationsavbildning på den nya densiteten, eftersom DFU-deskriptorn ofta kodar den maximala avbildningsstorleken.

Debugåtkomst är oförändrad, men option bytes är värda en kontroll: läsutskydd, watchdogbeteende och bootpinkonfiguration lagras i flash och kan skilja sig i standardtillstånd mellan batchar. Bekräfta dem på fixturen snarare än på bänken.

Produktionsprogrammering och spårbarhet

Byte av densitet ändrar programmeringsavbildningen och ofta fixturen. Tre punkter bör verifieras i produktionslinjen.

Bildstorlek och kontrollsumma.Programmeraren måste acceptera den större avbilden, och kontrollsumman som lagras i bootloaderområdet måste stämma.

Verifiering genom återläsning.En fullständig verifiering efter programmering fångar omedelbart en rulle med fel densitet, i stället för vid första uppstart.

Loggning av unikt ID.Det 96-bitars unika ID:t knyter en enhet till en produktionspost. Att logga det gör returer från fältet spårbara och hjälper till att identifiera ett dåligt parti.

7. Testplan

När 128 KB fortfarande inte räcker

Om den beräknade bildstorleken är över cirka 100 KB är nästa steg inte en annan F103-variant — det är en annan familj. F103:ans Cortex-M3 på 72 MHz och 20 KB RAM blir begränsningen innan flashminnet gör det.

Alternativen omfattar 256 KB-klassen i samma familj, en Cortex-M4-krets med mer RAM och en flyttalsenhet, eller ett externt QSPI-flash med stöd för execute-in-place. Var och en är ett plattformsbeslut med sina egna kostnader för certifiering och firmware.

Den praktiska regeln: välj den densitet som täcker funktionerna för de kommande två åren, inte den aktuella firmwarebildens storlek. Att rekvalificera samma kort två gånger är dyrare än att köpa en något större krets från början.

En femårig produkthistoria

Tänk dig en styrenhet som konstruerades 2021 med en 40 KB firmwarebild på C8T6. 2023 hade firmwarebilden nått 58 KB efter att ett webbgränssnitt lagts till. 2024 tryckte TLS den över 64 KB, och teamet komprimerade typsnitt för att få plats.

2025 fick OTA-stagingområdet inte längre plats. Åtgärden då var en kortrevision, en ny partitionslayout och en fältmigrering – allt undvikbart om konstruktionen hade börjat på CBT6 för några cent mer.

Det är argumentet för marginal: inte att det extra flashminnet kommer att användas omedelbart, utan att kostnaden för att få slut på det mäts i re-spins snarare än i cent.

8. Kostnad och planering

Prisdifferensen mellan C8T6 och CBT6 är liten. Beslutet handlar inte om styckkostnad; det handlar om huruvida de extra 64 KB tar bort behovet av en framtida omdesign.

Tre signaler talar för CBT6: den aktuella programbilden är över 45 KB, färdplanen omfattar en nätverksstack eller en display, eller så har produkten en livslängd på flera år. Två signaler talar för att stanna vid 64 KB: programbilden är stabil och liten, och volymen är tillräckligt hög för att cent spelar roll.

Om programbilden redan ligger nära 100 KB, gå direkt till 256 KB-klassen. Att kvalificera en 128 KB-krets och sedan byta igen inom ett år är den dyraste vägen.

En beslutsregel för nya konstruktioner

Skriv ned tre siffror innan du väljer: aktuell programbildsstorlek, förväntad storlek om två år och huruvida OTA krävs. Om svaret på OTA är ja, lägg till programbildsstorleken igen. Om den beräknade totalen är över 90 KB, börja på 128 KB eller högre.

För en produkt med fast funktion utan anslutning och utan OTA är 64 KB vanligtvis tillräckligt och C8T6 förblir det billigare valet. Misstaget är att anta att en produkt kommer att förbli oförändrad i fem år.

9. Vanliga frågor

Är CBT6 en direkt ersättare för C8T6?

Fysiskt och funktionellt ja. Firmware behöver länkskriptet och partitionstabellen uppdaterade för den större flashen.

Ökar RAM?

Nej. Båda kretsarna har 20 KB. Om RAM är begränsningen hjälper en större flashkrets inte.

Kan jag gå tillbaka till C8T6 senare?

Endast om avbildningen får plats i 64 KB. Planera partitionstabellen så att en nedgradering är möjlig utan kodändring.

Har alternativa källor samma register för flashstorlek?

Vanligtvis finns ett kompatibelt register, men värdet och granulariteten kan skilja sig. Läs databladet för den specifika komponenten.

Vad är det vanligaste migreringsfelet?

Att uppdatera länkskriptet men inte OTA-partitionstabellen, vilket ger uppdateringar som skriver utanför stagingområdet.

Ska jag beställa CBT6 för en ny design?

Om avbildningen är under 32 KB och stabil fungerar C8T6. Om det finns minsta risk för tillväxt – ett webbgränssnitt, TLS, loggning eller OTA – börja på 128 KB och undvik en andra designcykel.

Leveransanteckningar

Tillgången vid denna densitet är bättre än vid 32 KB, eftersom fler konstruktioner använder den. Ha en godkänd andra leverantörskälla och bekräfta att dess flashprogrammeringsalgoritm matchar din produktionsfixtur; avbildningen är densamma, men verktygen kanske inte är det. Kontrollera det innan du lägger beställningen.

10. Källor

• ST STM32F103CB produktsida:st.com
• GigaDevice GD32F103 dokumentation:gigadevice.com