1. Wat verandert er werkelijk tussen RBT6, RCT6 en RET6?

Alle drie de onderdelen zijn STM32F103-microcontrollers uit de performance-line, gebaseerd op dezelfde 72 MHz Arm Cortex-M3-core, dezelfde periferiemogelijkheden en dezelfde LQFP64-behuizing met een behuizing van 10 × 10 × 1.4 mm. De letter na "F103" plus het getal coderen de flashgrootte: RBT6 wordt geleverd met 128 Kbytes flash en 20 Kbytes SRAM, RCT6 wordt geleverd met 256 Kbytes flash en 48 Kbytes SRAM, en RET6 wordt geleverd met 512 Kbytes flash en maximaal 64 Kbytes SRAM. Niets aan het silicium verandert het aantal pinnen, de pindefinitie of de coreperiferie; alleen de hoeveelheid geheugen op de chip verandert.

Die combinatie van een identieke footprint en meer geheugen maakt dit tot een echte "capaciteitsupgrade" in plaats van een vervanging door een onderdeel van een andere fabrikant. De printplaat hoeft niet opnieuw te worden ontworpen, er is geen nieuw land pattern en er verandert niets aan de SWD- of JTAG-debugheader. Het resterende werk zit volledig in de firmware: controleren of niets in de build, het linker-script of de flashdriver uitging van de geometrie van het kleinere onderdeel.

Het eigen high-density-datasheet van ST (DS5792, voor de onderdelen 256 tot 512 Kbyte) en het medium-density-datasheet verwijzen beide naar dezelfde beschrijving van de performance-line-familie, en het commerciële datasheet STM32F103x8/B vermeldt dat de familie is ontworpen voor volledige pin-to-pin-, software- en featurecompatibiliteit. Die verklaring gaat over de familierelatie en vervangt niet de controle van de specifieke geheugenkaart van het beoogde onderdeel.

2. Is de pinout echt identiek?

Mechanisch gezien wel, voor deze specifieke drie onderdelen. RBT6, RCT6 en RET6 vermelden allemaal een LQFP 64-behuizingsoptie van 10 × 10 × 1.4 mm op de bestelgegevenspagina's van ST, met 51 algemene I/O-pinnen in deze configuratie. Dezelfde onderdeelnummers worden ook in andere behuizingen aangeboden (RBT6 voegt bijvoorbeeld een TFBGA64-optie toe), dus het achtervoegsel van de behuizing en de exacte bestelcode moeten afzonderlijk worden gecontroleerd. De claim "hetzelfde aantal pinnen" is niet hetzelfde als een geverifieerde footprintmatch voor het specifieke bestelbare onderdeel dat wordt gebruikt.

Voordat een beslissing over het opnieuw ontwerpen van de printplaat wordt genomen, in welke richting dan ook, moet de actuele tabel met apparaatgegevens in het datasheet voor de exacte te sourcen bestelcode worden geraadpleegd. De catalogus van ST voegt, net als die van de meeste fabrikanten, periodiek specifieke behuizingsopties per onderdeelnummer toe of trekt deze in, en het achtervoegsel van de bestelcode (hier "T6", plus eventuele aanvullende letters voor behuizing of temperatuur) is de code waartegen een distributeur daadwerkelijk voorraad voert.

3. Waarom noemt ST deze verschillende dichtheidsklassen?

De referentiehandleiding van ST voor de STM32F10xxx (RM0008) en de flashprogrammeerhandleiding (PM0075) delen de STM32F101/F102/F103-familie in in low-density (16 tot 32 Kbytes flash), medium-density (64 tot 128 Kbytes), high-density (256 tot 512 Kbytes) en XL-density-klassen. RBT6 valt onder medium-density; RCT6 en RET6 vallen onder high-density. Dit is geen marketinglabel: de dichtheidsklasse bepaalt de organisatie van de interne flash-array, en juist dat detail is van belang voor de firmware.

Concreet vermeldt PM0075 dat het hoofdblok van het flashgeheugen is georganiseerd als 32 pagina's van 1 Kbyte voor low-density-devices, 128 pagina's van 1 Kbyte voor medium-density-devices en 256 pagina's van 2 Kbytes voor high-density-devices. De wisgranulariteit, het kleinste blok dat de flashcontroller in één bewerking kan wissen, is gekoppeld aan de dichtheidsklasse en niet aan het feit dat het onderdeel tot dezelfde pincompatibele familie behoort.

4. Wat is een flash-wispage en waarom is de grootte ervan belangrijk?

