De professionele gids voor debuggingtools en -technieken voor IoT-apparaten

De ontwikkeling van een ingebed systeem, waarbij de software en hardware mooi op elkaar moeten aansluiten, is uiterst complex en vormt een grote uitdaging, zelfs voor wat misschien de eenvoudigste Internet of Things (IoT)-apparaten lijken. Zozeer zelfs, dat wanneer er iets fout gaat - wat onvermijdelijk het geval zal zijn - het opsporen van fouten meestal geen paar uur in beslag neemt, maar weken of maanden kan duren. Deze vertragingen brengen extra ontwikkelingskosten met zich mee, zorgen ervoor dat een product niet op tijd op de markt kan worden gebracht, vertragen de productieschema's en vernietigen leveringsketens en bedrijfsplannen.

De beste manier om minder tijd te besteden aan debugging en een project op de rails te houden is gebruik te maken van een combinatie van hardware debugging tools en vrij beschikbare software om inzicht te krijgen in hoe een systeem presteert en waar de problemen zich voordoen. Zowel voor professionals als voor hobbyisten is het dus van groot belang dat zij over het juiste gereedschap beschikken om de klus snel en correct te klaren.

In dit artikel worden ontwikkeltools en software besproken die kunnen worden gebruikt om de prestaties van een IoT-apparaat te debuggen en te analyseren. Er zal gebruik worden gemaakt van een ontwikkelbord van STMicroelectronics als voorbeeld van een IoT-apparaat, en de tools en software van SEGGER Microcontroller Systems zullen worden gebruikt om het systeem te begrijpen en te debuggen. Er zullen ook verschillende tips en trucs worden besproken over hoe u de debugtijd kunt minimaliseren en een IoT-project op tijd kunt opleveren.

Het typische IoT-apparaat om te debuggen

IoT-apparaten zijn gemeengoed geworden in bijna elke bedrijfstak, van het slimme huis tot industriële bewakingscontrole. Ondanks de grote verscheidenheid aan toepassingen zijn er een aantal typische componenten die een IoT-apparaat zal hebben. Dit zijn:

• Een microprocessor
• Een radio voor connectiviteit
• Sensors

Een ontwikkelaar zal zijn eigen bord niet op maat willen draaien om debugtechnieken te verkennen of stukjes van zijn applicatiecode te testen. Het is gewoon te tijdrovend. In plaats daarvan is het verstandiger om te werken met een goedkoop ontwikkelbord zoals de B-L4S5I-IOT01A Discovery Kit voor IoT-knooppunt van STMicroelectronics. Deze heeft bijna alles wat op een typisch IoT-apparaat te vinden is (Afbeelding 1).

Afbeelding 1: De STMicroelectronics B-L4S5I-IOT01A Discovery Kit voor IoT-knooppunt bevat alle componenten die typisch vereist zijn in een IoT-apparaat. (Bron afbeelding: STMicroelectronics)

Het bord bevat de STM32L4S5VIT6, een Arm® Cortex®-M4 microcontroller met een snelheid van 120 megahertz (MHz). Dit wordt ondersteund door maximaal 2 megabytes (Mbytes) flash en 640 kilobytes (Kbytes) RAM. Belangrijk voor het doel van deze oefening is dat het bord Wi-Fi en een overvloed aan sensors bevat, die kunnen worden gebruikt om snel een mock IoT-testapparaat te bouwen.

Professionele hardware-apparatuur voor foutopsporing

Bijna elk ontwikkelbord heeft een onboard JTAG/SWD-interface, zodat ontwikkelaars niet hun eigen programmer hoeven te kopen. In plaats daarvan kunnen ze direct uit de doos met het ontwikkelingsbord werken. Hoewel dit geweldig is voor marketingdoeleinden, is het niet geweldig voor echte engineering: on-board debuggers zijn vaak drastisch verkleinde versies die beperkingen hebben, zoals het aantal beschikbare breakpoints en de interface baud-rate. Voor niet-ingewijden lijken deze beperkingen misschien niet veel voor te stellen, maar het hebben van onbeperkte onderbrekingspunten vermijdt het voortdurend in- en uitschakelen van onderbrekingspunten, en snelle baudsnelheden zijn nodig voor het traceren van toepassingen (meer over traceren in de softwaretoolssectie).

