1. Hvorfor CBT6 finnes

F103-familien ble bygget rundt en enkelt die som kunne konfigureres med ulike flashdensiteter. Det er derfor C6T6, C8T6 og CBT6 deler kapsel, pinneoppsett og periferisett: forskjellene er minne, ikke arkitektur.

For en konstruktør er det en gave. Et kort kvalifisert for C8T6 godtar CBT6 uten layoutendring, og fastvaren kompilerer uten driverendringer. Det eneste spørsmålet er om minnekartet fortsatt holder.

For en innkjøper er det en pris- og tilgjengelighetsbeslutning: 128 KB-delen koster litt mer, men den fjerner risikoen for en ekstra lagringsredesign senere.

2. De tre minnevariantene

Legg merke til hva som ikke endres: RAM forblir på 20 KB på tvers av C8T6 og CBT6. Å doble flash gir ikke applikasjonen mer stack, heap eller buffere. Hvis begrensningen er RAM, er svaret en annen familie, ikke en komponent med større flash.

32 KB C6T6 er den motsatte avveiningen: billigst, men bare brukbar for et lite fast programbilde. Å gå fra 32 KB til 128 KB er en firedobling og løser vanligvis begrensningen permanent.

Hva som forblir identisk

Pinout, kapsel, periferisett, klokketre og debug-grensesnitt er uendret på tvers av C6T6, C8T6 og CBT6. Det samme kortet, den samme krystallen, den samme SWD-headeren og den samme USB-kretsen fungerer med alle tre.

Det er derfor oppgraderingen ofte beskrives som «gratis». Ingeniørarbeidet er reelt, men begrenset: oppdater linker-skriptet, gjennomgå partisjonstabellen, kjør akseptansetestene på nytt. Ingen skjemaendring, ingen ny layout, ingen nye drivere.

Den eneste periferiforskjellen som er verdt å sjekke, er flash-kontrollerens sidegeometri, fordi sidestørrelsen bestemmer hvordan den emulerte EEPROM-en og bootloaderen sletter.

I praksis er C8T6 og CBT6 ofte utskiftbare hos distributøren, og valget avhenger av hvilken som er tilgjengelig på byggetidspunktet. Denne fleksibiliteten er i seg selv et argument for å utforme partisjonstabellen rundt 128 KB, slik at begge deler kan brukes uten en fastvareendring.

3. Når 64 KB ikke lenger er nok

Fastvare vokser i forutsigbare trinn. Et prosjekt som passet komfortabelt inn på 40 KB, kan krysse 64 KB når én av fem ting skjer.

En nettverksstakk legges til.Selv en kompakt TCP/IP-stakk med TLS bruker titalls kilobyte.

En skjerm og et fontsett legges til.Noen få kinesiske eller japanske glyfsett kan overstige hele applikasjonsbudsjettet.

OTA-klargjøring legges til.Dobbeltbanksoppdateringer trenger plass til et andre fastvarebilde, eller i det minste et komprimert ett.

Logging eller konfigurasjonslagring flyttes inn i flash.Emulerte EEPROM-sider reduserer den brukbare applikasjonsplassen.

Debug-symboler eller en bootloader vokser.Bootloaderen opptar bunnen av flash, uansett om noen måler det eller ikke.

Hva som faktisk bruker de ekstra 64 KB

Det hjelper å se hvor plassen går før man bestemmer seg. En typisk tilkoblet applikasjon på denne klassen MCU fordeler seg omtrent slik: bootloader 16 KB, applikasjonskode 30–50 KB, en kompakt TCP/IP-stakk 12–20 KB, TLS 15–25 KB, et filsystem og konfigurasjon 4–8 KB, og et OTA-stagingområde lik bildestørrelsen.

Legger man sammen disse tallene, nås taket raskt. En applikasjon på 45 KB med TLS og dual-bank-staging trenger mer enn 128 KB før noen logg- eller skriftdata. Derfor virker 64 KB-komponenten tilstrekkelig på benken, men går tom under integrasjonen.

Det samme regnestykket forklarer hvorfor «bare å aktivere TLS» er en lagringsbeslutning like mye som en sikkerhetsbeslutning. Chiffersuiter og sertifikatlagre er ikke gratis.

4. Migrasjonsarbeidet

Den vanligste feilen er å endre linker-skriptet og glemme partisjonstabellen. Kortet programmeres da riktig, men OTA-oppdateringen skriver forbi staging-området, eller bootloaderen avviser et avtrykk den anser som for stort.

Utholdenhet og emulert EEPROM

Flash er ikke EEPROM. F103-flashen er spesifisert for et begrenset antall slettesykluser, typisk i størrelsesorden titusen per side. En konfigurasjonsblokk som skrives ved hver nedstenging, vil slite ut en side lenge før produktets levetid er over.

Emulert EEPROM løser dette med to teknikker. For det første skrives det til en ny lokasjon i stedet for å overskrive, slik at slitasjen fordeles over en side eller en blokk. For det andre holdes en liten indeks i RAM, og indeksen skrives bare på nytt når siden er full.

