Att välja en debug-/programmeringskontakt för en mikrokontroller

TL;DR sammanfattning: för ARM SWD, TI Spy-Bi-Wire eller Microchip ICD, använd Tag-Connect No-Legs footprint med standard pin/pad-tilldelningar, och skaffa Tag-Connect-kablar.

När man designar enheter som använder mikrokontrollers måste man tillhandahålla en kontakt för felsökning och programmering. Denna kanske bara används för utveckling, när man skriver och felsöker programvara, eller kan också lämnas kvar i produktionsenheter för programmering i fabriken.

Tillverkare och verktygsmakare såg till att vi lever i en värld där det finns en mängd debug-kontakter med mycket förvirring kring dem. Det är därför vi slutar med detta:

Så, vilket kontaktdon ska man välja för en ny design?

Den här artikeln fokuserar främst på ARM-enheter som har SWD-gränssnittet (Single-Wire Debug), men den är också tillämplig på andra komponenter, som Texas Instruments MSP430 som använder Spy Bi-Wire-protokollet (2-tråds JTAG), Microchip ICD, eller till och med komponenter som behöver en mer komplett uppsättning JTAG-stift.

Populära felsökningskontakter

Några av de vanliga valen som ofta övervägs:

• 10-stifts JTAG på en 0,1" IDC-stiftlist. Vanligtvis används en hanlist. Nackdel: den är enorm och stiftlisten kostar pengar.
• Cortex Debug Connector med en 0,05" mikrostiftlist (10-stifts eller 20-stifts, Samtec FTSH-110 och FTSH-105). 10-stiftskontakten är någorlunda liten och tillgänglig som en SMD-komponent, men dyrare än IDC-kontakter.
• 20-stifts 0,1" IDC-kontakt. Du överväger väl inte seriöst den dinosaurien? Den är större än vissa av korten jag designat.
• Anpassad uppsättning av 4 eller 6 stift (eller via-hål, eller kopparpads). Problemet här är "anpassad". Det kommer oundvikligen att bita dig i framtiden, den dagen din anpassade kontakt går sönder på fabriksgolvet och du måste frakta en ny från utlandet medan produktionen står stilla.
• Tag-Connect 6-stifts footprint i en av varianterna (med ben eller utan ben). Observera att det inte finns någon kontakt här: bara ett standardiserat footprint på mönsterkortet.
• Tag-Connect 6-stifts + Tag-Connect 10-stifts (för ETM-signaler): för denna kombination finns det till och med en färdigbyggd kabel tillgänglig, med en 20-stifts IDC-kontakt och standard ARM Cortex 20-stifts stifttilldelning.

En omedelbar observation är att de flesta av dessa kontakter kräver, ja, kontakter. Det är en extra komponent som du måste placera på kortet, vilket kostar pengar. För produktionsenheter eller större prototypserier kommer den kontakten bara att användas en gång under produktens hela livstid, vilket är ett slöseri.

Tag-Connect-lösningarna eller anpassade footprints med pogo-pin-baserade kontakter har en uppenbar fördel här genom att de inte kräver att några komponenter placeras på kretskortet, så kostnaden för debug-kontakten per kort sjunker till 0, vilket är fantastiskt!

Så här ser en Tag-Connect-footprint ut på ett riktigt kretskort:

Och så här ser kabeln med pogo-pins ut: Det andra stora övervägandet är storlek och resulterande krav på kortutrymme. De enda utmanarna är 10-stifts 0,05" mikro-stiftlisten och ett Tag-Connect 6-stifts avtryck. 10-stifts mikro-stiftlisten är faktiskt lite mindre i en riktning, men skillnaden är inte signifikant. Så här ser en 10-stifts 0,05" mikro-stiftlist ut (denna är från ett Nordic Semiconductor nRF52832 utvecklingskort, PCA10040):

Ben eller inga ben?

Det finns två varianter av en Tag-Connect-kabel: en med "ben" och en med "utan ben". Vad är skillnaden?

Tag-Connect använder pogo-stift, som har fjädrar inuti och trycker mot kretskortet. Om du vill att kontakten ska sitta kvar måste du kontinuerligt applicera kraft på den. Detta fungerar bra för snabb programmering, där du kan använda en hand för att hålla kontakten på plats och en annan för att starta programmeringsjobbet, men det fungerar inte så bra för längre felsökningssessioner. För det fungerar "legs"-fotavtrycket (och kontakten) mycket bättre. Benen fungerar som små klämmor, så när du sätter i kontakten snäpper de på plats och håller pogo-stiften tätt mot kortet under obegränsad tid.

