1. Hvorfor CBT6 findes

F103-familien blev bygget omkring en enkelt die, som kunne konfigureres med forskellige flashdensiteter. Det er derfor, at C6T6, C8T6 og CBT6 deler kapsel, pinout og periferisæt: forskellene er hukommelse, ikke arkitektur.

For en designer er det en gave. Et board, der er kvalificeret til C8T6, accepterer CBT6 uden ændring af layoutet, og firmwaren kompilerer uden driverændringer. Det eneste spørgsmål er, om hukommelseskortlægningen stadig er gyldig.

For en indkøber er det en beslutning om pris og tilgængelighed: 128 KB-delen koster lidt mere, men den fjerner risikoen for endnu en redesign af hukommelsen senere.

2. De tre hukommelsesvarianter

Bemærk, hvad der ikke ændrer sig: RAM forbliver på 20 KB på tværs af C8T6 og CBT6. Fordobling af flash giver ikke applikationen mere stack, heap eller buffere. Hvis grænsen er RAM, er svaret en anden familie, ikke en flash-komponent med større kapacitet.

32 KB C6T6 er den modsatte afvejning: billigst, men kun anvendelig til et lille fast firmware-image. At gå fra 32 KB til 128 KB er en firedobling og løser normalt begrænsningen permanent.

Hvad forbliver identisk

Pinout, kapsel, periferisæt, clock tree og debuginterface er uændrede på tværs af C6T6, C8T6 og CBT6. Samme board, samme krystal, samme SWD-header og samme USB-kreds fungerer med alle tre.

Derfor beskrives opgraderingen ofte som "gratis". Ingeniørindsatsen er reel, men afgrænset: opdater linker-scriptet, gennemgå partitionstabellen, kør accepttestene igen. Ingen ændring af skema, intet nyt layout, ingen nye drivere.

Den eneste periferiforskel, der er værd at kontrollere, er flashcontrollerens sidegeometri, fordi sidestørrelsen bestemmer, hvordan det emulerede EEPROM og bootloader sletter.

I praksis er C8T6 og CBT6 ofte udskiftelige hos distributøren, og valget afhænger af, hvilken der er tilgængelig på byggetidspunktet. Den fleksibilitet er i sig selv et argument for at designe partitionstabellen omkring 128 KB, så hver af delene kan bruges uden ændring af firmware.

3. Når 64 KB ikke længere er nok

Firmware vokser i forudsigelige trin. Et projekt, der passede komfortabelt i 40 KB, kan overskride 64 KB, når en af fem ting sker.

Der tilføjes en netværksstack.Selv en kompakt TCP/IP-stack med TLS bruger titusindvis af kilobyte.

Der tilføjes et display og et skriftsæt.Nogle få kinesiske eller japanske glyfsæt kan overstige hele applikationsbudgettet.

Der tilføjes OTA-staging.Dobbeltbankopdateringer kræver plads til et andet billede, eller i det mindste et komprimeret et.

Logning eller konfigurationslagring flyttes ind i flash.Emulerede EEPROM-sider reducerer det brugbare applikationsområde.

Debugsymboler eller en bootloader bliver større.Bootloaderen optager bunden af flash, uanset om nogen måler det.

Hvad bruger faktisk de ekstra 64 KB

Det hjælper at se, hvor pladsen går hen, før man beslutter sig. En typisk forbundet applikation på denne klasse af MCU fordeler sig nogenlunde sådan: bootloader 16 KB, applikationskode 30–50 KB, en kompakt TCP/IP-stak 12–20 KB, TLS 15–25 KB, et filsystem og konfiguration 4–8 KB samt et OTA-stagingområde svarende til image-størrelsen.

Lægger man de tal sammen, nås loftet hurtigt. En 45 KB-applikation med TLS og dual-bank-staging kræver mere end 128 KB, før der er tale om logning eller skriftdata. Det er derfor, at 64 KB-varianten føles tilstrækkelig på bænken og derefter løber tør under integrationen.

Den samme aritmetik forklarer, hvorfor "bare aktivér TLS" er en pladsbeslutning lige så meget som en sikkerhedsbeslutning. Cipher suites og certifikatlagre er ikke gratis.

4. Migrationsarbejdet

Den mest almindelige fejl er at ændre linkerscriptet og glemme partitionstabellen. Kortet programmerer derefter korrekt, men OTA-opdateringen skriver forbi staging-området, eller bootloaderen afviser et billede, som den anser for at være for stort.

Levetid og emuleret EEPROM

Flash er ikke EEPROM. F103-flashen er specificeret til et begrænset antal sletningscyklusser, typisk i størrelsesordenen ti tusinde pr. side. En konfigurationsblok, der skrives ved hver nedlukning, vil udtømme en side længe før produktets levetid slutter.

Emuleret EEPROM løser dette med to teknikker. Først skriver den til en frisk placering i stedet for at overskrive, så sliddet fordeles over en side eller en blok. Dernæst holder den et lille indeks i RAM og genskriver kun indekset, når siden er fuld.

