Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Interrupts and MPLAB debug mode

Status
Not open for further replies.

edeca

Active Member
I have been running some code under the MPLAB debugger with the Junebug. I was trying to teach myself how to use interrupts, mainly from the 18F1320 datasheet rather than code online. Although slow, the debugger is pretty neat, even if the one breakpoint limit sucks.

I spent a while going crazy though as my breakpoint in the ISR didn't ever hit. I read something vague online that suggested interrupts don't fire if using debug mode. Is this correct?

The same code with GIE and TMR0IE disabled and a simple test of the overflow flag works and provides a delay. The LED macro is from the Junebug manual.

I have disabled the code that I used to setup the interrupts and removed the code at org 0x04 which I presumed would handle the interrupt. If anybody can spot anything wrong with what I did, please say.

Code:
Start	bcf	T0CON, TMR0ON
;	bcf	INTCON, TMR0IE

	movlw	b'01000101'
	movwf	T0CON			; Enable Timer0

	clrf	TMR0L
	clrf	TMR0H
				
	bcf	INTCON, TMR0IF		; Clear Timer0 flag
;	bsf	INTCON, TMR0IE		; Enable Timer0 interrupt
;	bsf 	INTCON, GIE		; Enable global interrupts

	bsf	T0CON, TMR0ON

	bsf	ADCON1, 0		; Digital IO, disable A/D

LED1	LED b'00000001', b'10111110'

Loop	btfss	INTCON, TMR0IF
	goto 	Loop
		
	movlw	b'0000001'
	xorwf	LATA	
	bcf	INTCON, TMR0IF
	goto	Loop
 
I have disabled the code that I used to setup the interrupts and removed the code at org 0x04 which I presumed would handle the interrupt. If anybody can spot anything wrong with what I did, please say.

The interrupt vector is located at 0x0008 for the PIC18. Also, interrupts have a priority feature. By default they all have high priority, but if you enable low priority interrupts, their vector is at address 0x0018. That's illustrated by figure 5.2 in the datasheet.
 
The interrupt vector is located at 0x0008 for the PIC18. Also, interrupts have a priority feature. By default they all have high priority, but if you enable low priority interrupts, their vector is at address 0x0018. That's illustrated by figure 5.2 in the datasheet.

Argh! I spent a while wondering if the location had changed for the 18F devices but couldn't find anything in the datasheet so dismissed it :)

Thanks for the pointer, I hadn't read that chapter thoroughly. Interesting that you don't get much room for the high priority interrupt service routine (start at 0x08 and the low priority one starts at 0x18). Does this change how the routine is written?
 
Argh! I spent a while wondering if the location had changed for the 18F devices but couldn't find anything in the datasheet so dismissed it :)

Thanks for the pointer, I hadn't read that chapter thoroughly. Interesting that you don't get much room for the high priority interrupt service routine (start at 0x08 and the low priority one starts at 0x18). Does this change how the routine is written?

You don't have to squeeze the routine into that space; you jump from the interrupt location to the interrupt service routine which can be located elsewhere.
 
I spent a while going crazy though as my breakpoint in the ISR didn't ever hit. I read something vague online that suggested interrupts don't fire if using debug mode. Is this correct?
Interrupts do work in debug. But sometimes waiting the thousands and thousands of cycles for them is impossible, as the debugger steps thru instructions very slowly. There are times where you have to write some test code that will trigger the interrupt quickly, but still tell you whether what you're trying to test is working. It can be difficult. And there are some things you just plain can't do with a debugger.

The Run-To-Cursor command is your friend for this kind of thing. I just put the cursor on the first line in the ISR, right-click the mouse and select run to cursor. The program runs full speed till the IRQ hits. Or do the same thing with a breakpoint in the ISR.

If it never hits, then your interrupt isn't getting triggered. Look at your IRQ setup, the TRIS's, your hardware trigger(s) (if any) and stuff like that. Check that the interrupt flag in question is getting cleared properly. All the usual suspects. :D
 
When the debugger is used with the Junebug, RUN causes the target to execute code at full speed up to the point where it hits a breakpoint. Step Into, Step Over, and Animate are slow because they update the UI for each line.

I like to use the 18F1330 in place of the 18F1320 unless I need peripherals the 1330 does not have. The 1330 has 3 breakpoints and can be up to 4 times faster using the internal clock and PLL (32MHz instead of 8). The UI seems to work better with the faster target.
 
The PLL only works with external HS oscillators, but 8MHz will get it going.

Add
Code:
movlw 0x72
movwf OSCCON

to the beginning of your program
 
When the debugger is used with the Junebug, RUN causes the target to execute code at full speed up to the point where it hits a breakpoint.

Thanks all for the hints, that's useful. I didn't realise that different parts had different numbers of breakpoints.

I was setting the breakpoint and running to it, the UI is far too slow to update otherwise! I have been used to this sort of debugging with x86 ASM for a while but it is much nicer seeing it work with a micro.
 
I've just installed MPLAB 8.14 and one of the enhancements is faster 32kHz debug :)
- 64-bit USB Drivers – USB drivers for Windows Vista 64-bit operating system allows MPLAB ICD 2, MPLAB REAL ICE and other tools using USB interfaces to operate in both Windows 32-bit and 64-bit platforms (XP-64 and Vista-64).
- Fast Stepping with 32 kHz Oscillators
– Debugging targets at 32 kHz can be slow, since data speeds between MPLAB IDE and the device are rates limited by the clock speed. MPLAB IDE will switch to a faster internal oscillator when communicating to the device to speed up debugging.
 
Last edited:
I've just installed MPLAB 8.14 and one of the enhancements is faster 32kHz debug :)

Fantastic, I'll be downloading that first thing tomorrow. Have they fixed the annoying bug in the step over routine where it stops 1 instruction late and leaves you at the start of the next subroutine you wanted to step over.

Mike.
 
Fantastic, I'll be downloading that first thing tomorrow. Have they fixed the annoying bug in the step over routine where it stops 1 instruction late and leaves you at the start of the next subroutine you wanted to step over.

Mike.
My guess is the problem is with monitor on the PICs and not MPLAB itself. The monitor on the PIC causes execution to stop at (near) a breakpoint. MPLAB just reports what it is fed.

I would be happy if they fixed the phantom/hidden breakpoint. The one that comes into play when you move between ICD and simulator with breakpoints set.

They claim to have persistant bookmarks working.
 
Last edited:
I don't really care where the bug is, Microchip wrote both pieces of software and therefore only they can fix it. BTW, this doesn't happen with ICD2, just with Pickit2. With the Pickit2 if you step over a call instruction it executes the instruction after the call returns. If this is another call instruction then you find yourself at the start of the subroutine and have to single step through it.

Mike.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top