1. Perché esiste il CBT6

La famiglia F103 è stata costruita attorno a un singolo die che poteva essere configurato con diverse densità di flash. Ecco perché C6T6, C8T6 e CBT6 condividono package, pinout e set di periferiche: le differenze riguardano la memoria, non l'architettura.

Per un progettista, è un regalo. Una scheda qualificata per C8T6 accetta il CBT6 senza modifiche al layout, e il firmware si compila senza modifiche ai driver. L'unica questione è se la mappa di memoria è ancora valida.

Per chi acquista, è una decisione di prezzo e disponibilità: il componente da 128 KB costa leggermente di più, ma elimina il rischio di un secondo ridisegno dello storage in seguito.

2. Le tre varianti di memoria

Nota ciò che non cambia: la RAM resta a 20 KB tra C8T6 e CBT6. Raddoppiare la flash non fornisce all'applicazione più stack, heap o buffer. Se il limite è la RAM, la risposta è una famiglia diversa, non un componente con più flash.

Il C6T6 da 32 KB è il compromesso opposto: il più economico, ma utilizzabile solo per un'immagine piccola e fissa. Passare da 32 KB a 128 KB è un aumento di quattro volte e di solito risolve definitivamente il vincolo.

Cosa rimane identico

Pinout, package, set di periferiche, clock tree e interfaccia di debug sono invariati tra C6T6, C8T6 e CBT6. La stessa scheda, lo stesso cristallo, lo stesso connettore SWD e lo stesso circuito USB funzionano con tutti e tre.

Ecco perché l'aggiornamento viene spesso descritto come "gratuito". L'impegno ingegneristico è reale ma limitato: aggiornare il linker script, rivedere la partition table, rieseguire i test di accettazione. Nessuna modifica allo schema elettrico, nessun nuovo layout, nessun nuovo driver.

L'unica differenza periferica che vale la pena verificare è la geometria delle pagine del controller flash, perché la dimensione della pagina determina come l'EEPROM emulata e il bootloader eseguono la cancellazione.

In pratica, C8T6 e CBT6 sono spesso intercambiabili a livello di distributore, e la scelta si riduce a quale sia disponibile al momento della produzione. Questa flessibilità è di per sé un argomento a favore della progettazione della partition table su 128 KB, così che entrambi i componenti possano essere utilizzati senza modifiche al firmware.

3. Quando 64 KB non bastano più

Il firmware cresce in passi prevedibili. Un progetto che rientrava comodamente in 40 KB può superare i 64 KB quando si verifica una delle cinque circostanze.

Viene aggiunto uno stack di rete.Anche uno stack TCP/IP compatto con TLS consuma decine di kilobyte.

Vengono aggiunti un display e un set di font.Alcuni set di glifi cinesi o giapponesi possono superare l'intero budget dell'applicazione.

Viene aggiunto lo staging OTA.Gli aggiornamenti dual-bank richiedono spazio per una seconda immagine, o almeno per una versione compressa.

La registrazione dei log o l'archiviazione della configurazione si sposta nella flash.Le pagine di EEPROM emulata riducono lo spazio disponibile per l'applicazione.

I simboli di debug o un bootloader crescono.Il bootloader occupa la parte inferiore della flash indipendentemente dal fatto che lo si misuri o meno.

Che cosa consuma effettivamente i 64 KB aggiuntivi

Aiuta vedere dove va lo spazio prima di decidere. Una tipica applicazione connessa su questa classe di MCU si scompone all'incirca così: bootloader 16 KB, codice applicativo 30–50 KB, uno stack TCP/IP compatto 12–20 KB, TLS 15–25 KB, un file system e configurazione 4–8 KB, e un'area di staging OTA pari alla dimensione dell'immagine.

Somma quei numeri e il limite arriva in fretta. Un'applicazione da 45 KB con TLS e staging dual-bank necessita di più di 128 KB prima di qualsiasi logging o dati dei font. Ecco perché il componente da 64 KB sembra adeguato al banco e poi si esaurisce durante l'integrazione.

