Animate problem

[jpanhalt]

I tested the follow short code piece for a delay with MPLab and had breakpoints at the second decfsz and NOP. The Run command stopped at both. If the decfsz was removed, it stopped at NOP with the desired time on stopwatch. With animate or by stepping into, the program stopped at decfsz when d2 =0, but without decfsz, the program would not go to the NOP. The register for d2 simply rolls over to FF.

Why does Run work, but Animate rolls d2 over to FF? Is there a way to prevent the rollover?

Thanks.

John

Edit: I am using MPLAB 8.10, and the chip is 12F509.

;***** VARIABLE DEFINITIONS
	d1	equ d'9'
	d2	equ d'14'

;**********************************************************************
	ORG     0x3FF             ; processor reset vector
	movlw	0x50
; Internal RC calibration value is placed at location 0x3FF by Microchip
; as a movlw k, where the k is a literal value.

	ORG     0x000             ; coding begins here
	movwf   OSCCAL            ; update register with factory cal value 
	movlw	b'11011011'
	tris	GPIO
	movlw	b'00000000'
	option



start	
	movlw	0x06
	movwf	d1
	movlw	0x08
	movwf	d2
Delay_0
	decfsz	d1,f
	goto	$+2
	decfsz	d2,f
	goto	Delay_0
	goto	$+1
	nop

	END                       ; directive 'end of program'

 

[ericgibbs]

hi John,
Tried your short program using MPLAB IDE 7.6
The MPLAB warned me that that the WDT was active, which I disabled.

With break points at decfsz and the nop [ in the Delay_0 subr ]
Using RUN it would not break at the NOP, until d1 and d2 are zero,,, the decfsz was OK.

Using Animate, with only one break point at the NOP, it stops OK at d2=0

See image.

 

[jpanhalt]

Thanks. I have another machine with an earlier version of MPLab. I will try that a bit later today. I thought maybe it was a known difference between animate/step and run. However, I could find no mention of it (i.e., the roll over with decfsz) in the user guide for MPLab 8.10 .

I do so little programming, that every time I start a new project, there is a new version of MPLab to learn.

John

 

[jpanhalt]

Follow-up

I am perplexed. I tested it on MPLab 7.40 with the same result. I checked to be sure WDT was off and even added a clrwdt to the beginning of the delay.

1) With Run, the delays and breakpoints work as expected. The watch window ends with 00's and the stopwatch is correct for the values of d1 and d2 used.

2) With animate or step, the watch window for d1 and d2 just roll over to FF and the program keeps running.

3) One difference between your screen shot and my watch window is the absence of "__12F509" in the Add Symbol window. My Add Symbol button is grayed out and the field blank. How do you get that button active?

John

 

[ericgibbs]

hi John,
All I added, was this at the head of the program listing.

        list p=12F509
	#include <p12F509.inc>
	radix dec
        errorlevel -302, -207

 

[jpanhalt]

The processor and include files were there, but not copied for the code I posted. I did not have radix or the error files. I doubt the latter would make a difference in the simulation, but I will keep working on it.

My gut feeling is that there is something obvious I am overlooking, which is always frustrating, difficult to find (because I don't have a clue what it is), and leads to a really stupid feeling when it is found.

Thanks for trying to troubleshoot it for me.

John

 

[ericgibbs]

hi John,
Just re-run after lunch, still works OK. image1
It does take a few tens of seconds, real time, to dec to zero.

Are the debugger settings the same as mine, see image2

I'll try it later on my other PC with MPLAB IDE 8.10

 

[jpanhalt]

I've been working on it too. I used the usual Windows approach...just start over from scratch. Built a new project and copy/pasted the asm code. The processor type now appears in the Add Symbol window, and

It worked!

Still don't know why both d1 and d2 rolled over before. d1 stills rolls over, but I believe that is part of the design for the code from the Piclist Delay Code Generator. The last time I wrote any code was a little over 2 years ago. I wrote my own delays at that time, which ran differently. The obvious (stupid) thing was that I didn't look at the Piclist code carefully enough.

Thank you so much for taking the time to help me. It is tremendously helpful to know the code runs in someone else's hands, so I could concentrate on how I was operating the debugger.

Regards,

John

 

[ericgibbs]

hi John,
When I used your code, I started with the MPLAB 'project wizard' and loaded your code that way, perhaps that effects the way the debugger responds to breaks.???

Pommie aka Mike is upto speed on the MPLAB 8.1 .

 

[jpanhalt]

I used the wizard too, both times. I think I just messed up something along the way with the first version. Of course, it compiled fine and seemed to work, including under Run. So, I suspect what I did wrong initially will remain one of the great mysteries...my list just keeps growing.

John