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

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

--- 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

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

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

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

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

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

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.