error message: "can't verify device number 1"

[Altera_Forum]

Hi, 

 I am the newest member here.  I am getting an error message "can't verify device number 1". The device is EPM1270T144C5. It was programing OK for a while, then the error came up.  My computer and JTAG cable are fine, they work for programing other hardware, including the same type device (EPM1270T144C5).  I can detect the device, and I can erase it. I can not program it. It did go through the erase phase but it can not program.   The FAE sugested trying another IC, so I changed IC's on my PCB, and the programing worked a couple of times, and now I get the same error message.  I have only one device in the chain.  I just upgraded to the newest software (Quartus Web Edition 8.0), and that did not help either.   I looked up the help and the knowladge base, but still no clue.   I would greatly appreciate help.  Regards Dan

[Altera_Forum]

I see two possible causes: 

 1. The device is actually defective (or number of programming cycles has been considerably excceded)  2. The programming circuit or device power supply are not confirming to specifications, so only some device accesses are succesful by chance.

[Altera_Forum]

Thank you FVM for answering. 

 As I stated, I did replace the device on the PCB, and the new device programed a couple of times, then it did the same thing - "can't verify device number 1". The number of times the new device was programed was 3 times, the third one did not work.   The power supply measures 3.44V (with a very good meter) and I also looked with a scope. The supply is clean.   The first device programed OK about 3 dozen times before the problem showed up. All that made me suspect a faulty printed board (broken trace, or what not).  I started building the second PCB, so far I have only the Altera soldered (including the 3.3V regulator, pins for the JTAG cable and various bypass caps). I just wanted to see if I can send the same *.pof file to another board. The result is positive, the new partialy built board is working.   So unless I can find the problem, I will have to finish a second prototype (200+ parts), and given a dealine (a show), I am less then thrilled.  I checked the JTAG connections many times (Ohm meter and scope) and they seem fine. I am starting to suspect some open power pin or ground pin somewhere. Some of those intermitent problems seem OK when you touch with a probe, then open up when you remove the probe.  The PCB is a multilayer board, and as a prototype, it gets flexed more then a final product. This is though to find, because some of the power and ground feedthrough are under the TQFP 144 pin Altera pakage.  I am speculating that the lack of varification, or any progarming related JTAG action requires only the 4 JTAG lines and power + ground to be connected, and all the other IO pins are "out of the way". Given that the IC has a lot of power and ground pins, I wonder if there is a specific pair (or pairs) of power and ground that are there for the JTAG, for a EPM1270T144.   Of course my thinking may be wrong. It may be that someting is "marginal", or intermitant. I have nothing to back it up. I have been around (63 years old), and it just "feels" like it.  Thanks again. I would appreciate your additional thoughts, and other Altera Gurus thoughts and sugestions regarding how to narrow it down.   Regards Dan

[Altera_Forum]

Hello Dan,  

 I generally agree with your assumption that no other pins than power supply/ground and dedicated JTAG signals should play a role in JTAG configuration. Particularly bank 1 VCCIO and VCCINT are needed to operate the JTAG interface. There are some hints in the MAX II device handbook regarding possible JTAG problems, e.g. the possibility of temporary VCCINT droop due to current spikes during programming or the necessisty of having defined TCK and TMS levels during power up. Although I never had similar JTAG problems with any Altera device either CPLD or FPGA, I would expect something of this kind. Also bad solder joints as you mentioned may be possible cause, but less likely to my opinion.  Regards, Frank

[Altera_Forum]

Hello again, 

 I looked in the JTAG literature, chapter 11 in the IN-System Programibility Guidelines for MAX II devices. It sugested to check the TCK, and have it pulled down to Ground with 1K. According to the scope (100MHz bandwidth), the signals are very clean, no overshoots, no double pulses...  I did not see any referance to "startup voltages" at power up. I will try to find it.  Meanwhile, I figured out the following:  In the programing window, there are 3 rows. The top row specifies files (for the *pof), device, checksum, user code, the there are the boxes to check mark - program, verify, blank check, security and earse.   The second row has check marks for CFM, and the third row for UFM.  My programer completes the program and verify tasks when I check the CFM boxes only. The programer fails ("can't verify device number 1") when I try to program the UFM only. It can not everify the UFM.  The device does not function after I program the CFM (with or without verify). I guess there is some reason for it, but I do not undersatnd it. I thought that programing the CFM will have the user flash section work, and the user flash memory not work, but that is not the case here.  I do use the UFM, but I tried programing other files, as simple as a single input and output with an inverter between, and that does not work either - same error message.  My second board (not too populated yet, with only Altera, 3.3V regulator and bypass caps) does program. But I am nervous, because the first board programed fine about 3 dozen times before failing. In fact, it came to life for about 3 program cycles when I changed the IC. I programed the second board about 10 times, to see that it is working. So far it is OK. I will have the other parts soldered, but I am nervous about it.   The power supply is the same for both boards, and has been used for many programing tasks. I am still very confused. The layout is good, many bypass caps and a 3.3V linear regulator (from a clean 5V source)...  I wonder if the ability to program the UFM means that the JTAG is working fine, and the problem is elsewhere. The device is not heating up at all, so I would rule out latching.  Regards Dan