On-chip flash kan niet byte voor byte worden herschreven zoals RAM dat kan. Om eerder geprogrammeerde bits van 0 terug te zetten naar 1, moet de flashcontroller eerst een volledige pagina wissen; pas daarna kunnen nieuwe gegevens daarin worden geprogrammeerd. De pagina is daarom de atomaire eenheid voor elke update in het veld, of het nu gaat om een bootloader die een nieuwe applicatie-image schrijft, een instellingenblok dat opnieuw wordt geschreven of een OTA-update die een nieuwe firmwareversie klaarzet.

Een ontwerp rond RBT6 dat flash wist in eenheden van 1 Kbyte en twee onafhankelijke datablokken 1 Kbyte uit elkaar opslaat omdat dat op dat onderdeel een veilige wisgrens was, vertrouwt op een eigenschap van de medium-density-flasharray. Als dezelfde firmware naar RCT6 wordt verplaatst zonder dit opnieuw te controleren, wist de wisopdracht nu 2 Kbytes tegelijk: het tweede datablok, waarvan de firmware nog steeds denkt dat het geïsoleerd is, bevindt zich binnen de pagina die zojuist samen met het eerste blok is gewist.

Deze foutmodus lijkt aanvankelijk niet op een flashprobleem. Het probleem uit zich in instellingen die stilletjes terugvallen, een applicatiepartitie die na een update beschadigd raakt of een OTA-image die één keer opstart en daarna na de volgende schrijfcyclus faalt. Omdat het symptoom tijdens gebruik optreedt en niet tijdens het flashen, is het gemakkelijk tijd te besteden aan timing, voeding of interrupts voordat de werkelijke oorzaak — een aanname over de paginagrootte — wordt gecontroleerd.

5. Waar gaat een hardgecodeerde paginagrootte in een bootloader mis?

Op drie plaatsen in een typische firmwarebuild wordt een aanname over de grootte van een wispagina vastgelegd; alle drie moeten worden gecontroleerd bij de overgang tussen dichtheidsklassen:

1. De flashregiodefinities van het linker-script. Een aangepaste bootloader-/applicatiescheiding lijnt regio's vaak uit op de wispaginagrens die tijdens de ontwikkeling werd gebruikt. Als die grens op 1 Kbyte op RBT6 was ingesteld, blijven de regio's geldige adressen op RCT6, maar zijn ze niet langer uitgelijnd op de werkelijke 2 Kbyte-wisgrens van dat onderdeel. Daardoor kunnen tijdens een update gedeeltelijke pagina's over de applicatie- en bootloaderregio's heen vallen.
2. De wisroutine van de flashdriver. Zowel de ST's HAL als de standaard peripheral library bieden flash-wisfuncties die een pagina-adres accepteren, maar de paginagrootteconstante die wordt gebruikt om te berekenen hoeveel wisaanroepen nodig zijn of waar de volgende pagina begint, wordt soms lokaal in de applicatiecode gedefinieerd in plaats van uit de eigen geheugenorganisatie van het onderdeel te worden gelezen.
3. Elke OTA- of instellingenopslagbibliotheek die van buiten de HAL wordt ingeladen. Flashgebaseerde opslagbibliotheken van derden gebruiken vaak standaard een configureerbare paginagrootte die per doel moet worden ingesteld; als een 1 Kbyte-standaardwaarde stilzwijgend blijft staan terwijl RCT6-silicium wordt gebruikt, ontstaat hetzelfde risico op corruptie, zonder enig symptoom op linkerniveau.

De praktische oplossing is in alle drie de gevallen hetzelfde: zoek elke verwijzing naar de wispaginagrootte in de build, controleer in het huidige datasheet en PM0075 of deze uit de werkelijke organisatie van het doelonderdeel wordt gelezen (of daar expliciet mee overeenkomt), en voer opnieuw een volledige wis-/programmeer-/verificatiecyclus uit over een representatief adresbereik, niet alleen over de adressen die tijdens de oorspronkelijke ingebruikname werden gebruikt.

6. Wat verandert er naast de flash?

SRAM neemt dezelfde richting als flash, maar met een grotere relatieve toename: 20 KB op RBT6 tegenover 48 KB op RCT6 is meer dan dubbel zo groot, en 64 KB op RET6 is meer dan driemaal zo groot. Een ontwerp dat op RAM op het kleinere onderdeel krap zat, krijgt zinvolle extra ruimte voor grotere buffers, een grotere heap of aanvullende RTOS-taken. Een ontwerp dat RAM precies had begroot voor RBT6's 20 KB, moet opnieuw controleren of vaste statische allocaties, stackgroottes en linker-symbolen nog kloppen; de overstap naar een onderdeel met meer beschikbare RAM vereist niet dat alles wordt gebruikt, maar code die adressen berekende ten opzichte van een vaste, kleinere RAM-grootte moet op dezelfde manier worden nagekeken als de flashaannames.

