目标设备ID（0x0）是无效的设备ID

通常这是YEP连接的问题，或者是硬件问题，除非你的程序员断了…



      以下为原文

    Usually it's a problem with yep connections, or anyway hardware.
Unless your programmer got broken...

谢谢你回到我身边。如前所述，我的PICTIT3与集成电路板上的PIC18连接。好像有什么东西被损坏了，但我不知道该怎么改正。任何想法都会有帮助。谢谢



      以下为原文

   


Thanks for getting back to me. As mentioned, my pickit3 is connected to my pic18 on an integrated board. It seems likely that something got damaged, but I am at a loss as to how I would correct this. Any ideas would be helpful. Thanks

芯片也可能坏了。但99%的时间是连接问题，例如连接引脚向后，忘记跳线，坏接触，插入不良，功率差…



      以下为原文

    Chip could have gone bad too. But 99% of the time it's a connection problem, e.g. connecting pins backwards, forgetting jumpers, bad contacts, bad insertion, bad power ...

我意识到这一点，但我的问题是，无论如何我都不知道我能检查连接。昨天我成功地完成了计划，但今天我没有任何问题。同样，PICTIT3直接集成到PIC18-我从来没有担心连接。我想我们可能破坏了连接，但我真的说不出来。这是我的开发板附带的数据表，它是专门为我目前正在学习的课程而设计的。



      以下为原文

   


I realize this, but the issue that I have is that I don't know of anyway that I can check the connections. I was able to successfully program as of yesterday, but today I have been having no issue. Again, the pickit3 is integrated directly to the pic18 - never have I had to worry about the connections. I suppose its possible that we damaged the connections, but I really cannot tell. 
 
Here is the datasheet that comes with my development board - it was designed specifically for this course that I am currently taking. 

有PRG/Run模式的幻灯片开关。也许开关的接触是坏的或错误的。你可以试着来回滑动来清洁接触。



      以下为原文

    there is a slide switch for PRG/RUN mode.  Maybe the contact of the switch go bad or erroneous.  You can try to slide it back and forth to clean the contact.

这可能有助于扩大销钉范围。您应该在VPP、PCLK和PDAT上看到干净的信号。



      以下为原文

    It may help to put a scope on the pins. You should see clean signals on Vpp, PCLK, and PDAT.

1）检查MPLAB XC8编译器中的PUCIT3的UR项目属性…2）检查适当的电源配置。3）将PICTIT3重新连接到U R板。



      以下为原文

    1) check u r project properties for pickit3 in MPLAB XC8 compiler...
2) check proper power configurations.
3) Re-connect the pickit3 to u r board.

奇怪的是，我现在也突然看到了这种行为，稍微有些不同。我不是想劫持线程，而是希望更多的信息可以为每个人解决一个解决方案。我有一个全新的ICD3。我们的装配车间使用ICD3进行生产编程，所以我想运行他们的过程，以确保在生产开始之前一切都不会发生意外。我也有一个用于比较的PACKIT3。我编译了.xEx文件，我们将在XC8PRO模式下把它交给装配室。如果写入程序员的PACKIT3去模式，它完全闪烁到目标PCB。但是如果你使用MPLAB X的“导入”函数（文件/导入/ HEX/ELF），我得到同样的“目标设备ID（0x0）是一个无效的设备ID。请检查你的连接到目标设备”错误消息。ICD3和PICTIT3都是真的。在MPLAX中，当一个独立的.HEX文件工作在“导入”时，但是如果在PTG模式下写入到PICTIT3，这个完全相同的HEX文件工作得很好。因为文件在PTG模式下运行良好，所以我假定文件是OK的。因为当MPLAB X处于正常（非“导入”）时，PICTIT3工作得很好。“模式”，我认为没关系。因为当MPLAB X处于常规（非“导入”）模式时，ICD3工作良好，我认为它是可以的。这使我很可能是MPLAB X的“导入”模式。不幸的是，这就是我们的装配室接受HEX文件用于生产编程的原因。我曾温和地建议使用IPE或命令行工具，但却有很多阻力。我在这里张贴，是因为线程基于相同的错误消息。但在我的例子中，我已经证明了连接是有效的（因为编程在非导入模式下是成功的），程序员自己在工作，目标PCB的工作，等等。大多数“通常的嫌疑犯”都是好的。但也有同样的错误信息，有人有什么想法吗？以前见过这个吗？希望知道如何改正？谢谢！



      以下为原文

    Oddly, I am now suddenly seeing this behavior too, with a slightly different twist. I'm not trying to hijack the thread, but hoping that additional information might tease out a solution for everyone.
 
