Microchip Studio 7 Data Breakpoint nicht unterstuetzt?

[Wulf D. (holler)]

Moin,
es geht um Microchip Studio 7 mit einem AVR Tiny 2-Series, via UPDI 
angeschlossen.
Habe in einem längeren C-Programm das Problem, dass mir irgendwo eine 
Struktur zerschossen wird. Per Einzelschritt Debugger finde ich den 
fehlerhaften Code nicht. Passiert auch erst nach einiger Zeit.

Ein Data-Breakpoint wäre jetzt genau das richtige. Gibt auch einige 
Hinweise im Forum wo das schon im MS-Studio mit AVR angewendet wird.
Wenn ich den Breakpoint setzen will, erscheint jedoch eine 
Fehlermeldung, dass das Feature nicht mit dem Device & Tool unterstützt 
wird.

Kennt jemand einen workaround?

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Wulf D. schrieb:
> Ein Data-Breakpoint wäre jetzt genau das richtige.

Die Meldung stimmt schon, das kann der Mikrocontroller nicht. Ich meine, 
das geht nur mit JTAG bei wenigen AVR Modellen.

Vielleicht magst du zu STM32F3 wechseln, die können das.

[Wulf D. (holler)]

Ja ok danke, das erklärt das Verhalten.

Aber vielleicht hat noch jemand einen Tipp wie man den fehlerhaften Code 
mit den Mitteln des Debuggers eingrenzen könnte.

HW ist fertig, SW auch fast, bis auf wenige Bugs. Da wollte ich nicht 
wechseln.

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Wulf D. schrieb:
> Aber vielleicht hat noch jemand einen Tipp wie man den fehlerhaften Code
> mit den Mitteln des Debuggers eingrenzen könnte.

Ich sehe keinen Code, keine Beschreibung was er tun soll, keine 
Beschreibung des Fehler. Was erwartest du?

Man kann seriell Log Meldungen ausgeben oder den Status mit einer LED 
anzeigen. Ich bin 20 Jahre lang ohne Debugger aus gekommen.

[Frank K. (fchk)]

Wulf D. schrieb:
> Moin,
> es geht um Microchip Studio 7 mit einem AVR Tiny 2-Series, via UPDI
> angeschlossen.
> Habe in einem längeren C-Programm das Problem, dass mir irgendwo eine
> Struktur zerschossen wird. Per Einzelschritt Debugger finde ich den
> fehlerhaften Code nicht. Passiert auch erst nach einiger Zeit.

Schon probiert, ob MPLABX das kann? Im Gegensatz zum Studio wird das ja 
noch weiterentwickelt.

fchk

[Wulf D. (holler)]

Sherlock 🕵🏽‍♂️ schrieb:
> Wulf D. schrieb:
>> Aber vielleicht hat noch jemand einen Tipp wie man den fehlerhaften Code
>> mit den Mitteln des Debuggers eingrenzen könnte.
>
> Ich sehe keinen Code, keine Beschreibung was er tun soll, keine
> Beschreibung des Fehler. Was erwartest du?

Ich erwarte nicht, dass jemand seitenlang Code reviewed.

> Man kann seriell Log Meldungen ausgeben oder den Status mit einer LED
> anzeigen. Ich bin 20 Jahre lang ohne Debugger aus gekommen.

Im Hobbybereich ist das auch ok. Die LED ist natürlich mit einer kleinen 
Prüfroutine ist drin und die geht nach einiger Zeit auch an.

Die werde ich jezt nach und nach in jeden Unterprogrammzeig hängen und 
irgendwann findet man die fehlerhafte Stelle.

Aber vielleicht geht es eleganter.

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Frank K. schrieb:
> Schon probiert, ob MPLABX das kann?

Wie gesagt: Es liegt am Chip.

[N. M. (mani)]

Nicht direkt debuggen, aber führt vermutlich auch ans Ziel:
Linte mal deinen Code!

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Man kann regelmäßig den freien Speicher und Stack ausgeben.

[Wulf D. (holler)]

N. M. schrieb:
> Nicht direkt debuggen, aber führt vermutlich auch ans Ziel:
> Linte mal deinen Code!

Gute Idee, sollte im ersten Schritt erstmal alle Warnings durchgehen. Da 
sind noch etliche nicht auf Relevanz geprüft.

[Peter D. (peda)]

Wulf D. schrieb:
> Habe in einem längeren C-Programm das Problem, dass mir irgendwo eine
> Struktur zerschossen wird.

Ich würde mal einen RAM-Dump ausgeben, was genau und wie zerschossen 
wird. So viel RAM kann das ja nicht sein.

[Wulf D. (holler)]

Sherlock 🕵🏽‍♂️ schrieb:
> Man kann regelmäßig den freien Speicher und Stack ausgeben.

Auch gut, geht schnell über die eh vorhandene UART.

[Wulf D. (holler)]

Peter D. schrieb:
> Wulf D. schrieb:
>> Habe in einem längeren C-Programm das Problem, dass mir irgendwo eine
>> Struktur zerschossen wird.
>
> Ich würde mal einen RAM-Dump ausgeben, was genau und wie zerschossen
> wird. So viel RAM kann das ja nicht sein.

Vielen Dank: im grün umrandeten Bereich liegt die zerschossene Struktur, 
da hat sich ein String drüber gelegt. Das sollte leicht zu finden sein!

[Wulf D. (holler)]

War ein nicht abgefangener Bufferüberlauf. Läßt sich schnell beheben.

Jetzt muss ich nur noch den logischen Fehler finden, warum überhaupt so 
viele Daten einlaufen. Aber das ist eine andere Geschichte.

Danke für die kontruktiven Tipps!

[Peter D. (peda)]

Wulf D. schrieb:
> War ein nicht abgefangener Bufferüberlauf.

Ich nehme vorzugsweise den sizeof Operator. Dann muß man keine magischen 
Nummern hinschreiben und kann die Größe nachträglich scnell ändern.