# Bring-up MCU: il quarzo che non oscilla e la seriale illeggibile > Due classici del bring-up embedded: il quarzo che non oscilla per capacità di carico sbagliate e la UART illeggibile per errore di baud rate. La diagnosi. Pubblicato: 2026-06-24 Categoria: firmware Tag: firmware, bring-up, quarzo, uart, baud-rate, clock, embedded Pagina: --- Nel bring-up di una scheda nuova, clock e UART sono fra i primi sottosistemi da verificare: un errore sull’oscillatore si propaga ai generatori di baud rate e a ogni periferica temporizzata, quindi si presenta come un guasto altrove. Nel bring-up di un MCU — che sia un ARM Cortex-M o un core RISC-V — due fallimenti tornano con una regolarità quasi noiosa: l'oscillatore a quarzo che non oscilla (o deriva), e la UART che sputa caratteri a caso. Entrambi si diagnosticano con i conti e con l’oscilloscopio, senza sostituire componenti a tentativi. Nella nostra esperienza la causa più frequente è un valore sbagliato in fase di progetto, non un guasto. ## Il quarzo che non parte: è una questione di capacità di carico Il sintomo è inequivocabile: il clock di sistema non aggancia, il PLL non si stabilizza, oppure la frequenza è fuori specifica di centinaia di ppm e tutto quello che dipende dal tempo — UART, USB, timer — va alla deriva. La prima reazione è sospettare il quarzo difettoso, e di rado è quello. Nella maggior parte dei casi il problema sta nelle **capacità di carico**. Un quarzo non è un componente che "oscilla e basta": oscilla alla frequenza nominale solo se vede una specifica capacità ai suoi terminali, la **capacità di carico CL** dichiarata sul datasheet (tipicamente 8, 12, 18, 20 pF). Quel valore è la capacità che il circuito esterno deve presentare al quarzo. Se è sbagliata, il quarzo oscilla a una frequenza leggermente diversa da quella nominale (pulling), oppure il loop di oscillazione non ha guadagno sufficiente e non parte affatto. Il punto che molti sbagliano è il calcolo delle due capacità C1 e C2 ai piedini del quarzo. Non bastano due condensatori uguali a CL: il quarzo vede la **serie** di C1 e C2, più le capacità parassite del PCB e dei pin del package. La formula corretta è: ```text CL = (C1 · C2) / (C1 + C2) + Cstray ``` con `Cstray` che raccoglie le capacità parassite di piste, piazzole e ingressi dell'oscillatore on-chip — tipicamente 3-5 pF, non trascurabili. Con C1 = C2, la parte serie vale C/2: per ottenere CL = 18 pF con Cstray = 4 pF servono C1 = C2 ≈ 28 pF, non 18 pF e nemmeno 36 pF. Sbagliare questo conto è l'errore numero uno: ci si ritrova capacità troppo alte (il quarzo fatica a partire) o troppo basse (frequenza fuori specifica). Per non rifare il calcolo a mano ogni volta abbiamo messo online un [calcolatore di capacità di carico](/tools/crystal-load-cap/); il ragionamento completo, con i casi limite, è nella [wiki dedicata](/wiki/crystal-load-cap/). ## La UART illeggibile: l'errore di baud rate Il secondo classico arriva subito dopo aver acceso il clock: apri il terminale, ti aspetti il banner di boot, e leggi caratteri spazzatura. Se i caratteri sono completamente casuali, di solito è un baud rate sbagliato in modo grosso. Ma c'è un caso più insidioso — caratteri quasi giusti, qualche byte corretto e qualcuno corrotto, soprattutto sulle stringhe lunghe — che tradisce un **errore di baud rate** entro pochi punti percentuali. La UART asincrona genera il proprio clock di trasmissione dividendo un clock di periferica per un divisore intero (o frazionario, sui MCU più recenti). Il baud rate reale è quindi **leggermente diverso** da quello nominale ogni volta che il divisore intero più prossimo non centra il valore esatto, perché il divisore intero che più si avvicina raramente lo centra esattamente. La differenza percentuale tra baud rate reale e nominale è l'errore di baud. Il problema è che trasmettitore e ricevitore campionano i bit a istanti prestabiliti dentro il frame. Se i due clock divergono troppo, lo scostamento si accumula bit dopo bit e, verso la fine del frame (start + 8 dati + stop), il ricevitore campiona già nel bit successivo. La regola empirica che usiamo: tenere l'errore combinato dei due lati **entro circa ±2-3%**. Oltre quella soglia i frame iniziano a corrompersi, prima sporadicamente, poi sistematicamente. È un bug particolarmente subdolo perché dipende dal contenuto: i caratteri con certe sequenze di bit passano, altri no. La diagnosi è puramente numerica: prendi il clock di periferica reale (attenzione: dopo il PLL, non quello nominale del quarzo — ed ecco perché i due bug sono cugini), il divisore impostato, e calcoli il baud effettivo e l'errore percentuale. Se è sopra soglia, scegli un clock di periferica più "amichevole" (molti progetti adottano i classici 14,7456 o 18,432 MHz proprio perché dividono in baud standard senza errore) oppure un baud rate diverso. Anche qui abbiamo un [calcolatore di errore di baud UART](/tools/uart-baud-error/) e la sua [wiki](/wiki/uart-baud-error/) con la tabella degli scostamenti. ## Il conto prima del cacciavite I due casi hanno la stessa struttura: un valore deciso in fase di progetto che non regge alla verifica, non un componente guasto. Il quarzo che non parte e la seriale illeggibile sono entrambi figli di un conto sbagliato sul clock, fatto settimane prima al momento del progetto schematico. Si diagnosticano con carta e penna, prima ancora di tirare fuori l'oscilloscopio. Verificarli in anticipo, con i numeri giusti, fa risparmiare ore di sonda e tester su una scheda che "non si capisce perché non va". --- Stai facendo il bring-up di una scheda e qualcosa non torna sul clock o sulla seriale? [Parliamone](/contatti/).