Problemet med avtrycket med "ben" är dess storlek: det är betydligt större än varianten "utan ben". Vad som är värre är att det kräver fyra stora hål i kortet. Stora hål är alltid ett problem: de måste (uppenbarligen) passera genom alla lager, och du behöver ett keepout-område runt dem också. Detta innebär att påverkan av ett avtryck med "ben" på din design är mycket större än varianten "utan ben".

För produktionsenheter, där anslutningen sannolikt bara kommer att göras en gång under produktens livstid, och enkelt kan hållas för hand hela tiden, är det ingen tvekan: du föredrar definitivt fotavtrycket "utan ben", vilket sparar kretskortsutrymme. Men vad ska man göra med prototyperna? Å ena sidan har du råd med kretskortsutrymmet, men å andra sidan vill du inte designa om kretskortet bara för att du behöver ta bort hålen i den slutliga revisionen.

Lyckligtvis finns det en annan lösning. Tag-Connect säljer en liten fästklämma. Det är en bit kretskort med tre socklar som passar stiften på Tag-Connect-kabeln. Det är inte en mekaniskt perfekt lösning och klämmorna tenderar att slitas ut med tiden (de är också otroligt lätta att tappa bort!), men i praktiken fungerar det ganska bra.

Min rekommendation är att alltid välja footprintet utan ben och kablar, köpa ett gäng fästklämmor, och spara på kortutrymme och omdesign av korten.

Använd en standardiserad signaltilldelning

Jag har sett hårdvara i verkligheten där designers använde en Tag-Connect-footprint för ARM SWD (på en Cortex-M0), men tilldelade signalerna annorlunda. Det är troligt att motivationen var att dölja gränssnittet.

Detta är inte något jag skulle rekommendera: fördunklingen upptäcks lätt, och man slutar med ett inkompatibelt fotavtryck, vilket oundvikligen kommer att orsaka problem i framtiden.

Praktiska detaljer

Tag-Connect rekommenderar att inga komponenter placeras (eller ledare dras) på andra sidan av footprinten. Även om det är en bra rekommendation har man inte alltid den lyxen, särskilt på små kort med snäva layoutbegränsningar.

Som jag har upptäckt kan man komma undan med att placera komponenter på andra sidan, även när man använder fästklämman för att hålla kabeln på plats. Jag skulle dock föreslå att man använder en bit isolering mellan komponenterna och fästklämman för att förhindra eventuella kortslutningar (papper fungerar bra). Även om det inte är rekommenderad praxis, fungerar detta, även om det blir lite mer komplicerat att fixera debug-kontakten på plats.

Här är ett exempel på ett prototypkort (ursäkta prototypens lödkvalitet) där komponenter är placerade inom området för debug-fotavtrycket:

Kritik

Allt är inte guld och gröna skogar med Tag-Connect. Webbplatsen är inte välorganiserad, så det är svårt att hitta informationen man letar efter. Det finns en mängd varianter som erbjuds, och även om de flesta människor behöver en enda typ av kabel, visas den inte tydligt. Tyvärr verkar detta vara en tradition hos företag som tillverkar debug- och programmeringsutrustning i den inbyggda världen.

Det andra klagomålet jag har är att företaget erbjuder nedladdningsbara CAD-bibliotek med Tag-Connect-avtryck, men anger att:

Dessa filer tillhandahålls i befintligt skick och utan garanti för att de är kompletta, felfria eller lämpliga för användning. Kontrollera noggrant de importerade dekalerna mot det senaste databladet som tillhandahålls på Tag-Connects webbplats (se nedan). Kontrollera särskilt hålstorlekar, stiftnumrering och var extra uppmärksam på lödpastamasklagret för att säkerställa att ingen lödpasta deponeras på footprint-paddarna.

Om du tittar i de medföljande ZIP-filerna finns det vanligtvis flera footprint-varianter för en given CAD. Vilken ska jag använda? Och varför är det mitt ansvar att verifiera det?

Jag tycker att Tag-Connect borde städa upp i detta bibliotek och tillhandahålla en uppsättning stödda footprints, åtminstone för de mer populära CAD-paketen, utan en friskrivningsklausul. Det borde vara en del av värdet i denna lösning.

Slutsats

Sammantaget är Tag-Connect fortfarande den bästa färdiga lösningen för felsökning och programmering. Jag rekommenderar att standardisera på den och använda den i alla dina konstruktioner.