ICD3-Debuggen zu Fuß programmieren

[BL1]

Hallo,

ich habe eine Compiler, der von haus aus keine fertige Debug-Funktion zur Verfügung stellt. Wie macht man denn sowas zu Fuß? Steht dazu irgendow, irgendwas zu lesen?


Danke!


BL

[oerni]

Im allgemeinen kann man so etwas über ein zur Verfügung stehendes Ausgabemedium machen.
Das kann alles mögliche sein: optisch mit LCD, TFT, oder Blinklämpchen.
Idealerweise über eine serielle Schnittstelle, wie RS232, I2C, 1-Wire oder auch CAN, Ethernet.

Ausgabe dann über ein aktiviertes oder eben nicht aktiviertes #define

Code:

#define DEBUG

#ifdef DEBUG
   printf("Hallo, ich bin da!!!\n\r");
#endif

Wenn was anderes gemeint war, dann bitte die Frage etwas genauer formulieren.

Tschaui Oerni

[BL1]

Das mache ich ja auch so seit Jahren. Da muß ich michaber Befehlszeile für Befehlszeile langwierig vorwärts robben. Dauert meist Tage und Zeit ist da so ein Problem.
Nur stehe ich jetzt vor so einer Aussetzgeschichte, da wäre es halt schön, wenn ich mal etwas fixer nachvollziehen könnte, wo das S...ding da so hinschwebt.

Beim C18 ist das ja kein Problem. Beim CC5x aber schon. Deshalb aber jetzt noch mit Hightech oder CCS anfangen, löst dasd Zeitproblem aber auch nicht.

Übrigens, wie geht's denn so auf dem F..berg?



BL

[oerni]

Also immer noch mit dem CC5X unterwegs. Der wird doch aber genauso im MPLAB eingebunden und mit dem ICD3 gebrannt.
Und das Ding erlaubt kein Debuggen? Vielleicht doch mal über ein Redesign nachdenken oder den Compiler wechseln.
Ich kenne ja deine kritischen Anwendungen, ich glaube da sollte man nicht sparen.
Die paar hundert Mark sind doch sofort wieder drin, wenn man nicht stundenlang über Probleme grübeln, sondern solange was Sinnvolles machen kann, was dann auch effektiv Kohle bringt.
Oder einmal quer durch Deutschland gefahren, möglichst noch mit Übernachtung und das alles wegen einer Kleinigkeit im Compiler
Ich weis, alles keine schnellen Lösungen.


Man darf mich jetzt übrigends "Head of development" nennen

Tschau Oerni

PS: Ich vermisse übrigends noch ein geborgtes USB Board. Rechnung?!?!

[Edson]

Hallo BL,

du kannst in MPLAB mit File>Import... deine Hex-Datei laden und in der Programmspeicher-Ansicht (View>ProgramMemory) debuggen. Deinen PIC-Typ vorher unter Configure>SelectDevice auswählen.

Gruß,
Edson

[oerni]

@Edson
Der CC5X ist doch im MPLAB eingebunden. Da brauchst du doch nicht mehr importieren.
Das ist ja das, was ich nicht verstehe. Und ein reines HEX-File Debuggen, da kann ich mir schöneres vorstellen.
Ich glaube hier geht es um die FSR und bestimmte Variablen, da das Prog ab und zu mal hängen bleibt. Und genau diesen Zustand zu finden ist das Problem.
Tschau Oerni

[Edson]

Der CC5X ist doch im MPLAB eingebunden. Da brauchst du doch nicht mehr importieren.Das ist ja das, was ich nicht verstehe.

Ja, da hast du schon recht. Aber um welches Problem handelt es sich nun? Kann man mit CC5X (ich benutze das Teil nicht) überhaupt nicht debuggen, oder geht nur der ICD3 nicht?! Vielleicht kann BL da mal was dazu sagen.

Und ein reines HEX-File Debuggen, da kann ich mir schöneres vorstellen.