Er zijn verschillende tools beschikbaar die een professionele debug-ervaring kunnen bieden, maar de hulpmiddelen zelf zijn slechts de helft van de oplossing. De tools moeten worden ondersteund door goede software. Een toolset die er zowel qua hardware als software uitspringt is de SEGGER J-Link serie. Deze serie heeft een debugger versie voor bijna elk type ontwikkelaar, van studenten en hobbyisten tot hardcore professionals.

Uit ervaring is gebleken dat twee modellen het nuttigst zijn voor de algemene ontwikkelaar: de J-Link Base en de J-Link Ultra+ (Afbeelding 2). Qua vormfactor zijn de twee units identiek, maar de J-Link Ultra+ biedt de ontwikkelaar hogere downloadsnelheden naar het RAM (3 Mbyte/s tegenover 1,0 Mbyte/s) en een snellere SWD-interfacesnelheid (100 MHz in plaats van 30 MHz). De hogere snelheden maken het verschil wanneer een ontwikkelaar zijn toepassing wil traceren om inzicht te krijgen in de prestaties en het RTOS-gedrag, en zijn systeem wil debuggen.

Afbeelding 2: De SEGGER J-Link Ultra+ biedt ontwikkelaars een verbeterde debugger-ervaring dankzij een 50 MHz target interface. (Afbeelding bron: SEGGER Microcontroller Systems)

Het leuke van de J-Link en de B-L4S5I-IOT01A ontwikkelingskaart is dat de twee kunnen worden verbonden via een Tag-Connect TC2050-IC-NL-kabel en de TC2050-CLIP-3PACK-houderclip. Deze maken het mogelijk een debugger aan te sluiten op het ontwikkelingsbord via het "spijkerpad" (Afbeelding 3). Het kan nodig zijn de 20-pins connector van de J-Link aan te passen aan de 10-pins connector van de TC-2050-kabel. Een optie die hiervoor kan worden gebruikt is de 8.06.04 J-Link 10-Pin Needle Adapter.

Afbeelding 3: Op het B-L4S5I-IOT01A-ontwikkelbord kan de Tag-Connect kabelassemblage worden aangesloten door middel van een spijkerbed-achtige printplaatafdruk (rechts). (Bron afbeelding: STMicroelectronics)

Zodra een ontwikkelaar dit pad aan de hardwarekant heeft afgesloten, kan hij de softwaretools gebruiken om zijn toepassing te analyseren en te debuggen.

Professionele debugging softwaretools

Er zijn nogal wat softwaretools die heel goed werken met de SEGGER J-Link tools, die verrassend genoeg niet door SEGGER worden geleverd. Hieronder zullen we een aantal van deze gratis tools bekijken en zien hoe ontwikkelaars ze kunnen gebruiken om hun software te debuggen.

Als eerste is er J-Scope. J-Scope is een oscilloscoop-achtig instrument dat variabele waarden in de tijd weergeeft. Ontwikkelaars kunnen één variabele of enkele tientallen variabelen controleren. Merk echter op dat naarmate meer variabelen worden bewaakt, minder monsters kunnen worden genomen voordat de monsterbuffer overloopt en gegevens verloren gaan.

Variabelen worden geselecteerd door J-Scope te voorzien van het elf-bestand dat door de compiler wordt uitgevoerd. Dit levert de geheugenplaatsen op die moeten worden gelezen, en de ontwikkelaar kan dan zijn bemonsteringsfrequenties instellen en volgen hoe de variabele(n) in de tijd veranderen. Een eenvoudig voorbeeld van een spoor met drie variabelen is te zien in Afbeelding 4.

Afbeelding 4: J-Scope kan worden gebruikt om variabelen via de J-Link te monitoren terwijl een toepassing in real-time draait. (Afbeelding bron: SEGGER Microcontroller Systems)

De volgende is Ozone. Ozone is een debugger-interface en prestatie-analysator. Ontwikkelaars kunnen hun elf-bestand in het programma laden en debugging op bronniveau uitvoeren. Zij kunnen breekpunten instellen en hun code bijwerken. Een bijzonder nuttige functie voor ontwikkelaars is dat zij ook instructies kunnen traceren (indien hun hardware dit ondersteunt) en kunnen nagaan welke assemblage- en C-codestatements zijn uitgevoerd. Dit is bijzonder nuttig voor het verifiëren van code coverage van hardware-in-loop (HiL) testen.

