| Viele Softwareentwickler kämpfen gelegentlich mit dem gleichen Problem: Nach dem Kompilieren des Projektes werden „0 Errors“ und „0 Warnings“ angezeigt. Im Debugger funktioniert alles. Nach dem Laden der Applikation in den Flash Speicher funktioniert jedoch nichts. Der Verdacht könnte auf den Flash-Programmier-Vorgang fallen, aber eine CRC Prüfung ergab, dass die Daten mit dem Programm-Code übereinstimmen. Der vom Compiler erzeugte Code sollte in diesem Fall untersucht werden auf: Speicher-Belegung Adressverteilung mehrfach belegte Adressen Um diese Punkte (gerade bei einer größeren Applikation) mit einem Blick erfassen zu können, bietet sich ein Softwarewerkzeug an, das einen Programmcode grafisch aufbereiten kann. |
| Mit HEXit wurde untersucht, welche Adressbereiche von der Applikation im Programm-Speicher belegt wurden. Die grafische Ausgabefläche wurde so eingestellt, dass sie der Größe des verfügbaren Programmspeichers entsprach (64 K Byte). Der von der Applikation belegte Bereich wird farbig- und der ungenutzte Bereich weiß dargestellt. In der von HEXit generierten Grafik ist zu erkennen, dass der Reset-Vektor an Adresse 0 nicht definiert wurde. Da hier eine MCU verwendet wird, deren Reset-Vektor an der Adresse 0 zu liegen hat, kann die Applikation nicht starten. Der erste Fehler ist gefunden. Weiter ist zu erkennen, dass die meisten Interrupt-Vektoren (0x4 – 0x1FF) nicht definiert worden sind. Nicht definierte Interrupt-Vektoren sollten immer auf Funktionen zeigen, die z.B. eine Fehlerbehandlung einleiten können. Geschieht das nicht, kann es zu unkontrollierbaren Reaktionen kommen, wenn z.B. ein vermeintlich passiver Interrupt den nächsten Vektor benutzt, dem eine ganz andere Funktion zugedacht war. |
| Die hier gezeigten Fälle sind nur ein Auszug von Fehlern, die sich typischerweise erst in der Endphase der Softwareentwicklung zeigen, aber mit den Analysemöglichkeiten von HEXit gut in den Griff zu bekommen sind. |