La stessa aritmetica spiega perché "basta abilitare TLS" è una decisione relativa allo spazio di archiviazione tanto quanto alla sicurezza. Le suite di cifratura e gli archivi di certificati non sono gratuiti.

4. Il lavoro di migrazione

L'errore più comune è modificare lo script del linker e dimenticare la tabella delle partizioni. La scheda quindi si programma correttamente, ma l'aggiornamento OTA scrive oltre la regione di staging, oppure il bootloader rifiuta un'immagine che considera troppo grande.

Endurance e EEPROM emulata

La flash non è una EEPROM. La flash dell'F103 è specificata per un numero limitato di cicli di cancellazione, tipicamente nell'ordine delle decine di migliaia per pagina. Un blocco di configurazione scritto a ogni spegnimento esaurirà una pagina molto prima che termini la vita utile del prodotto.

La EEPROM emulata risolve questo problema con due tecniche. Innanzitutto, scrive in una posizione nuova invece di sovrascrivere, così l'usura si distribuisce su una pagina o un blocco. In secondo luogo, mantiene un piccolo indice in RAM e riscrive l'indice solo quando la pagina è piena.

Entrambe le tecniche consumano flash in proporzione al numero di variabili e alla profondità del wear-leveling. Su un componente da 64 KB, questo può rappresentare una frazione significativa del budget; sul CBT6, lo spazio aggiuntivo rende sostenibile uno schema di wear-leveling più profondo.

Se il prodotto registra dati in modo continuo, valuta una FRAM esterna o una piccola flash SPI invece di consumare la flash interna dell'MCU. Il costo è modesto e il guadagno in affidabilità è elevato.

Clock, stati di attesa e prestazioni percepite

Una flash più grande non rende l'MCU più veloce, ma può cambiare il numero di stati di attesa della flash con cui viene eseguito il codice. A 72 MHz l'F103 richiede stati di attesa su entrambe le densità; la differenza emerge quando il codice è collocato a indirizzi diversi o quando il buffer di prefetch si comporta in modo diverso.

Per la maggior parte delle applicazioni questo è invisibile. Per i loop con conteggio dei cicli, le interfacce bit-banged e i cicli di controllo serrati può essere importante, e il test di accettazione dovrebbe includere i percorsi sensibili ai tempi anziché solo verifiche funzionali.

Se il progetto funziona al di sotto di 48 MHz, gli stati di attesa sono di solito zero e la differenza scompare del tutto. Questo è uno dei motivi per cui molti progetti industriali funzionano deliberatamente più lentamente del massimo.

5. Dimensione della flash in fase di esecuzione

L'F103 riporta la dimensione della propria flash in un registro che il firmware può leggere. Ciò è utile per una piattaforma che viene fornita con parti da 64 KB o 128 KB, ed è anche una trappola: il codice che codifica in modo fisso il numero di pagine o gli indirizzi dei settori si comporterà in modo errato su una densità diversa.

Se il prodotto può essere spedito con entrambe le varianti, leggere la dimensione all'avvio e configurare il livello di archiviazione in base a essa. Se viene spedito con una sola, verificare la dimensione prevista nel test di produzione, così che una bobina errata venga intercettata prima dell'assemblaggio.

Opzioni di progettazione OTA

Quattro schemi sono comuni e il loro costo in flash differisce nettamente.

Doppio banco.Due slot completi per l'immagine più un bootloader. Sicuro e semplice, ma richiede il doppio della dimensione dell'immagine. Su 128 KB, un'immagine da 40 KB con staging a doppio banco consuma 80 KB prima dei dati.

Staging compresso.L'immagine scaricata viene memorizzata compressa ed espansa sul posto all'avvio. Consente di risparmiare spazio, aggiunge una fase di decompressione e una modalità di guasto se il decompressore viene interrotto.

