Announcement

Collapse
No announcement yet.

U2 P'gmr "Target device does not match selected device" error

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • U2 P'gmr "Target device does not match selected device" error

    I have been using the U2 programmer to program several different 16F part numbers with no problems. Lately have been working with 16F886. Simple circuit and program to read 3 pots (0-5V) and display A to D readings on LCD. Program worked fine for 20 to 30 code changes (and reprogramming) but when I made a simple change got the "Target device does not match selected device" error. Replaced the 16F886 and all OK for a while then same error occurred. Tried a new chip, OK for a while then same problem. I guess i'm destroying the chips!! Using PBP default config with no #CONFIG block in my code.
    SO- Any idea on why I am burning up chips??
    Thanks
    Peter

  • #2
    Static?

    Originally posted by PeterS View Post
    I have been using the U2 programmer to program several different 16F part numbers with no problems. Lately have been working with 16F886. Simple circuit and program to read 3 pots (0-5V) and display A to D readings on LCD. Program worked fine for 20 to 30 code changes (and reprogramming) but when I made a simple change got the "Target device does not match selected device" error. Replaced the 16F886 and all OK for a while then same error occurred. Tried a new chip, OK for a while then same problem. I guess i'm destroying the chips!! Using PBP default config with no #CONFIG block in my code.
    SO- Any idea on why I am burning up chips??
    Thanks
    Peter
    I had this problem some time back. Two actions solved the problem I experienced. First when installing the device into the programmer or circuit, discharge all static by first touching a ground point to drain the static before touching the device. Next, in another programmer (not MeLabs) a 1 or 2 mFd cap across the chip power pins with short leads was needed for proper operation.

    Comment


    • #3
      Originally posted by J2017G View Post
      I had this problem some time back. Two actions solved the problem I experienced. First when installing the device into the programmer or circuit, discharge all static by first touching a ground point to drain the static before touching the device. Next, in another programmer (not MeLabs) a 1 or 2 mFd cap across the chip power pins with short leads was needed for proper operation.
      Hi, Peter S here. Thanks for the suggestions. Yes, I am good about static but, no, I did NOT have a bypass cap. As an EE I should know better.
      I'm not sure either of these caused my problems. I removed ALL IDE, compiler and programming tools and reinstalled them. I have not had the problem since and, JOY JOY, all my PIC's are programming and working fine.

      Comment


      • #4
        Hello! Hope it's alright to comment like this on an older thread, but I am having a similar symptom. However, my problem was caused by my own mistake. Basically, if you program a device (specifically here, the PIC16F628A) with MCLR as an input and using an internal oscillator, you can put your device into a state where it can no longer be programmed! As I understand it, this is because the device starts running its code as soon as it gets power, and the MCLR pin, used for programming, is no longer available. This is fairly well documented, both on the ME Labs support page (http://melabs.com/support/icsp.htm) and elsewhere (http://www.electro-tech-online.com/t...problem.14248/).

        My question is this - now that I have created this problem for myself, is there any way to recover these chips? In the second link above, the gentleman talks about hard wiring the Vpp pin to 13v using his programmer, but I don't think I have the same option using the ME Labs USB device. I could conceivably add an additional power supply with a common ground and do essentially the same thing, but I don't want to damage my programmer. Anyone have similar issues with clever solutions?

        Thanks in advance!


        Respectfully,
        Marshall

        Comment


        • #5
          It helps to place the chips in one of our programming adapters, as opposed to in-circuit programming on your board. Since the programmer controls power to the adapter, it has a better chance of breaking into programming mode immediately after power-up.

          In the meProg software, click Options > More Options, then disable "Verify Target Device ID". This will minimize the time between adapter power-up and the erase command transmit.

          After that, click the Erase button on the toolbar (or CTRL-E) repeatedly until you get a successful erase. It doesn't always work, but I've had reasonable success.

          Remember to enable Verify Target ID when finished.

          To help avoid the problem in the future, place a 1 or 2 second pause at the beginning of your code, before the programming pins are changed to outputs. This will sometimes give the programmer a window of opportunity after the chip is powered, but before the TRIS change that locks the programming pins.
          Charles Leo
          ME Labs, Inc.
          http://melabs.com

          Comment


          • #6
            Charles, is this just on the older MCUs? I've never ran into that problem with the 2007+ products assigning MCLR as an input pin. I do usually use your U2 Programmer, for what it's worth.

            Comment


            • #7
              I don't know for sure, but it seems to me that I don't encounter it as much as I used to. It could be more common on older chips.

              I'm not certain the issue was correctly described early-on, either. My perception of it has changed over the years. I think it may have more to do with setting the programming pins as outputs than the MCLR pin being an input. Then again, it may be a different cause on different chips.
              Charles Leo
              ME Labs, Inc.
              http://melabs.com

              Comment

              Working...
              X