Ozone kan ontwikkelaars ook helpen de prestaties van hun systeem te analyseren (Afbeelding 5) en variabelen in de tijd te visualiseren. Dit biedt mogelijkheden zoals J-Scope, maar op een meer geïntegreerde manier. Het kan zelfs worden gebruikt om het stroomverbruik te monitoren en al deze gebeurtenissen op één plaats te synchroniseren.

Afbeelding 5: Ozone kan worden gebruikt om variabelen via de J-Link te traceren terwijl een toepassing in real-time draait, naast code coverage en RTOS-bewuste debugging. (Afbeelding bron: SEGGER Microcontroller Systems)

Een derde hulpmiddel is SystemView. SystemView stelt ontwikkelaars in staat om het runtime gedrag van hun RTOS systeem te analyseren. Het omschakelen van taken wordt vastgelegd in een traceerbuffer en vervolgens via de debugger gerapporteerd aan SystemView (Afbeelding 5). SystemView geeft deze informatie vervolgens weer op een manier die een ontwikkelaar in staat stelt hun contextschakelaars te zien en de prestaties van hun systeem te meten. Dit is ook een geweldige manier om een systeem te visualiseren en bugs en andere problemen te vinden.

Afbeelding 6: SystemView biedt een link naar een RTOS waarmee ontwikkelaars taakprestaties kunnen meten en kunnen visualiseren wat het RTOS aan het doen is en wanneer het dat doet. (Afbeelding bron: SEGGER Microcontroller Systems)

Tips en trucs voor het debuggen van een ingebed systeem

Voor het debuggen van een IoT-apparaat moeten ontwikkelaars zowel over de juiste hardware- als over de juiste softwaretools beschikken. Beide onderdelen moeten aanwezig zijn als ontwikkelaars de tijd die ze besteden aan debugging tot een minimum willen beperken. Om succesvol te debuggen, zijn er verschillende "tips en trucs" die ontwikkelaars in gedachten moeten houden, zoals:

• Gebruik een professionele debugger die de interface baudrate maximaliseert. De hoeveelheid nuttige gegevens die uit een systeem kan worden verkregen, zal afhangen van de snelheid waarmee die gegevens kunnen worden ontvangen. Lagere snelheden resulteren in een langere debug-sessie.
• Stel de debug software vroeg in de ontwikkelingscyclus in. Ontwikkelaars moeten niet wachten tot ze een probleem hebben om hun debugging tools op te zetten.
• Gebruik traceerinstrumenten vanaf het begin van de ontwikkeling. Hierdoor kunnen ontwikkelaars de prestaties van hun systeem in de gaten houden en onmiddellijk begrijpen hoe softwareveranderingen deze beïnvloeden.
• Gebruik instructietracing of programmatellerbemonstering om tijdens het testen inzicht te krijgen in de systeemcodedekking. Bugs zullen bestaan in ongeteste voorwaardelijke takken en code.
• Gebruik maken van snelle overdrachtsprotocollen om gegevens van de chip te halen, zoals de Real-time Transfer (RTT) bibliotheken.

Ontwikkelaars die deze "tips en trucs" volgen, zullen merken dat ze heel wat tijd en verdriet kunnen besparen wanneer ze een IoT-apparaat proberen te ontwikkelen.

Conclusie

De software voor IoT-apparaten is complex geworden, maar dat betekent niet dat professionele of hobbyistische ontwikkelaars voortdurend moeten blijven steken in het debuggen van hun systemen. Het gebruik van professionele ontwikkelingstools en -software kan ontwikkelaars de inzichten verschaffen die zij nodig hebben om niet alleen een systeem te debuggen, maar ook om de prestaties van hun systemen te analyseren en te verbeteren. Door in deze hulpmiddelen te investeren, kunnen gebruikers de tijd die aan debugging wordt besteed drastisch verminderen, en hun projecten binnen een redelijk tijdsbestek aan de praat krijgen en op de markt brengen.