Where do you set break points in source code

Thread Starter

anukalp

Joined Jul 28, 2018
158
I am looking tips on breakpoints in code debugging. Breakpoints are one of the most important debugging techniques to solve the problem

For example, in the following code Where do you set break points in source code to see variables value
C:
#define _XTAL_FREQ 8000000

#include <xc.h>

// BEGIN CONFIG
#pragma config FOSC = HS // Oscillator Selection bits (HS oscillator)
#pragma config WDTE = ON // Watchdog Timer Enable bit (WDT enabled)
#pragma config PWRTE = OFF // Power-up Timer Enable bit (PWRT disabled)
#pragma config BOREN = ON // Brown-out Reset Enable bit (BOR enabled)
#pragma config LVP = OFF // Low-Voltage (Single-Supply) In-Circuit Serial Programming Enable bit (RB3 is digital I/O, HV on MCLR must be used for programming)
#pragma config CPD = OFF // Data EEPROM Memory Code Protection bit (Data EEPROM code protection off)
#pragma config WRT = OFF // Flash Program Memory Write Enable bits (Write protection off; all program memory may be written to by EECON control)
#pragma config CP = OFF // Flash Program Memory Code Protection bit (Code protection off)
//END CONFIG

int main()
{
  TRISB0 = 0; //RB0 as Output PIN
  while(1)
  {
    RB0 = 1;  // LED ON
    __delay_ms(1000); // 1 Second Delay
    RB0 = 0;  // LED OFF
    __delay_ms(1000); // 1 Second Delay
  }
  return 0;
}
 

dl324

Joined Mar 30, 2015
16,846
Breakpoints are a debugger notion. You don't need to put anything explicit in your code. You set them (by line number) in the debugger.

It looks like you're writing code for a microcontroller. If it doesn't have an operating system, then you'll probably need to use print statements; possibly to a serial port.
 

AlbertHall

Joined Jun 4, 2014
12,345
Looks like Mchip XC8 compiler. If you're using this with a PICKIT then when it stops at your chosen breakpoint you can display values in ram or SFRs within the IDE. Where you put the breakpoint depends on which part of the code you want to check.
 

Thread Starter

anukalp

Joined Jul 28, 2018
158
Looks like Mchip XC8 compiler. If you're using this with a PICKIT then when it stops at your chosen breakpoint you can display values in ram or SFRs within the IDE.
I have MPLABX IDE and XC8 compiler. I think I have to wait for PICKIT I don't have PICKIT now.

I thought I can do software debugging without hardware PICKIT

Assume there two variable declare in the code TRISB0, and RB0

I would set first break point in following line to check the Pin RB0 is high or Low
Code:
TRISB0 = 0; //RB0 as Output PIN
then I would set break point in following line to check the LED is On or OFF
Code:
  RB0 = 1;  // LED ON
It looks like you're writing code for a microcontroller. If it doesn't have an operating system, then you'll probably need to use print statements; possibly to a serial port.
I didn't get your point
Do you mean something like this:
Code:
    if(TRUE)
        {
        print("This should be printed");
        }
    if(FALSE)
        {
        print("This should NOT be printed");
        }
 
Last edited:

AlbertHall

Joined Jun 4, 2014
12,345
I have MPLABX IDE and XC8 compiler. I think I have to wait for PICKIT I don't have PICKIT now.

I thought I can do software debugging without hardware PICKIT

Assume there two variable declare in the code TRISB0, and RB0

I would set first break point in following line to check the Pin RB0 is high or Low
Code:
TRISB0 = 0; //RB0 as Output PIN
then I would set break point in following line to check the LED is On or OFF
Code:
  RB0 = 1;  // LED ON
I didn't get your point
Do you mean something like this:
Code:
    if(TRUE)
        {
        print("This should be printed");
        }
    if(FALSE)
        {
        print("This should NOT be printed");
        }
You can indeed do debugging without a PICKIT using the simulator built into the IDE. This system allows you to set many breakpoints.

TRISB0 would usually be used to set RB0 as an input or output rather than to set the pin high or low.
 

jpanhalt

Joined Jan 18, 2008
11,087
TRISB0 would usually be used to set RB0 as an input or output rather than to set the pin high or low.
TRISB0 is set to output. Making a pin high or low using TRIS can be done, but is frowned on by some, as TRIS is also subject to RMW error. Depending on the chip it is better to use LATB, a mirror register, or just write to the pin. Of course, the letter is subject to RMW, but that is no worse than doing bit writes to TRIS. I have read that C uses a "bsf" like command when making a bit write.

Edit: There have been a few discussions here on RMW instructions with TRIS. Here is just one: https://forum.allaboutcircuits.com/...ram-the-pic10lf322.150246/page-3#post-1286576
 

