PIC16F in-circuit debugging issues with 20MHz oscillator

Discussion in 'Embedded Systems and Microcontrollers' started by Robin66, Jun 13, 2016.

  1. Robin66

    Thread Starter Member

    Jan 5, 2016
    102
    3
    Hi. I spent most of yesterday trying to get ICD in MPLAB X IDE working with the pickit3 on a PIC16F882. I finally got it working but here are some observations:
    1. I started off with the CONFIG1 of h'20f2' ie. debugging disabled, external crystal. I changed this to h'00f2', however this wasn't reflected when inspecting the config memory in MPLAB X IDE. ICD still didn't work.
    2. I then switched to the onboard 4MHz oscillator ie. CONFIG1 = h'00f5'. This change was reflected in the config memory (even tho it showed h'20f5'). ICD started working but I can't find anything in the documentation about ICD not working with 20MHz external crystal.
    3. I could only have 1 breakpoint at a time. Creating a new breakpoint greyed out the prev breakpoint. I'm not sure why this is a limitation.
    4. I was using the ADC and saving the result to custom vars, however the vars seemed to be updated unreliably when I inspected then in MPLAB. I have my suspicions whether MPLAB's memory inspection is trustworthy.
    Any comments appreciated. Annoyingly I can't remember the exact version of MPLAB I'm using, but I think it's ~v3.2
     
  2. jpanhalt

    AAC Fanatic!

    Jan 18, 2008
    5,680
    900
    Question #3 With hardware debugging you have a limited number of breakpoints compared to software debugging. Some chips only allow one. The chip I currently use allows 3 (16F1829). It is a limitation imposed by the complexity (from the Microchip side) of doing hardware debugging.
    Some options:
    1) Do software debugging first. I use MPLab SIM.
    2) Use a chip that allows more breakpoints. Do you have any enhanced mid-range chips (i.e., 16F1xxx)?

    John
     
    Robin66 likes this.
  3. Robin66

    Thread Starter Member

    Jan 5, 2016
    102
    3
    Thanks John. Yes I already do software debugging first. To be honest a single breakpoint isn't an issue because as soon as it's hit I can place my next bp downstream. I just wanted to understand the limitation. Thanks for taking the time to explain.

    Also, I noticed the code actually stops on the line *after* the bp. Any idea why this would be?
     
    Last edited: Jun 13, 2016
  4. jpanhalt

    AAC Fanatic!

    Jan 18, 2008
    5,680
    900
    Here's a presentation on hardware vs. software breakpoints:
    http://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en556761.pdf

    BTW, when I referred to software debugging, I was referring to using MPLab SIM or similar. There is also a "software" breakpoint mentioned in that Microchip link. It appears in my debugging menu like this:
    upload_2016-6-13_6-31-6.png
    That breakpoint is different from the ones used in the MPLab SIM.

    John
     
  5. Robin66

    Thread Starter Member

    Jan 5, 2016
    102
    3
    Very useful. I see the 1 instruction lag in halting is called a "skid". Re. software debugging, I use the simulator built into MPLAB X IDE. There are some video tutorials on this which I used to get going. There doesn't seem to be so much support for hardware debugging, so this presentation is a real help.

    Robin

    PS. and now I know why step over doesn't work (but step into does) with my hardware bps.
    PPS. and now I know about the existence of data bps. They should prove a useful tool
    PPS. I now see the distinction between software debugging and simulating. I've only been simulating thus far.
     
    Last edited: Jun 13, 2016
Loading...