Begge teknikkene bruker flash proporsjonalt med antall variabler og dybden på slitasjeutjevningen. På en 64 KB-komponent kan dette utgjøre en betydelig del av budsjettet; på CBT6 gjør den ekstra plassen et dypere slitasjeutjevningsskjema overkommelig.

Hvis produktet logger data kontinuerlig, bør du vurdere en ekstern FRAM eller en liten SPI-flash i stedet for å slite på den interne flashen til MCU-en. Kostnaden er moderat, og gevinsten i pålitelighet er stor.

Klokke, ventetilstander og opplevd ytelse

Større flash gjør ikke MCU-en raskere, men det kan endre antallet flash-ventetilstander koden kjører med. Ved 72 MHz trenger F103 ventetilstander på begge tettheter; forskjellen vises når kode plasseres på forskjellige adresser, eller når prefetch-bufferen oppfører seg annerledes.

For de fleste applikasjoner er dette usynlig. For syklustelte løkker, bit-bangede grensesnitt og stramme reguleringssløyfer kan det ha betydning, og aksepttesten bør omfatte de tidsfølsomme banene i stedet for bare funksjonelle kontroller.

Hvis designet kjører under 48 MHz, er ventetilstandene vanligvis null, og forskjellen forsvinner helt. Det er en grunn til at mange industrielle design bevisst kjører langsommere enn maksimum.

5. Flash-størrelse ved kjøretid

F103 rapporterer flashstørrelsen sin i et register som fastvaren kan lese. Det er nyttig for en plattform som leveres med enten 64 KB eller 128 KB deler, og det er også en felle: kode som hardkoder sideantall eller sektoradresser vil oppføre seg feil på en annen tetthet.

Hvis produktet kan leveres med begge varianter, les størrelsen ved oppstart og konfigurer lagringslaget ut fra den. Hvis det leveres med bare én, verifiser forventet størrelse i produksjonstesten slik at en feil komponentrull fanges opp før montering.

OTA-designalternativer

Fire mønstre er vanlige, og flash-kostnaden for dem varierer kraftig.

Dobbeltbank.To fulle bildeposisjoner pluss en oppstartsprogramvare. Trygt og enkelt, men krever dobbel bildestørrelse. På 128 KB bruker et 40 KB bilde med dobbeltbank-mellomlagring 80 KB før data.

Komprimert mellomlagring.Det nedlastede avbildningen lagres komprimert og utvides på stedet ved oppstart. Sparer plass, men legger til et dekomprimeringssteg og en feilmodus hvis dekomprimeringen avbrytes.

Ekstern staging.Avbildningen lagres i en ekstern SPI-flash, og MCU-en kopierer den internt. Legger til en komponent, men fjerner den interne plassbegrensningen helt.

Ingen staging.Enheten laster ned og skriver direkte, vanligvis med en recovery-bootloader. Gir lavest flashforbruk, men er mest risikabelt i felt.

Uansett hvilket mønster som velges, må partisjonstabellen være fastsatt før fastvaren skrives. Å endre den senere ugyldiggjør alle enheter i felt.

Kontroller av fastvarekompatibilitet

Fire kontroller fanger opp de fleste migrasjonsproblemer før de når feltet.

Enhets-ID.Fastvarens oppstartskode kan forgrene seg på ID-en; legg til den nye verdien eksplisitt.

Flash-størrelseregister.Verifiser forventet verdi i produksjonstesten, slik at en rull med feil tetthet avvises ved programmering.

Vektortabellforskyvning.Hvis bootloaderen flytter applikasjonen, bekreft at forskyvningen samsvarer med den nye partisjonstabellen.

Antall sider for EEPROM-emulering.Antall sider som er reservert for konfigurasjon, må samsvare med det nye oppsettet, ellers vil den siste siden overlappe applikasjonen.

6. Sekundærkilder ved 128 KB

De samme reglene fra artikkelen om 64 KB gjelder: pinkompatibilitet er mekanisk, og fastvaren må valideres. Med større flash dukker ett ekstra element opp – flash-programmeringsalgoritmen og slettegranulariteten kan variere, noe som påvirker både produksjonstiden og OTA-designet.

Verifiser også gjenopprettingsveien. Hvis bootloaderen støtter DFU over USB eller UART, test gjenoppretting fra et korrupt applikasjonsbilde på den nye tettheten, fordi DFU-deskriptoren ofte koder maksimal bildestørrelse.

Debuggtilgang er uendret, men option bytes er verdt en sjekk: lesebeskyttelse, watchdog-atferd og konfigurasjon av boot-pinne lagres i flash og kan ha ulik standardtilstand mellom partier. Bekreft dem på fixturen i stedet for på benken.

Produksjonsprogrammering og sporbarhet

Bytte av tetthet endrer programmeringsbildet og ofte fixturen. Tre punkter bør verifiseres på linjen.

Bildestørrelse og sjekksum.Programmereren må godta det større bildet, og sjekksummen som er lagret i bootloader-området, må stemme.