Thread Starter

anukalp

Joined Jul 28, 2018
158
My question was where to set the break point in a source code to find problem

Take a example If I had interfaced Led with PiC but that was faulty but I didn't knew it was faulty. We can also use multimeter to check voltage on PIC Pin but That is another topic. I am talking only about software debugging.

Where do you set break point to check Led ?

I would set break point in this line RB0 = 1; //LED ON

C:
#define _XTAL_FREQ 8000000

#include <xc.h>

// BEGIN CONFIG
#pragma config FOSC = HS // Oscillator Selection bits (HS oscillator)
#pragma config WDTE = ON // Watchdog Timer Enable bit (WDT enabled)
#pragma config PWRTE = OFF // Power-up Timer Enable bit (PWRT disabled)
#pragma config BOREN = ON // Brown-out Reset Enable bit (BOR enabled)
#pragma config LVP = OFF // Low-Voltage (Single-Supply) In-Circuit Serial Programming Enable bit (RB3 is digital I/O, HV on MCLR must be used for programming)
#pragma config CPD = OFF // Data EEPROM Memory Code Protection bit (Data EEPROM code protection off)
#pragma config WRT = OFF // Flash Program Memory Write Enable bits (Write protection off; all program memory may be written to by EECON control)
#pragma config CP = OFF // Flash Program Memory Code Protection bit (Code protection off)
//END CONFIG

int main()
{
  TRISB0 = 0; //RB0 as Output PIN
  TRISD0 = 1; //RD0 as Input PIN

  RB0 = 0; //LED Off

  while(1)
  {
    if(RD0 == 0) //If Switch Pressed
    {
      RB0 = 1; //LED ON
      __delay_ms(3000); //3 Second Delay
      RB0 = 0; //LED OFF
    }
  }
  return 0;
}
 

jpanhalt

Joined Jan 18, 2008
11,087
My question was where to set the break point in a source code to find problem
There is no generic answer to that. You need to understand the code and try to figure out how far it is working correctly.

With firmware and/or hardware, I will run the code or step through it in a watch window, and if it hangs, stop execution. Often that will be somewhere near the trouble spot, e.g., some loop that isn't being exited. Generally, when stepping through code, you will need to disable or drastically shorten most delays that are more than a few microseconds, unless you have a lot of time to waste.

With hardware, another approach I use to to set up a trouble-shooting LED. Then light it at various points in the code.
 

MrChips

Joined Oct 2, 2009
30,720
My question was where to set the break point in a source code to find problem
This is a rather odd question. It is like asking "Where do I look to find my misplaced house key?"

A breakpoint is one tool used for debugging computer code. You do not have to use a breakpoint to do this.
A breakpoint is a static diagnostic tool.
It can give you information on the state of the machine before a particular line of code is executed.
It can give you information after a particular line of code has been executed.
It can provide information on which path of the program has been taken.
It allows you to single step your code so that you can observe how registers, flags, and memory are being affected by the execution of code.

Dynamic (or real-time) diagnostics include using embedded print statements, flashing LEDs, and/or use of an oscilloscope.
 

atferrari

Joined Jan 6, 2004
4,764
Breakpoints are good to stop program execution so you can change the value of one or more registers prior a certain line is executed.
 

BobaMosfet

Joined Jul 1, 2009
2,110
Breakpoints are not one of the most important tools in debugging-- although they can really be useful! It is entirely possible to debug quite well through other means-- leaving a trail of breadcrumbs is one of the most useful in any coding language.

One of the most useful tools I made for debugging in a micro-controller environment, was simply outputting information to a serial port and capturing that information on a PC, while the embedded code ran through a failure point. Outputting hex values like a string, like this:

4145AA00AA034BAA00AA0342AA00AA02AA0EAA0E

Some values are predetermined, to identify what function I'm looking at, and when I see it, my tool can parse X number of next hex values into the appropriate form. Output ends up being something like this:

Code:
--------------------------------------------------------------------------------------------------------------
       0.   Key Down Interrupt Called                                   [A] INT2-0
       1.   - Interrupt Accepted. Determine Row/Col & Key               [E] INT2-1
                <Row (Y): 0 / Col (X): 3>
       6.   Y,X Keypress to Byte                                        [K] GETCHARFROMROWCOL
                <Val: 'A'>
      11.   - Queue An Event                                            [B] CREATEEVENT
                <Event 'what': 0010>
                '14 / 0x000E / 00001110'                                    <Val: 14/'*'>
                '14 / 0x000E / 00001110'                                    <Val: 14/'*'>
Very useful.
 
Top