P-star, XC8, MPLAB, interrupts not triggered

I’m using Code Configurator in MPLAB for the PIC18F25K50 (P-star). I have read through the https://www.pololu.com/docs/0J62/6.1 page. I’m able to use the “Codeoffset” option set to 0x2000 in the project properties->XC8 linker->additional options menu to get my code running on the P-star. However, it looks like interrupts aren’t being triggered (everything else seems to work). There is a function generated by Code Configurator called INTERRUPT_InterruptManager in the interrupt_manager.c file and I’ve added a line of code in that function which [is supposed to] turns on the green LED on the P-star. I’ve also enabled the timer interrupt for various timers, but the LED never turns on. I know the timers are running because the timer counter increments and overflows (as it should), and I’ve ensured the global, peripheral and individual timer (like INTCONbits.TMR0IE = 1;) interrupts are enabled, but still nothing.

I suspect that I might need to also move the INTERRUPT_InterruptManager function to either 0x2008 or 0x2018, but adding any of the following to the function doesn’t seem to make a difference:

@ 0x2008

So the whole line would be something like:

 void interrupt INTERRUPT_InterruptManager (void) __attribute__((address(0x2008)))

I’m not sure if XC8/MPLAB knows to also move the interrupt vector locations when I tell it to use the 0x2000 codeoffset setting. Has anyone else tried using the P-star with XC8/MPLAB and used interrupts successfully? Thanks.

EDIT: it seems like the forum interprets the double surrounding underscores as a bold flag. Bolded “attribute” is actually __ attribute __ with the spaces removed.


I have used interrupts on the P-Star successfully with XC8 and MPLAB X. The “Codeoffset” setting in MPLAB X should be enough to make the interrupt vector be placed at the right location without needing to specify the address manually. You should check to see if there is any code in your main loop that is controlling the green LED, since that code would make it very hard to see what the ISR is doing to the green LED. If that does not help, please make a ZIP file of your entire MPLAB X project directory, including the source code and compiled HEX file, and post it here as an attachment. Please say what inputs you are sending to the P-Star as the code runs, what the expected behavior is, and what the actual behavior is.

In the future, if you want to post code snippets, you should use one of the code formatting options provided by the forum so that the underscores are not interpreted as formatting instructions. For example, you can indent the code by four spaces if it is a block of code or put a backtick (`) before and after the code if it is in the middle of a paragraph. We have edited your first post to fix the formatting.


Hi David,

Thanks for the reply. I plan on starting a new project in MPLAB and trying things again from scratch. The current code is pretty messy since I had been trying a bunch of things to get it working, so I’ll put just the bare minimum in and work from there. I removed all reference to the LEDs in the main function, so it should have only turned on in the ISR (had it been called). It’s good to hear that the codeoffset setting is all that is needed to be modified.

Sorry I missed the code formatting. I thought I did try looking for formatting controls but I guess I missed them. Thank you for editing my original post - it looks much better this way!

Hopefully I’ll be able to work on the project again this weekend a bit, and if so I’ll report back here with my results. Thanks again for your help!

In order to speed up the troubleshooting/debugging process I decided to use a PICkit3 to program the P-star, to skip the button press (to enter bootloader mode) & p-load steps. I find just clicking the Run button in MPLAB is quicker when making many quick little changes to troubleshoot. I realize that erases the bootloader, and so I also reset the codeoffset option back to 0 and manually set the config bits.

Project file: p-star_mcc1.zip (325.2 KB)

  • MPLAB v3.50 (newest at the moment)
  • XC8 v1.40 (newest at the moment)
  • MCC v3.25 (newest at the moment)
  • using codeoffset=0 (since I’m now using a PICkit3),
  • set the configuration bits similar to the ones listed here,
  • MCC generated code with TMR0 and interrupts enabled,
  • TMR0 period is set to about 1 second (with 256 prescaler),
  • nothing in the main loop (except to first enable the global and peripheral interrupts),
  • the only place I touch the green LED is in the void TMR0_DefaultInterruptHandler(void) function, and the only thing I do is to turn it on with LATB7 = 1; (note: I have B7 set to an output rather than an input and switching the TRIS bit to turn it on/off like the P-star example shown here).

Inputs: none - I was using a P-star which was connected to a few things like one of Pololu’s encoder motors & driver boards, a pushbutton & digital hall effect sensor. However, to isolate the problem I decided to try troubleshooting with a spare bare P-star with nothing connected except for the PICkit3 and USB (for power).

Expected: after about 1s the green LED should turn on.

Actual: the green LED never turns on.

If I set the green LED on right before the while (1) loop in the main function the LED turns on as expected, so I know the P-star is at least getting that far.

The MCC-generated code you posted uses this line to set up Timer0:

// T0PS 1:256; T08BIT 16-bit; T0SE Increment_hi_lo; T0CS T0CKI; TMR0ON off; PSA assigned; 
T0CON = 0x37;

Since the T0CS bit is 1, the clock source of Timer0 is the T0CKI pin (RA4), but you are not supplying a clock signal to that pin. Can you try setting T0CS to 0 so that the timer uses the internal clock signal instead? For example, you could set T0CON to 0x17.


Thanks David, that fixed it. I’m not sure why that setting was changed - I didn’t touch it [intentionally] in either my original project or the demo project I created above for this thread. However, I did check my original project and the T0CS bit is NOT set (=0), so I guess it must be something else specific to that project that is messing things up. I’ll try adding things one at a time from my old project to this new one and verify at each step that everything still works. Thank you for getting me to a solid starting point that I can work from!