I've got a brand new ICD3. Our assembly house uses ICD3's for production programming, so I wanted to run through their process to make sure everything works with no surprises before production starts. I've also got a PICkit3 to use for comparison.
 
I compiled the .HEX file that we will hand off to the assembly house in XC8 Pro mode. If written to the PICkit3 in Programmer To Go mode, it flashes perfectly into the target PCB's. But if you use MPLAB X's "import" function (File / Import / Hex/ELF), I get this same "Target Device ID (0x0) is an Invalid Device ID. Please check your connections to the Target Device" error message.
 
This is true with BOTH the ICD3 and the PICkit3. Neither one seems to work with a standalone .HEX file when "imported" via MPLAB X. But if written to the PICkit3 in PTG mode, this exact same hex file works perfectly.
 
Since the file works fine in PTG mode, I presume the file is OK.
Since the PICkit3 works fine when MPLAB X is in regular (not "import") mode, I presume it's OK.
Since the ICD3 works fine when MPLAB X is in regular (not "import") mode, I presume it's OK.
 
This leaves me with the probable culprit being the "import" mode of MPLAB X. Unfortunately, that's how our assembly house accepts hex files for production programming. I've gently suggested using IPE, or command line tools, but got lots of resistance.
 
I'm posting this here because the thread is based on the same error message. But in my case I have proven that the connections are valid (since programming is successful in non-import mode), the programmers themselves are working, the target PCB's are working, etc. Most of "the usual suspects" are known to be good. Yet there's the same error message.
 
Anyone have any ideas? Seen this before? Hopefully know how to correct it?
 
Thanks!

导入模式假设您已经告诉MPLABX正在使用什么PIC。



      以下为原文

    The import mode assumes you have already told MPLABX what PIC is being used.
 

一个更多的信息：两个程序员报告的设备类型准确地作为PIC18F26K80。我假设这是从板上的物理硬件读取的，因为我不认为设备类型存储在HEX文件中。然后，他们将“AP”固件编程给程序员，以准备与该设备一起使用。只有在“AP”固件闪现到程序设计器之后，它才能再看到设备类型。我假设“AP”是固件，它是特定于设备的固件，它必须在ICD3或PICTIT3中运行，以便它与每个设备或家庭一起工作。CE类型足以获得合适的固件，但此后再也看不到设备类型了。



      以下为原文

    One more tidbit of info: Both programmers report the device type accurately as PIC18F26K80. I presume that is being read from the physical hardware on the board since I don't think the device type is stored in the hex file. They then program the "AP" firmware to the programmer in preparation for use with that device. It is only after that "AP" firmware is flashed to the programmer that it can no longer see the device type.
 
I presume "AP" is programming firmware that is device specific which must be running in the ICD3 or PICkit3 for it to work with each device or family.
 
Kind of odd that it can determine the device type well enough to obtain the proper firmware, but thereafter can't see the device type anymore....

宾果-你是对的！根据您的评论，我检查了MPLAB X为导入“项目”配置了什么。原来是一个不同的后缀部分-正确的家庭，甚至正确的前缀，但错误的后缀。一旦我有力地纠正了这一点，编程就奏效了。它明确地读取正确的设备直接从硬件，以获得适当的AP固件为程序员。它必须至少使用一部分数据来配置项目（否则，它将如何得到“接近”，但使用了我们从未使用过的零件号？）但它只得到了90%的解决方案…毕竟，它仍然需要人工干预来选择合适的部分。谢谢小费。我只是希望我能理解为什么这是必要的！



      以下为原文

   
Bingo - you're correct!
 
Based on your comment I checked what MPLAB X had configured for the import "project". Turned out to be a different suffixed part - correct family, even correct prefix, but wrong suffix. Once I forcefully corrected that, programming worked.
 
This is remarkable. It definitely reads the proper device straight off the hardware in order to obtain the proper AP firmware for the programmer. It must use at least part of that data to configure the project (otherwise how would it have "gotten close", yet used a part number we've never used here?). Yet it only got to a 90% solution... after all of that, it still requires manual intervention to select the proper part.
 
Thanks for the tip. I just wish I understood WHY it is necessary!

我过去有过这个问题。如果你连续几次重复（比如5次），它就会开始工作，至少在我身上发生过这样的情况。



      以下为原文

   


I had this problem in the past. If you repeat this back-to-back several times (like 5), it'll start working, at least that was happened to me.

真的！这是第一次。通常，精神错乱的定义是反复做同样的事情，同时期待不同的结果。听起来像这样的精神病终于有了回报！{GRIN }



      以下为原文

    Wow! That's a first. Normally the definition of insanity is doing the same thing over and over while expecting different results. Sounds like in this case insanity finally pays off! {grin}