Debugging-Problem: MPLAB X IDE v5.15, ICD3/ICD4, dsPIC33FJ128MC706A

[Uli N. (uln)]

Ich arbeitet mich gerade in ein Board mit einem dsPIC33FJ128MC706A unter 
Verwendung des MPLAB X IDE v5.15 mit dem ICD4 ein und habe ein Problem 
beim Debuggen - wenn ich die Funktionen "Step Over", "Step Out", "Run to 
Cursor" verwende oder einen Breakpoint setze, läuft der Debugger einen 
Schritt zu weit!

z.B. in main.c

 x  function1();
    function2(); 
    function3();
    function4();

Ich setze eine Breakpoint auf function1(), der Debugger hält aber 
innerhalb der Funktion function1().

void function1(void) 
{ <= hier!!! 
    irgendwas1();

Führe ich ein "Step Out" aus, landen ich nicht auf function2(), sondern 
innerhalb der Funktion function2()

void function2(void)
{ <= hier!!!
    irgendwas2();

Steppe ich statt dessen mit "Step Into" durch function1(void), bis ich 
auf function2(void) stehe und führe dann einen "Step Over" durch, lande 
ich nicht auf function3(), sondern wieder innnerhalb der Funktion 
function3().

void function3(void)
{ <= hier!!!
    irgendwas3();

Setze ich nun den Cursor in main.c auf function4() und führe ein "Run to 
Cursor" aus, lande ich nicht wie erwartet beim Cursor, sondern wieder 
innerhalb der Funktion function4(void).

void function4(void)
{ <= hier!!!
    irgendwas4();

Ich kann mir nicht vorstellen, dass das so sein soll, weil meiner 
Meinung nach unbrauchbar!? Oder kennen das die PIC-Anwender unter Euch 
nicht anders und das Verhalten ist so gewollt?

[soso... (Gast)]

U. L. schrieb:
> Ich arbeitet mich gerade in ein Board mit einem dsPIC33FJ128MC706A
> unter
> Verwendung des MPLAB X IDE v5.15 mit dem ICD4 ein und habe ein Problem
> beim Debuggen - wenn ich die Funktionen "Step Over", "Step Out", "Run to
> Cursor" verwende oder einen Breakpoint setze, läuft der Debugger einen
> Schritt zu weit!

Wenn du Hardware-Breakpoints verwendest, ist das normal.

Warum das so ist, siehe auch:
http://ww1.microchip.com/downloads/en/DeviceDoc/Software%20breakpoints.pdf
Im Endeffekt stoppt der µC, wenn er eine bestimmte Adresse erreicht hat. 
Dann führt er aber noch alle Instruktionen in der Pipline aus.

Wenn du das nicht willst : Du kannst Software-Breakpoints verwenden, die 
das Verhalten nicht aufweisen. Da werdem in den Code "Break" 
Intruktionen eingefügt. In der Präsentation findest du die jeweiligen 
Vor- und Nachteile.

Der Hauptnachteil der Software-Breakpoints ist, dass sie das Flash 
abnutzen, denn für jeden Breakpoint muss eine Flash-Page programmiert 
werden. Sie sind außerdem langsam, das kann Konsequenzen haben - setzt 
man einen Breakpoint, wird der µC für einige ms angehalten, weil eine 
Flash-Page programmiert werden muss.

Hardware-Breakpoints haben das Problem nicht. Der Hauptnachteil der 
Hardware-Breakpoints ist das von dir beschriebene Verhalten.

Wie du Software Breakpoints verwenden kannst:
http://microchipdeveloper.com/mplabx:use-software-breakpoints

Mich hat es viel graue Haare gekostet, weil ich nicht verstanden habe, 
wie Breakpoints funktionieren. Es lohnt sich daher, die oben verlinkte 
Präsentation zu lesen und zu verstehen!

[soso... (Gast)]

Sorry, habe ich vergessen:
Das Verhalten betrifft nicht alle PICs. PIC32 haben das Problem 
beispielsweise nicht.

Für zukünftige DSP-Geschichten würde ich die dsPIC33 überdenken. Es gibt 
inzwischen die Motorcontrol-Serie PIC32MK:
https://www.microchip.com/design-centers/32-bit/pic-32-bit-mcus/pic32mk-family
Der hat DSP-Extensions, eine FPU und schnelle ADCs.

[Uli N. (uln)]

Danke für die schnelle Antwort,
gleichwohl ich vernehmen muss, dass das kein Bug, sondern ein Feature 
ist ;-)

[soso... (Gast)]

U. L. schrieb:
> gleichwohl ich vernehmen muss, dass das kein Bug, sondern ein Feature
> ist ;-)

Die hätten mal einfach per Default Software-Breakpoints einschalten 
sollen, dann hätte es nie jemand gemerkt.

Die Teile halten 10k Schreibzyklen aus (bei 125°C), Bei Raumtemperatur 
vermutlich ein vielfaches. Da ist der Nachteil mit der Endurance sehr 
akademisch.