De core, de klokboom, de GPIO-structuur en de communicatieperipherals (I2C, SPI, I2S, USART, USB, CAN) veranderen niet tussen deze drie onderdelen. De elektrische specificaties, het werkspanningsbereik en de timing van die peripherals worden bepaald door het ontwerp van de performance-line-familie, niet door de geheugendichtheid. Een kwalificatie op peripheralniveau hoeft daarom niet uitsluitend vanwege de flashupgrade opnieuw te worden uitgevoerd.

7. Wat moet worden geverifieerd voordat het onderdeel wordt geüpgraded?

Een dichtheidsupgrade binnen deze familie is veilig zodra vijf punten zijn gecontroleerd aan de hand van het actuele datasheet van het specifieke doelonderdeel en de flashprogrammeerhandleiding, en niet uitsluitend op basis van pincompatibiliteit zijn aangenomen.

1. Bestelbare behuizingscode. Controleer of de exacte LQFP64-bestelcode voor de doeldichtheid actueel en verkrijgbaar is bij de beoogde bron; behuizingsopties kunnen voor een bepaalde fabrikant binnen het dichtheidsbereik verschillen.
2. Flash-wispaginagrootte. Controleer of de bootloader, de OTA-bibliotheek of de instellingenopslag uitgaat van een vaste paginagrootte, en pas die constante aan zodat deze overeenkomt met de dichtheidsklasse van het doelonderdeel (1 Kbyte voor gemiddelde dichtheid, 2 Kbyte voor hoge dichtheid).
3. Uitlijning van linker-scriptregio's. Controleer opnieuw of de applicatie- en bootloaderregio's zijn uitgelijnd op de nieuwe wispaginagrens, en niet alleen op een geldig flashadres.
4. RAM-gerelateerde adressering. Controleer alle code die bufferlocaties of stacklimieten berekent ten opzichte van een specifieke SRAM-grootte, in plaats van de linker-symbolen van de toolchain te gebruiken.
5. Volledige wis-/programmeer-/verificatietest. Voer het volledige updatepad uit, inclusief een gesimuleerde onderbroken schrijfactie als de applicatie fail-safe updates ondersteunt, voordat het nieuwe onderdeel voor productie wordt gekwalificeerd.

Documenteer op welk specifiek onderdeel (RBT6, RCT6 of RET6) een bepaalde firmwarebuild is gericht, en voorkom dat één binair bestand zonder expliciete paginagroottecontrole in de flashdriver zelf over dichtheidsklassen heen wordt geleverd.

8. Zijn er pincompatibele alternatieven buiten de ST-familie?

Onderdelen van een tweede bron die compatibel zijn met STM32F103 bestaan van andere fabrikanten en worden doorgaans verkocht met dezelfde LQFP64-pinconfiguratie voor gelijkwaardige dichtheden, volgens dezelfde logica als de eerdere STM32F103C8T6-cross-referencegids op deze site. De waarschuwing is hier hetzelfde: pincompatibiliteit is een mechanische claim over de behuizing en bewijst op zichzelf geen identieke flashcontroller, identieke wispagegrootte of identieke flashprogrammeertiming. Controleer de eigen programmeerhandleiding van de specifieke fabrikant op de wispagegrootte en de configuratie van de flash-toegangscyclus voordat u ervan uitgaat dat een onderdeel van een tweede bron zich op firmwareniveau gedraagt als het originele ST-onderdeel.

9. Wat hoort er in de aanvraag voor sourcing te staan?

Bij het inkopen van een dichtheidsupgrade levert een aanvraag met het exacte doelonderdeel sneller een bruikbaar antwoord op dan een aanvraag waarin alleen een flashgrootte wordt genoemd. Een leverancier kan de voorraad aan de hand van de volledige bestelcode bevestigen, maar een kale "256 KB STM32F103" specificeert de behuizing, de temperatuurgraad of het exacte suffix niet.

Nuttige gegevens zijn het volledige bestelbare onderdeelnummer (inclusief behuizings- en temperatuursuffix), de hoeveelheid per build met het jaarlijkse volume, of het ontwerp van een specifiek kleiner onderdeel komt (vermeld het exacte brononderdeelnummer), en of de wispaginagrootte van de huidige firmware al is aangepast aan de dichtheidsklasse van het doel. Als alleen de doeldichtheid van belang is en zowel RCT6 als RET6 volstaat, vermeld dat dan; als een specifieke RAM-grootte vereist is, vermeld die dan in plaats van "de grootste beschikbare" aan te vragen.