[Altera_Forum]

Hi again, 

 I need to make a big correction. The device DOES work when I program the CFM section only. It does require to turn the power off then on, but then it works.   I did not see it, because normaly, I see all sorts of LED's On and the front panel switches function as well after programing. When I program the CFM only, the device only work after power off then on.  But this is progress. I would think that vthe JTAG is working, and I have an issue with the user flash memory (UFM).  Now I need to figure why I get a "can't verify device" when trying to program the UFM.  I am slightly encouraged, but still do not know what the problem is.  Regrads Dan

[Altera_Forum]

Hello Dan, 

 as you already found out, only the CFM part is responsible for the logic configuration. Although the UFM part is programmed by default, it would be only needed if you are using the user flash in your design and want to initialize it during device programming. In some designs, it may be in contrast desirable to exclude UFM from an logic update, e. g. cause it contains calibration data or device personalisation.   I never experienced similar problems with MAX II user flash. I wonder if you have some logic that is unintentionally rewriting the flash and thus exceeds the possible number of reprogram cycles after a short time or if the flash content may be self-modfied between program and verify?   Anyway a read-back of UFM and compare with original content may help to understand the issue.  The JTAG and power-up point in the handbook should be always satisfied when using a TCK pull-down and a TMS pull-up. Actually, MAX II has already built-in weak resistors, but they may be overdriven by an external circuit sometimes, so it's better to use the suggested external resistors.  I understand from your post, that the power supply shouldn't be a problem. To be sure, I would perform the test for VCCINT during device programming, that's described in the handbook.  Regards, Frank

[Altera_Forum]

--- Quote Start ---  Hello Dan,  as you already found out, only the CFM part is responsible for the logic configuration. Although the UFM part is programmed by default, it would be only needed if you are using the user flash in your design and want to initialize it during device programming. In some designs, it may be in contrast desirable to exclude UFM from an logic update, e. g. cause it contains calibration data or device personalisation.   I never experienced similar problems with MAX II user flash. I wonder if you have some logic that is unintentionally rewriting the flash and thus exceeds the possible number of reprogram cycles after a short time or if the flash content may be self-modfied between program and verify?   Anyway a read-back of UFM and compare with original content may help to understand the issue.  The JTAG and power-up point in the handbook should be always satisfied when using a TCK pull-down and a TMS pull-up. Actually, MAX II has already built-in weak resistors, but they may be overdriven by an external circuit sometimes, so it's better to use the suggested external resistors.  I understand from your post, that the power supply shouldn't be a problem. To be sure, I would perform the test for VCCINT during device programming, that's described in the handbook.  Regards, Frank  --- Quote End ---     Hi again,  I am able to erase the IC. I would assume it erases both the CFM and UFM. Following an erase, I can not program the device if I try to include the UFM section. I can reprogram if I exclude the UFM. Such is the case even if I try to load a design (pof file) that does not utilize the UFM section.  I wonder if I can conclude that the JTAG is working properly. I am suspecting that there is something going on with the memory power and ground, but why should that be different then the CFM section? I will try and find the supply and ground pins dedicated to the UFM, but I realy do not think that is the issue. I will try and look up what you sugested regading the VCCINT testing.   So I assume the problem is not with the JTAG. I am using the memory flash via the megafunction, and it is set to parallel memory, only 3 words at 16 bits each. I do have a mif file to initialize some data. I used parallel memory before (1 word of 16 bits), but without initalizing data and that workes fine on exsiting product hardware.   The issue here is that once the IC fails to verify the UFM, the problem presists even when I erase the IC (no error messages on erase). Loading a file without UFM does not clear the problem.  That is a real puzzle. I wonder if I damage the IC's when trying to program thye UFM. It is possible that I am doing something dumb, that I am not suposed to do. There is so much to learn and read, it is overwhelming...  Regrads Dan

[Altera_Forum]

I'm not sure about the exact hardware structure, but I expect that CFM and UFM are different sector groups of one serial flash. There are most likely no separate supply pins.

[Altera_Forum]

I tend to think that the issue is not in my JTAG hardware and connections, because I can program and verify the CFM section. The error shows up only when trying to verify the UFM. I can erase both CFM and UFM, but load the CFM only.  

 Do you think my assumption (that the JTAG is working) is correct? Is there anything different about sending (or reading) the UFM section? The device can be erased, so why would it "not verify device number 1" After it is erased, even when I compile a simple pof without a UFM section?  I am still very puzzled.  Regards Dan

[Altera_Forum]

