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

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

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

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

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

Regards,

Frank

Thanks again

Dan

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

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

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!