Nach dem Import steht das Programm mit Disassembly zur Verfügung, man braucht nicht das Hex-File debuggen. Um einem vollkommen "unerklärlichen" Fehler auf die Spur zu kommen, kann das zum Einkreisen des Problems schon ganz hilfreich sein.

Ich glaube hier geht es um die FSR und bestimmte Variablen, da das Prog ab und zu mal hängen bleibt. Und genau diesen Zustand zu finden ist das Problem.

Ja, aber dieses Problem werden wir nicht aus der Ferne diagnostizieren oder gar lösen können. Ich würde auch erst intensiv den Quelltext untersuchen bevor ich mich mit Einzelstep-Debuggen und seinen Schwächen herumschlage.

Gruß,
Edson

[BL1]

Moin,


mal der Reihe nach:

Der CC5x macht (nach Meinung kompetenterer Leute) den schlankesten Code. Deshalb habe ich damals damit angefangen. Gekostet hat es freilich auch Geld, aber das ist halt so.
Nun hat das Ding sicher auch Schwächen, beispielsweise bin ich letztens einer ganz klaren Fehlbehandlung von Variablen auf die Spur gekommen, die so nicht hätte übersetzt werden dürfen. Nur einerseits, wer sagt mir denn, dass andere Compiler nicht andere Bugs haben? Jetzt habe ich mit viel Zeitaufwand diese CC5x-Dinger gefunden. Beim Umstieg kommt der Aufwand des Umschreibens, die neue Lernkurve hinzu und wenn es da auch Bugs gibt, müssen die auch erst gefunden werden. Ich bin das nicht überzeugt, dass ein Umstieg wirklich effektiver wäre. Jedenfalls nicht bei diesem Projekt. Bei einem neuen -und da läuft gerade was an- versuch ich es schon mal mit einem anderen Compiler. In dem Fall mit dem High-Tech.
Aber jetzt hilft mir das erst einmal nicht weiter.

Zum Debuggen.
Der CC5x läßt sich freilich in den MPLab integrieren und theoretisch auch debuggen. Im Simulator geht das auch prima. Aber im Schaltkreis nicht. Da muß man softwaremäßig diverse Änderungen vornehmen, die beispielsweise beim C18(bei den 18ner Pics) schon automatisch fuktionieren. Es geht aber auch mit dem CC5x, nur eben nicht bei mir. Der Compiler bezieht sich lt. Manual auf das Einbinden diverser defines. Nun habe ich aber keinen Überblick, was genau die softwaretechnischen Voraussetzungen sind. Da muß es ja Reservierungen geben.
Außerdem müßte MPLab irgendwie mitgeteilt werden, dass man debuggen will. Der gibt nämlich die Auswahl Debug/Release nicht frei.
Wäre also die Frage, wie man da ran kommt.


Und letztens: Das USB-Bord liegt noch hier. Rechnung oder Rückgabe ist mir eigentlich egal.

[oerni]

Mahlzeit,
ich habe mir nun mal die Mühe gemacht und den CC5X installiert und mein altes MPLAB wieder angeschmissen.
Anhängend ein Bild mit funktionierendem Programm und laufendem Debugger. Dazu ein Oszibild wo man sieht, dass das auch was Sinnvolles macht.
Die Auswahl Debug/Release  spielt fürs Debuggen erstmal keine Rolle, das sind nur verschiedene Einstellungen möglich, um sich den Designprozess zu vereinfachen.
Das Ganze hat 20min. gedauert, um das Handbuch zu suchen und heraus zu finden was fürn #define gebraucht wird. Genau damit werden nämlich die Reservierungen vorgenommen.
Aber wir sind ja nicht kompetent
Bitte mal den PIC Typen angeben. Kann man den überhaupt so einfach debuggen?

Zum Compiler äußere ich mich jetzt mal nicht weiter.

Tschau Oerni

[BL1]

Da ging wohl was in die falsche Kehle?
Die Bemerkung mit der Kompetenz bezog sich nicht auf Euch, da war schon ich selber gemeint. Soweit müßten wir uns eigentlich inzwischen kennen, dass ich hier keine Gemeinheiten durch's Netz jage.