Zoek voor de actuele beschikbaarheid binnen deze familie op de STM32F103RCT6-vermelding, op de STM32F103RBT6-vermelding en op de STM32F103RET6-vermelding op chip-seek.com. Deze pagina's tonen actuele catalogusresultaten en vormen geen voorraadclaim; bevestig hoeveelheid en datumcode aan de hand van de offerte. De eerdere STM32F103C8T6-cross-referencegids en STM32F103CBT6-gids de kleinere LQFP48-leden van dezelfde familie voor projecten die nog niet voor de 64-pins footprint hebben gekozen. Een sourcingaanvraag met meerdere regels kan worden ingediend via de BOM en RFQ-formulier.

Veelgestelde vragen

Kan ik hetzelfde firmwarebinair bestand zonder wijzigingen gebruiken op RBT6 en RCT6? Alleen als de firmware de flashgeometrie al uit de eigen definities van het onderdeel leest in plaats van een paginagrootte hard te coderen. De meeste bring-upcode die voor één doelcomponent is geschreven, codeert deze waarde wel hard, dus controleer de flashdriver en het linker-script voordat je het binaire bestand hergebruikt.

Is de LQFP64-footprint daadwerkelijk identiek voor RBT6, RCT6 en RET6? Ja, voor het LQFP 64, 10 × 10 × 1.4 mm-pakket dat in de actuele ST-bestelinformatie van elk onderdeel staat vermeld. Controleer de specifieke bestelbare code voor het doelonderdeel, omdat de beschikbaarheid van behuizingen gedurende de levenscyclus van een product kan veranderen.

Wat is volgens de terminologie van ST het verschil tussen medium-density en high-density? Het is een flashcapaciteitsklasse die is gedefinieerd in de RM0008-referentiehandleiding van ST: medium-density omvat 64 tot 128 Kbytes flash, en high-density omvat 256 tot 512 Kbytes. De klasse bepaalt de interne organisatie van de flasharray, waaronder de grootte van de wispagina.

Zijn voor meer SRAM op zichzelf firmwarewijzigingen nodig? Nee. Ongebruikte RAM hoeft niet te worden gebruikt. Controle is alleen nodig voor code die adressen of limieten berekende ten opzichte van de vaste RAM-grootte van het kleinere onderdeel, in plaats van door de linker geleverde symbolen te gebruiken.

Veranderen de ADC, timers, USB- en CAN-peripherals tussen deze drie onderdelen? Nee. De kernset van peripherals, elektrische specificaties en klokboom worden bepaald door het ontwerp van de performance-line-familie en veranderen bij deze drie onderdelen niet met de geheugendichtheid.

Wat gebeurt er als de grootte van de wispagina in firmware voor productie onjuist is? Gegevens naast de bedoelde gegevens binnen dezelfde fysieke wispagina kunnen onbedoeld worden gewist wanneer één gebied wordt gewist. Dit uit zich doorgaans als beschadigde instellingen of een mislukte update, en niet als een onmiddellijke programmeerfout.

Bronnen

• Omslagfoto: Raimond Spekking, Foto van de behuizing: STMicroelectronics, STM32F107RBT6 en LQFP64, CC BY-SA 4.0. Chip-seek heeft de omslagfoto bijgesneden en onder dezelfde licentie samengesteld. De foto toont dezelfde LQFP64-behuizingsfamilie en is niet specifiek een foto van een STM32F103RBT6, RCT6 of RET6, en vormt ook geen bewijs van voorraad.
• ST STM32F103RB-productpagina: flashgrootte, SRAM, behuizingsopties en bestelinformatie.
• ST STM32F103RC/RD/RE-datasheet, DS5792: beschrijving van de high-density performance-line-familie, flash- en SRAM-capaciteit en behuizingsinformatie.
• ST STM32F103RE-productpagina: flashgrootte, SRAM en bevestiging van de LQFP64-behuizing.
• ST PM0075, programmeerhandleiding voor STM32F10xxx-flashgeheugenmicrocontrollers: organisatie van de flashmodule, paginagrootte per dichtheidsklasse en definities van low-, medium- en high-density.
• ST STM32F103x8/B-datasheet: verklaring over pin-naar-pin-, software- en functiecompatibiliteit binnen de performance-line-familie.

Hulp nodig bij het sourcen van de juiste dichtheid?

Werk je in plaats daarvan met de 48-pins familie? De STM32F103C8T6-cross-referencegids behandelt de kleinere LQFP48-behuizing.