Staging esterno.L'immagine è memorizzata in una SPI flash esterna e l'MCU la copia internamente. Aggiunge un componente ma elimina del tutto il vincolo di spazio interno.

Nessuno staging.Il dispositivo scarica e scrive direttamente, in genere con un bootloader di ripristino. È la soluzione più economica in termini di flash e la più rischiosa sul campo.

Qualunque schema venga scelto, la tabella delle partizioni deve essere fissata prima della scrittura del firmware. Modificarla successivamente invalida ogni dispositivo sul campo.

Verifiche di compatibilità del firmware

Quattro controlli intercettano la maggior parte dei problemi di migrazione prima che si manifestino sul campo.

ID dispositivo.Il codice di avvio del firmware può diramarsi in base all'ID; aggiungere esplicitamente il nuovo valore.

Registro della dimensione Flash.Verificare il valore atteso nei test di produzione, in modo che una bobina con densità errata venga rifiutata al momento della programmazione.

Offset della tabella dei vettori.Se il bootloader riloca l'applicazione, verificare che l'offset corrisponda alla nuova tabella delle partizioni.

Numero di pagine dell'emulazione EEPROM.Il numero di pagine riservate alla configurazione deve corrispondere al nuovo layout, altrimenti l'ultima pagina si sovrapporrà all'applicazione.

6. Fonti alternative a 128 KB

Valgono le stesse regole dell'articolo sui 64 KB: la compatibilità dei pin è meccanica e il firmware deve essere validato. Con una flash più grande compare un elemento in più — l'algoritmo di programmazione della flash e la granularità di cancellazione possono differire, il che influisce sia sui tempi di produzione sia sul design OTA.

Verificare anche il percorso di recovery. Se il bootloader supporta DFU su USB o UART, testare un recovery da un'immagine applicativa corrotta sulla nuova densità, perché il descrittore DFU spesso codifica la dimensione massima dell'immagine.

L'accesso al debug è invariato, ma vale la pena controllare gli option byte: la protezione dalla lettura, il comportamento del watchdog e la configurazione del pin di boot sono memorizzati nella flash e possono differire nello stato predefinito tra i lotti. Confermarli sul fixture anziché sul banco.

Programmazione in produzione e tracciabilità

Il cambio di densità modifica l'immagine di programmazione e, spesso, il fixture. Tre elementi dovrebbero essere verificati sulla linea.

Dimensione dell'immagine e checksum.Il programmatore deve accettare l'immagine più grande e il checksum memorizzato nell'area del bootloader deve corrispondere.

Verifica di rilettura.Una verifica completa dopo la programmazione intercetta immediatamente una bobina con densità errata, invece che al primo avvio.

Registrazione dell'ID univoco.L'ID univoco a 96 bit collega un dispositivo a un record di produzione. La sua registrazione rende tracciabili i resi dal campo e aiuta a identificare un lotto difettoso.

7. Piano di test

Quando 128 KB non sono ancora sufficienti

Se l'immagine prevista è superiore a circa 100 KB, il passo successivo non è un'altra variante F103 — è una famiglia diversa. Il Cortex-M3 dell'F103 a 72 MHz e 20 KB di RAM diventa il vincolo prima della memoria flash.

Le opzioni includono la classe da 256 KB nella stessa famiglia, un componente Cortex-M4 con più RAM e un'unità in virgola mobile, oppure una memoria flash QSPI esterna con supporto execute-in-place. Ognuna è una decisione di piattaforma con i propri costi di certificazione e firmware.

La regola pratica: scegliere la densità che copre i prossimi due anni di funzionalità, non la dimensione attuale dell'immagine. Requalificare due volte la stessa scheda costa più che acquistare fin dall'inizio un componente leggermente più grande.

Una storia di prodotto di cinque anni