I am still stuck. I have here a second IC that programmed a few times and then failed. The failure is in the verification of the UFM. I can program the CFM and it works fine as long as I uncheck the UFM "boxes" at the programmer window. 

 That makes me think that the JTAG is working. In fact, I can erase the device (CFM and UFM), but can not program anything unless the UFM is unchecked, not even the simplest of pof files (input, inverter output with no UFM at all).  The problem stated after I included a parallel memory type UFM in the design. That may or may not be related, but it seems to me that something happened inside, so that even a complete erase does not fix. But the erase sequence does not report that anything is wrong - erase reports successful operation.    I wonder how many people use a parallel user flush memory. Is it possible that there is a bug here?   So far, the Altera FAE, and excellent EE (I took Altera courses from him) does not know what the problem is. The tech support guy suggested that I should only check the top row of the programmer and then he thinks the device will work. Can you dig it? I can not!  Regards Dan

[Altera_Forum]

I'm using the MAX II parallel flash in several production designs and they are operating correct. I still think, it may be a problem of unintentional erase or write accesses to the flash, as I already mentioned. Particularly the delayed failure suggests an issue like this.

[Altera_Forum]

I too am using the exact same device in a product, and the device does utilize a parallel memory mega function in the UFM. I never had a single such error. 

 I am not sure what you mean by "delayed". The error comes up very quickly if I only check the "verify" box of the UFM. If I also check the CFM section, then it takes longer for the error to show up, because it "does" the CFM first.   I read your comments, and assuming they are 100% on the mark, it does not tell me where to take it or what to do.  One way or the other, I simply do not know what to do with it. You have working commercial hardware so so do I. In fact, mine uses the identical part - EPM1270T144. Not so for my present project.  I have a device that erases with no errors, and then refuses to load any file, not even a simple input inverter outout (no UFM) after a complete erase...  Thanks for your comments.  Regards Dan

[Altera_Forum]

Hello Dan, 

 unfortunately I can't see from a distance what's going on in your circuit, and may be, I would have the same difficulties with the circuit at my fingetrtips.   delayed was referring to the fact, that the error occured after several programming cycles, if I understood right. To verify, that the design isn't damaging the flash by excessive write or erasure requests, I would disconnect the respective control lines and try with a new device.  If this kind of design problems can be excluded, I would return to possible hardware issues. There must be something specific to your present hardware.  Of course, individual parts may be defective, respectively have been damaged by solder/desolder or ESD events. So it may be misleading to base the conclusions on the behaviour of a single part.  Regards, Frank

[Altera_Forum]

Hello Frank, 

 My posts may be too long, but I belive I stated that the first part programed around 3 dozen times, then it failed, just around the time that I included the UFM portion into the design (parralell flash via the Quartus Megafunction).   Then I replaced the part, and it programed only 3 times, then it failed on the forth time.   Yes, it may be the specific board, or may not. I will know soon because the second prototype is almost completed.    We have the most competent and highly experienced techs, as well as all the proper gear, soldering tools, microscope, name it. We checked and rechecked... It should not be so difficult, only 144 pins and 4 traces, clean power, pull up and down resistors as recomanded by Altera for MAX II...   I just do not get it. A SECOND device also can be recognized and fullty erased (no errors). Then I found out that the second device device can be programed into the CFM (no errors) but the UFM does not verify (I assume the first device would have done the same).   I can include UFM circuitry or not, it does not matter. If I check the UFM verify, the error is there. If I do not check UFM verify and/or program, there is no error.    So my UFM is "broken", and if I can not fix it, I will go for an external EPROM. That is a new layout, but I may have no choice. Too bad. I like Altera a lot, it is my first problem with it, and I am trying to use the user flash memory feature, but at that rate I am considering giving up the feature.   Thanks again for staying with me so long. I do appreciate it.   Regards  Dan

[Altera_Forum]

Sorry, I've no new ideas at this point.  

 Regards, Frank

[Altera_Forum]

Thanks again 

 Dan

[Altera_Forum]

A couple of month passed by, I still have no idea what the issue is.  

I am going to renew my search for an answer. Any sugestions are welcome.  Regards Dan

[Altera_Forum]

Hi, 

 I'm a relatively new Altera user, so I could be way off here, but I believe Frank has already mentioned 'programming cycles' with reference to the UFM (user flash memory).  In the MaxII device handbook it states the maximum number of programming cycles to the UFM and CFM is 100 (max II handbook, table 5-3). As frank has already pointed out, if you have logic that is writing and rewriting to the UFM you could quickly reach this limit, making the UFM nonprogrammable.  The limit is the same for both the user flash and configuration flash, but of course you can only program the configuration via JTAG/ISP - one could implement a design that rewrites to the flash constantly, making it unusable within a matter of seconds of power up(!!)  Its a bummer, because I was planning on using these devices for extensive bench testing of bespoke hardware, which requires changing the configuration quite often. Even without the UFM, I would probably use up the rewrite cycles in a matter of months.  As I said, could be way off, or repeating what others have said, but its a little caveat/gotcha that I'm used to spotting in datasheets.  BuriedCode

[Altera_Forum]

Hello, I encountered the same problem to you, the device I used is EPM240T100C3, I found that if the pin DEV_CLR wasnot set ZERO, the Quartus II would encount the error message "can't verify device number 1" when it worked about 56%. When I set the pin DEV_CLR to th Ground, the program was download successfully. 

Hope this useful to you!