Senden von Debug-Informationen von MSP430 an die CCS-Konsole

Ich debugge gerade Code, der für den MSP430F2132 geschrieben wurde, der nur sehr wenig Flash-Speicher für das Programm zur Verfügung hat. Um richtig zu debuggen, muss ich Informationen an ein Terminal senden, damit sie gespeichert und zu einem späteren Zeitpunkt angezeigt werden können. Normalerweise würde ich printf oder einen ähnlichen Befehl (vielleicht putchar) verwenden und ihn mit der CCS 6.1-Konsole verknüpfen. Aufgrund des fehlenden Programmspeichers auf dem Mikro kann ich diese Funktionen jedoch nicht nutzen. Ich habe auch nicht die Möglichkeit, das Board zu modifizieren, um einen eingebauten UART-Kanal auf dem Mikro zu nutzen. Ich bin über die USB-Debug-Schnittstelle MSP-FET430UIF mit dem Mikro verbunden, die angeblich eine Rückkanal-UART-Schnittstelle implementiert, aber ich denke, dies erfordert spezielle Verbindungen zum Ziel, die ich nicht habe. Habe ich Optionen, die sehr wenig Speicher beanspruchen und mir erlauben würden, Debug-Informationen zu speichern? Ich muss nur zwei lange Ints pro Zyklus senden.

BEARBEITEN:

Bei näherer Betrachtung (das Design stammt ursprünglich nicht von mir) stelle ich fest, dass die für den MSP-FET430UIF erforderlichen "speziellen Verbindungen zum Ziel" (einfach zu den UCA0RXD- und UCA0TXD-Pins am Zielmikro) vorhanden sind, die Signale jedoch konvertiert werden an RS-485 unter Verwendung von Transceivern auf der Schnittstellenplatine (einer Testhalterung) und der Zielplatine. Vielleicht kann ich doch den FET430UIF-Backchannel-UART verwenden, obwohl ich noch keine guten Anweisungen dazu gefunden habe. Wenn hier jemand Erfahrung damit hat und eine Anleitung geben kann, wäre das sehr hilfreich.

Sie sagen nicht, was letztendlich mit diesen RS-485-Signalen passiert. Können Sie irgendwie an die TXD/RXD-Signale (mit 3,3-V-CMOS-Pegeln) herankommen?
Ich habe noch etwas nachgezeichnet und es scheint, dass diese TXD/RXD-Signale doch nicht mit dem FET430 verbunden sind, wie ich ursprünglich dachte. Stattdessen werden sie mit einem RS232-USB-Chip auf der Schnittstellenplatine verbunden und über ein weiteres USB-Kabel herausgeführt. Ich denke, das könnte mein Ticket sein, ich glaube nicht, dass es in meinem aktuellen Setup eine Möglichkeit gibt, den FET430-Rückkanal-UART zu verwenden
Rückkanal-UART ist schließlich von Natur aus ein einfacher UART. In jedem Szenario werden Sie höchstwahrscheinlich einen COM-Port auf Ihrem PC haben, und es ist irrelevant, wie Sie ihn erhalten. Verwenden Sie einfach einen beliebigen UART, den Sie von Ihrem Ziel erhalten können, und alles wird gut. GL!
Vielleicht nicht so gut wie Sie wollen, aber wenn Sie Platz haben, können Sie Daten in einen RAM-Puffer stopfen, dann das Programm anhalten und mit dem Debugger untersuchen (vielleicht einige Zeit, nachdem das wichtige Ereignis nicht passiert ist).
Ich habe das tatsächlich versucht, aber die Puffergröße musste aufgrund des verfügbaren RAM auf dem Gerät extrem klein sein. Ich konnte schließlich über eine separate UART-Verbindung (nicht über den FET430) mit dem Mikro sprechen, was wirklich alles tat, was ich brauchte. Ich habe die Daten einfach so verschickt, wie sie ankamen, und sie mit PuTTY gesammelt
potenziell verwandte (?) Frage: MSP430 printf() durch Spy-Bi-Wire hängt
@NickAlexeev Ich fürchte nicht, das Problem ist nicht, dass printf() dazu führt, dass die Schnittstelle hängt, das Problem ist, dass es zu viel Codeplatz beansprucht und nicht in mein Design passt. Ich suchte nach einer alternativen Methode zum Senden von langen Ints an die CCS-Konsole, die nicht so viel Codeplatz beansprucht
Bei der Arbeit mit MSP430 habe ich die Software immer mit dem CCS-Überwachungsfenster debuggt, es funktioniert gut und ermöglicht fast Echtzeit-Updates. Vielleicht reicht dir das auch.

Antworten (1)

Wenn Sie über eine funktionierende JTAG-Verbindung verfügen, können Sie den integrierten CCS-Debugger für alle Ihre Debugging-Anforderungen verwenden.

Speichern Sie einfach Ihre Debug-Werte in einem Array und richten Sie optional eine "if"-Klausel mit __no_operation() für einen Haltepunkt ein, um regelmäßig zu überprüfen, was vor sich geht. Oder halten Sie einfach die Ausführung an, nachdem Sie zurückkommen und die gesammelten Daten sehen.

Alternativ können Sie, anstatt das speicherhungrige printf auf stdout zu verwenden, mit fprintf auf stderr schreiben. Es ist bei weitem langsamer und verwendet keine Pufferung, aber für regelmäßige Statusberichte kann es ausreichen.

Senden von Debug-Informationen von MSP430 an die CCS-Konsole
AntwortenHierDatenschutz-Bestimmungen1y, 0v