Si consideri un controller progettato nel 2021 con un'immagine da 40 KB sul C8T6. Nel 2023 l'immagine ha raggiunto 58 KB dopo l'aggiunta di un'interfaccia web. Nel 2024, TLS l'ha portata oltre 64 KB e il team ha compresso i font per farla rientrare.

Nel 2025 l'area di staging OTA non entrava più. La soluzione a quel punto è stata una revisione della scheda, un nuovo layout delle partizioni e una migrazione sul campo — tutto evitabile se il progetto fosse partito dal CBT6 per pochi centesimi in più.

Questo è l'argomento a favore del margine di crescita: non che la flash in più verrà utilizzata immediatamente, ma che il costo di esaurirla si misura in re-spin anziché in centesimi.

8. Costi e pianificazione

La differenza di prezzo tra C8T6 e CBT6 è minima. La decisione non riguarda il costo unitario; riguarda se i 64 KB aggiuntivi eliminano una futura riprogettazione.

Tre segnali sono a favore del CBT6: l'immagine corrente supera i 45 KB, la roadmap include uno stack di rete o un display, oppure il prodotto ha una vita pluriennale. Due segnali inducono a restare a 64 KB: l'immagine è stabile e ridotta, e i volumi sono abbastanza elevati da far contare anche i centesimi.

Se l'immagine è già vicina a 100 KB, passare direttamente alla classe da 256 KB. Qualificare un componente da 128 KB e poi cambiare di nuovo entro un anno è il percorso più costoso.

Una regola di decisione per i nuovi progetti

Annotare tre numeri prima di scegliere: dimensione corrente dell'immagine, dimensione prevista tra due anni e se OTA è necessario. Se la risposta a OTA è sì, aggiungere di nuovo la dimensione dell'immagine. Se il totale previsto supera 90 KB, partire da 128 KB o più.

Per un prodotto a funzionalità fissa senza connettività e senza OTA, 64 KB sono di solito ampiamente sufficienti e il C8T6 resta la scelta più economica. L'errore è presumere che un prodotto rimanga a funzionalità fissa per cinque anni.

9. FAQ

Il CBT6 è un sostituto drop-in per il C8T6?

Fisicamente e funzionalmente sì. Il firmware richiede l'aggiornamento dello script del linker e della tabella delle partizioni per la memoria flash più grande.

La RAM aumenta?

No. Entrambi i componenti hanno 20 KB. Se la RAM è il vincolo, un componente con memoria flash più grande non aiuta.

Posso tornare a C8T6 in seguito?

Solo se l'immagine rientra in 64 KB. Pianifica la tabella delle partizioni in modo che un downgrade sia possibile senza modificare il codice.

Le fonti alternative hanno lo stesso registro della dimensione della flash?

Di solito esiste un registro compatibile, ma il valore e la granularità possono differire. Consulta la scheda tecnica per il componente esatto.

Qual è il bug di migrazione più comune?

Aggiornare lo script del linker ma non la tabella delle partizioni OTA, il che produce aggiornamenti che scrivono al di fuori dell'area di staging.

Dovrei ordinare CBT6 per un nuovo progetto?

Se l'immagine è inferiore a 32 KB ed è stabile, C8T6 va bene. Se c'è una qualsiasi possibilità di crescita — un'interfaccia web, TLS, logging o OTA — inizia da 128 KB ed evita un secondo ciclo di progettazione.

Note sulla fornitura

La disponibilità a questa densità è migliore rispetto a 32 KB, perché più progetti la utilizzano. Mantieni una seconda fonte approvata e conferma che il suo algoritmo di programmazione della flash corrisponda al tuo fixture di produzione; l'immagine è la stessa, ma gli strumenti potrebbero non esserlo. Verificalo prima di effettuare l'ordine.

10. Fonti

• Pagina prodotto ST STM32F103CB:st.com
• Documentazione GigaDevice GD32F103:gigadevice.com