Verifisering ved tilbakelesing.En full verifisering etter programmering fanger opp en rull med feil tetthet umiddelbart, i stedet for ved første oppstart.

Logging av unik ID.Den 96-biters unike ID-en knytter en enhet til en produksjonsregistrering. Logging av den gjør returer fra felt sporbare og hjelper med å identifisere et dårlig parti.

7. Testplan

Når 128 KB fortsatt ikke er nok

Hvis det anslåtte bildet er over omtrent 100 KB, er ikke neste steg en annen F103-variant — det er en annen familie. F103-ens Cortex-M3 på 72 MHz og 20 KB RAM blir begrensningen før flash gjør det.

Alternativene inkluderer 256 KB-klassen i samme familie, en Cortex-M4-komponent med mer RAM og en flyttallsenhet, eller en ekstern QSPI-flash med støtte for execute-in-place. Hvert valg er en plattformbeslutning med sine egne sertifiserings- og fastvarekostnader.

Den praktiske regelen: velg tettheten som dekker funksjonene for de neste to årene, ikke gjeldende bildestørrelse. Å rekvalifisere samme kort to ganger er dyrere enn å kjøpe en litt større komponent fra starten.

En femårig produkthistorie

Tenk deg en kontroller designet i 2021 med et 40 KB-bilde på C8T6. I 2023 nådde bildet 58 KB etter at et webgrensesnitt ble lagt til. I 2024 presset TLS det forbi 64 KB, og teamet komprimerte fonter for at det skulle passe.

I 2025 passet ikke OTA-mellomlagringsområdet lenger. Løsningen på det tidspunktet var en kortrevisjon, et nytt partisjonsoppsett og en feltmigrering – alt unngåelig hvis designet hadde startet på CBT6 for noen få cent mer.

Det er argumentet for margin: ikke at den ekstra flashen vil bli brukt umiddelbart, men at kostnaden ved å gå tom måles i nye kortrunder snarere enn i cent.

8. Kostnad og planlegging

Prisforskjellen mellom C8T6 og CBT6 er liten. Beslutningen handler ikke om enhetskostnad; den handler om hvorvidt de ekstra 64 KB fjerner en fremtidig redesign.

Tre signaler taler for CBT6: det gjeldende fastvarebildet er over 45 KB, veikartet inkluderer en nettverksstack eller en skjerm, eller produktet har flerårig levetid. To signaler taler for å bli på 64 KB: fastvarebildet er stabilt og lite, og volumet er høyt nok til at cent teller.

Hvis fastvarebildet allerede er nær 100 KB, hopp til 256 KB-klassen. Å kvalifisere en 128 KB-komponent og deretter bytte igjen om et år er den dyreste veien.

En beslutningsregel for nye design

Skriv ned tre tall før du velger: størrelsen på gjeldende fastvarebilde, forventet størrelse om to år, og om OTA er påkrevd. Hvis svaret på OTA er ja, legg til størrelsen på fastvarebildet igjen. Hvis projisert total er over 90 KB, start på 128 KB eller høyere.

For et produkt med fast funksjon uten tilkobling og uten OTA er 64 KB vanligvis rikelig, og C8T6 forblir det billigere valget. Feilen er å anta at et produkt vil forbli uendret i fem år.

9. FAQ

Er CBT6 en direkte erstatning for C8T6?

Fysisk og funksjonelt ja. Fastvaren krever at linker-skriptet og partisjonstabellen oppdateres for det større flash-minnet.

Øker RAM-mengden?

Nei. Begge komponentene har 20 KB. Hvis RAM er begrensningen, vil en komponent med større flash ikke hjelpe.

Kan jeg flytte tilbake til C8T6 senere?

Bare hvis avbildningen passer i 64 KB. Planlegg partisjonstabellen slik at en nedgradering er mulig uten en kodeendring.

Har sekundærkilder samme flashstørrelsesregister?

Vanligvis finnes det et kompatibelt register, men verdien og granulariteten kan variere. Les databladet for den eksakte delen.

Hva er den vanligste migreringsfeilen?

Å oppdatere linkerskriptet, men ikke OTA-partisjonstabellen, noe som gir oppdateringer som skriver utenfor staging-området.

Bør jeg bestille CBT6 til et nytt design?

Hvis fastvarebildet er under 32 KB og stabilt, er C8T6 greit. Hvis det er noen mulighet for vekst – et webgrensesnitt, TLS, logging eller OTA – start på 128 KB og unngå en andre designrunde.

Forsyningsnotater

Tilgjengeligheten ved denne tettheten er bedre enn ved 32 KB, fordi flere design bruker den. Hold én godkjent sekundærleverandør og bekreft at flash-programmeringsalgoritmen samsvarer med produksjonsfixturen din; fastvarebildet er det samme, men verktøyet er kanskje ikke det. Sjekk det før du bestiller.

10. Kilder

• ST STM32F103CB produktside:st.com
• GigaDevice GD32F103 dokumentasjon:gigadevice.com