Begge teknikker bruger flash proportionalt med antallet af variabler og wear-leveling-dybden. På en 64 KB-del kan dette udgøre en betydelig del af budgettet; på CBT6 gør den ekstra plads en dybere wear-leveling-ordning overkommelig.

Hvis produktet logger data kontinuerligt, bør du overveje en ekstern FRAM eller en lille SPI-flash i stedet for at slide på MCU'ens interne flash. Omkostningen er beskeden, og pålidelighedsgevinsten er stor.

Clock, ventetilstande og oplevet ydeevne

En større flash gør ikke MCU'en hurtigere, men den kan ændre antallet af flash-ventetilstande, som koden kører med. Ved 72 MHz har F103 brug for ventetilstande ved begge densiteter; forskellen viser sig, når koden placeres på forskellige adresser, eller når prefetch-bufferen opfører sig anderledes.

For de fleste applikationer er dette usynligt. For cyklustalte løkker, bit-bangede interfaces og stramme kontrolsløjfer kan det have betydning, og accepttesten bør omfatte de timingfølsomme stier i stedet for kun funktionelle kontroller.

Hvis designet kører under 48 MHz, er ventetilstandene normalt nul, og forskellen forsvinder helt. Det er en grund til, at mange industrielle design bevidst kører langsommere end maksimum.

5. Flashstørrelse under kørsel

F103 rapporterer sin flashstørrelse i et register, som firmware kan læse. Det er nyttigt for en platform, der leveres med enten 64 KB- eller 128 KB-dele, og det er også en fælde: kode, der hardkoder sideantal eller sektoradresser, vil opføre sig forkert på en anden densitet.

Hvis produktet kan leveres med begge varianter, skal størrelsen læses ved opstart, og lagringslaget konfigureres ud fra den. Hvis det kun leveres med én, skal den forventede størrelse verificeres i produktionstesten, så en forkert rulle fanges før samling.

OTA-designmuligheder

Fire mønstre er almindelige, og deres flash-omkostninger adskiller sig markant.

Dobbelt bank.To fulde image-slots plus en bootloader. Sikkert og enkelt, men kræver to gange image-størrelsen. På 128 KB bruger et 40 KB image med dual-bank-staging 80 KB før data.

Komprimeret staging.Det downloadede firmwarebillede gemmes komprimeret og udpakkes på stedet ved opstart. Sparer plads, tilføjer et dekomprimeringsstrin og en fejltilstand, hvis dekompressoren afbrydes.

Ekstern mellemlagring.Firmwarebilledet gemmes i en ekstern SPI-flash, og MCU'en kopierer det internt. Tilføjer en komponent, men fjerner den interne pladsbegrænsning fuldstændigt.

Ingen mellemlagring.Enheden downloader og skriver direkte, typisk med en recovery-bootloader. Billigst i flash, mest risikabel i felten.

Uanset hvilken fremgangsmåde der vælges, skal partitionstabellen være fastlagt, før firmwaren skrives. Ændres den senere, ugyldiggøres hver enhed i felten.

Kontroller af firmwarekompatibilitet

Fire kontroller fanger de fleste migreringsproblemer, før de når ud i felten.

Enheds-ID.Firmwarens opstartskode kan forgrene sig på ID'et; tilføj den nye værdi eksplicit.

Flashstørrelsesregister.Kontroller den forventede værdi i produktionstesten, så en rulle med forkert tæthed afvises på programmeringstidspunktet.

Vektortabel-offset.Hvis bootloaderen flytter applikationen, skal du bekræfte, at offsettet matcher den nye partitionstabel.

Sideantal for EEPROM-emulering.Antallet af sider, der er reserveret til konfiguration, skal svare til det nye layout; ellers vil den sidste side overlappe applikationen.

6. Sekundærkilder ved 128 KB

De samme regler fra 64 KB-artiklen gælder: pin-kompatibilitet er mekanisk, og firmwaren skal valideres. Med en større flash dukker der et ekstra punkt op — flash-programmeringsalgoritmen og slettegranulariteten kan være forskellige, hvilket påvirker både produktionstiden og OTA-designet.

Kontroller også gendannelsesstien. Hvis bootloaderen understøtter DFU over USB eller UART, skal du teste en gendannelse fra et korrupt applikationsimage på den nye densitet, fordi DFU-deskriptoren ofte koder den maksimale imagestørrelse.

Debug-adgang er uændret, men option bytes er værd at kontrollere: read-out-beskyttelse, watchdog-adfærd og boot-pin-konfiguration gemmes i flash og kan have forskellig standardtilstand mellem partier. Bekræft dem på fixturen i stedet for på bænken.

Produktionsprogrammering og sporbarhed

Skift af densitet ændrer programmeringsimaget og ofte fixturen. Tre punkter bør verificeres på linjen.

Billedstørrelse og kontrolsum.Programmeringsenheden skal acceptere det større billede, og kontrolsummen, der er lagret i bootloader-området, skal stemme overens.