Den #define habe ich auch schon entdeckt. Der steht ebenso drin, wie die Optionen in der Compilerzeile. Im Simulator funktioniert die Geschichte auch. Im Schaltkreis aber nicht.


Dazu hatte ich den lieben Bengt Knudsen mal angeschrieben. Der nun wiederum antwortete:

The symbol ICD2_DEBUG is just a matter of resource reservation so that the compiler does not use resources need for debugging. The program will probably run also if you skip using ICD2_DEBUG. For ICD3 you must look up the reservations yourself and ensure that no overlap with the application occur. ICD2_DEBUG is probably sufficient.

Was ich so verstehe, dass ich mit dem ICD3 selber sehen muß, ob und wo Speicherbereiche o.ä. reserviere.
Es dreht sich um den 16F1827. Deshalb auch der ICD3. Beim 16F819(pinkompatibel) mit ICD2 war es aber das gleiche Problem. MPLab bringt die Fehlermeldung 0040. Die verweißt unter anderem auf ein Linker-Script, mithin auf die Reservierung diverser Ressourcen und dahin zielte die Frage, welche Ressourcen da gemeint sein könnten. In der Beschreibung der Fehlermeldung wird auch auf die Auswahl Release/Debug verwiesen, die man vor dem Compilieren treffen müsse. Die ist bei mir aber inaktiv und wie ich das aktiviere, war der andere Teil der Frage.



BL

[oerni]

Nabend,
ich habe die Schaltung noch mal mit nem 16F819 aufgesteckt.
Das Debuggen funkt einwandfrei. Wichtig ist hier, dass der MCLR bei den Configbits auch als MCLR definiert ist. Sonst läßt er sich nicht debuggen.
Also nicht als I/O PIN !!!
Kanns das gewesen sein?

Die Resourcen vom ICD2 und ICD3 sind die gleichen. Der Knutsen hats nur noch nicht richtig ausprobiert und will sich nicht aus dem Fenster hängen. Bei mir läufts unter Win7/64Bit und MPLAB 8.xx und ICD3.
MPLAB X will der CC5X angeblich noch nicht. Sollte man mal testen.
Nen 16F1827 hab ich leider nicht da, sonst würd ichs mal probieren.

So, muss morgen wieder richtig arbeiten.
Tschau Oerni

[BL1]

Ich kann das derzeit mit dem 819er nicht mehr ausprobieren, weil ich nur mit den fertigen Boards arbeite und da ist inzwischen überall der 1827er drauf. Aber der Fehler, der da irgendwo zu stecken scheint, ist sicher der gleiche. Das Reset-Pin dürfte es aber nicht sein, dass wird im Programm auch als Reset-Pin gebraucht und ist folglich auch so configuriert.

Ich denke eher an den RAM. Mal andersrum gefragt, welche Speicheradressen dürfte man denn nicht benutzen, wenn man debuggen will?


BL

[Edson]

welche Speicheradressen dürfte man denn nicht benutzen, wenn man debuggen will?

Laut MPLAB>Help>Topic>MPLAB ICD3 Help sinds beim 16F1827 folgende File-Register Adressen:

0x245-0x24F und 0xFE3


Gruß,
Edson

[BL1]

Isses auch nich.

Man sieht aber sehr schön, dass die 02er-Adressen mit einem R belegt sind.


Viel simpler, das mit der Kompetenz war schon richtig(so wie ich es gemeint hatte, nicht wie es vemeintlich verstanden wurde).
Man muß im Code die Config-Bits auskommentieren. Ich habe das immer im MPLab gesetzt und das Häkchen rausgenommen, dass er die Config-Bits aus dem Code holt. Das reicht aber nicht, man muß es auch auskommentieren. Dazu muß man offensichtlich alles rausnehmen, WDT, BOR, POR, CP usw..

Jetzt geht's.


Danke!


BL