Svenska ElektronikForumet

När jag kör brytpunkter i ICD2:an under MPLab (assembler) så stannar alltid programmet på raden efter brytpunkten, inte på samma rad. I alla andra miljöer jag kört, oavsett språk, så stannar programmet innan raden med brytpunkten exekveras. Det har alltid varit så här i MPLab, och med tiden har jag vant mig vid det. Till viss del. Men känns rätt avigt.

Är det någon som vet om det verkligen skall vara så? Har jag missat något i dokumentationen, eller? Är det bara jag som tycker det känns avigt?

I simulatorn stannar den väl innan brytpunkten?

ICD2-Debugern har jag inte använt så mycket. Tänkte aldrig på att den stannade efter brytpunkten. Kanske har med hårdvaran att göra.

vfr:
Det är inte så att det bara ser ut som att den stannar efter brytpunkten?
Markören (pilen) stannar på raden där man har satt brytpunkten, men det som står på den raden utförs inte.

T.ex: Sätter man brytpunkten på rad 4 och kör från rad 1 så stannar den på rad 4 utan att ha brytt sig om "nop".
Trycker man F7 ("step into") så går det en klockcykel (nop'en) och så stannar den på rad 6,
redo för att gå in i loopen när man trycker F7 eller F9 (run).


edit: Förtydligade lite.

Jag har faktiskt inte kört simulatorn på väääldigt länge, eftersom jag haft ICD:n. Däremot är jag ganska säker på att den gamla emulatorn betedde sig likadant. Jag kommer inte ihåg vad den hette, men det var en PIC16 ICE med dotterkort för 16C74.

Hmm, jag får nog göra som jag själv förespråkar, ett testcase som jag testar med simulatorn. Just för att se om simulatorn gör samma sak. Men om två ICE:ar har gjort det, så är väl chansen ganska stor att även simulatorn gör det. Jag får försöka hinna med det imorgon.

Edit: Jimmy, nej den har verkligen utfört den raden som den stannar på. Det är precis så som i din sista föklaring med rad 4 och rad 6, som jag tycker att den borde göra.

Skumt...
Jag letade i inställningarna men hittade inget som kan tänkas påverka detta.

Berätta gärna vad du kommer fram till i testcaset.

off-topic:
Här flyter kvällens kodsession ganska fint. Har precis avslutat kodandet/testet av en subrutin och ska ge mig på nästa (2 av 3 för i kväll).

Jag har samma problem. Speciellt när man debuggar i C så kan det vara väldigt störigt när man hamnar i en subrutin som man egentligen skulle vilja stega förbi. Detta gäller både c-18 och C30.

Jag frågade microchip:

The first problem that occur for me is that when I place the breakpoint in the main.c file and run the code, it automatically jupms into the sub-routine. This makes it hard to debug routines that has a while(wait_for_something) inside, because it's not possible to add an extra breakpoint at the "return" in a void function.

svaret jag fick på frågan var:

This is a limitation of the debugger and is mentioned under limitation.
Breakpoints may skid (not halt on the instruction where the breakpoint is located) based on device and type of memory on which they are set, as described below. This is called skidding and is normal. You can easily avoid this by using "Nop"s.
An example:

Nop(); // set breakpoint here
Callingfuction(); // instead of here

This has been reported already and we are in the process of rectifying it. The newer versions of MPLAB IDE should have some kind of fix for this. In the meantime it seems like you already know the workaround.

Tror ni att NI har problem, mitt MPLAB hoppar över mina breakpoint Klickar jag ur och sen i dem igen så fungerar det, högst irriterande. Sen vägrade den att hoppa in i interuptrutinen så fort jag ändrat i den

Funderar på att installera om hela skiten

Snart kommer någon som tappat all sin kod

Ah, du har *det* felet. Det brukar uppstå när man har slitit ut brytpunkterna. Då bryts de på mitten och fungerar inte.

Kanske inte , men det låter som ditt MPLAB skulle må bra av en ominstallation.
Det tar ju inte många minuter alls att installera om och göra inställningarna så man får allt som man vill.

Förresten, vad kör ni för version? Jag kör v7.60.
Installerade om det för några dagar sedan pga att MPLAB envist försökte kompiliera min asm-kod med C(18)-kompilatorn...

> Förresten, vad kör ni för version? Jag kör v7.60.

Eller, för att fomulera om frågan, varför inte alltid köra den senaste ?
OM det inte är något uppenbart större fel med den, så klart...

Tror jag har 8.2 faktist iaf finns den där C-grejjen med (även om jag inte installerade den(tror jag)) 8.3 är den nyaste så så lång efter ligger jag ju inte.

Det är bara i vissa fall det inte fungerar som det ska även fast det borde det, man ser tex att interupten triggats i INTCON.

Tänkte jag skulle uppgradera till nyaste men fram till nu så fungerar det förrutom ovanstående prima