Tilbagelæsningsverifikation.En fuld verifikation efter programmering fanger straks en rulle med forkert densitet i stedet for ved første opstart.

Logning af unikt ID.Det 96-bit unikke ID knytter en enhed til en produktionsregistrering. Logning af det gør returneringer fra markedet sporbare og hjælper med at identificere et dårligt parti.

7. Testplan

Når 128 KB stadig ikke er nok

Hvis det forventede image er over ca. 100 KB, er næste skridt ikke en anden F103-variant — det er en anden familie. F103'ens Cortex-M3 på 72 MHz og 20 KB RAM bliver begrænsningen, før flash bliver det.

Mulighederne omfatter 256 KB-klassen i samme familie, en Cortex-M4-komponent med mere RAM og en flydende-komma-enhed eller en ekstern QSPI-flash med understøttelse af execute-in-place. Hver af dem er en platformbeslutning med sine egne omkostninger til certificering og firmware.

Den praktiske regel: vælg den kapacitet, der dækker de næste to års funktioner, ikke den nuværende image-størrelse. At rekvalificere det samme board to gange er dyrere end at købe en lidt større komponent fra starten.

Et femårigt produktforløb

Overvej en controller, der blev designet i 2021 med et 40 KB-image på C8T6. I 2023 nåede image'et 58 KB efter tilføjelse af en webgrænseflade. I 2024 skubbede TLS det forbi 64 KB, og teamet komprimerede skrifttyper for at få det til at passe.

I 2025 passede OTA-stagingområdet ikke længere. Løsningen på det tidspunkt var en boardrevision, et nyt partitionslayout og en feltmigrering — alt kunne være undgået, hvis designet var startet på CBT6 for få cent mere.

Det er argumentet for råderum: ikke at den ekstra flash vil blive brugt med det samme, men at omkostningen ved at løbe tør måles i re-spins snarere end i cent.

8. Omkostninger og planlægning

Prisforskellen mellem C8T6 og CBT6 er lille. Beslutningen handler ikke om enhedspris; den handler om, hvorvidt de ekstra 64 KB fjerner behovet for et fremtidigt redesign.

Tre signaler taler for CBT6: det aktuelle image er over 45 KB, køreplanen omfatter en netværksstak eller et display, eller produktet har en flerårig levetid. To signaler taler for at blive på 64 KB: imaget er stabilt og lille, og volumen er høj nok til, at cents betyder noget.

Hvis imaget allerede er tæt på 100 KB, skal du springe til 256 KB-klassen. At kvalificere en 128 KB-komponent og derefter skifte igen om et år er den dyreste vej.

En beslutningsregel for nye designs

Skriv tre tal ned, før du vælger: aktuel imagestørrelse, forventet størrelse om to år, og om OTA er påkrævet. Hvis svaret på OTA er ja, skal du lægge imagestørrelsen til igen. Hvis den forventede total er over 90 KB, skal du starte ved 128 KB eller højere.

For et fastfunktionsprodukt uden netværksforbindelse og uden OTA er 64 KB normalt rigeligt, og C8T6 forbliver det billigere valg. Fejlen er at antage, at et produkt vil forblive uændret i fem år.

9. FAQ

Er CBT6 en drop-in-erstatning for C8T6?

Fysisk og funktionelt ja. Firmwaren skal have linker-scriptet og partitionstabellen opdateret til den større flash.

Øges RAM?

Nej. Begge komponenter har 20 KB. Hvis RAM er begrænsningen, vil en komponent med større flash ikke hjælpe.

Kan jeg skifte tilbage til C8T6 senere?

Kun hvis firmwarebilledet passer i 64 KB. Planlæg partitionstabellen, så en nedgradering er mulig uden kodeændring.

Har andensource-komponenter det samme flashstørrelsesregister?

Normalt findes der et kompatibelt register, men værdien og granulariteten kan være forskellig. Læs databladet for den præcise del.

Hvad er den mest almindelige migreringsfejl?

At opdatere linker-scriptet men ikke OTA-partitionstabellen, hvilket giver opdateringer, der skriver uden for stagingområdet.

Skal jeg bestille CBT6 til et nyt design?

Hvis firmwarebilledet er under 32 KB og stabilt, er C8T6 fint. Hvis der er den mindste chance for vækst — en webgrænseflade, TLS, logning eller OTA — så start ved 128 KB og undgå endnu en designcyklus.

Forsyningsnoter

Tilgængeligheden ved denne tæthed er bedre end ved 32 KB, fordi flere design bruger den. Behold én godkendt andenleverandør, og bekræft, at dennes flash-programmeringsalgoritme svarer til din produktionsfixture; firmwarebilledet er det samme, men værktøjet er måske ikke. Kontroller det, før du afgiver ordren.

10. Kilder

• ST STM32F103CB-produktside:st.com
• GigaDevice GD32F103 dokumentation:gigadevice.com