Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21602 Discussions

Programmer fails at 87% - SoCKit

Altera_Forum
Honored Contributor II
2,529 Views

Hi, 

 

I am using SoCKit Development Kit.  

 

Programmer fails always at 87% and it doesn't show any error. Sometimes, when the programmer fails at 87% or 88%, I can still see program got burned (LED Blinking) on the board but it doesn't show any error code. However, I can't use Signal Tab II to analyze the outputs. 

 

JTAG connection is just fine. Any idea why it happens ?  

 

Thanks.
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
650 Views

To paraphrase Forest Gump, "it happens". 

 

Before considering any legitimate hardware problem, do all of the reset-ish things you can do: power cycle the board, unplug/replug the USB cable. Depending on what operating system you are on, kill any JTAG related process that might be running. (jtagserver.exe, jtagd, ...)  

 

Then, scan the chain in the programmer and try again.
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

I have already tried those actions. When current code fails to burn, I can successfully burn simple LED blinking project.  

 

I am trying to see LVDS outputs. I read somewhere that LVDS signals can't be seen on signal tab, therefore, I am not using any differential signals such as bit clock. I am using frame clock as main clock and reset to trigger the Signal Tab. I successfully burned the program for one channel with this setting but for 8 channel with the same setting, it fails at 87%.  

 

For one channel output, I just activated LED and now the programmer fails again at 87% but I can see LED blinking which means part of program is still there but Signal Tab is not activated. 

 

If anyone tried to see LVDS output, can please comment here. 

 

Thanks.
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

Programming is consistently failing @88%. Not trying to see LVDS directly - observing parallel outputs after deserialization, etc.

0 Kudos
Altera_Forum
Honored Contributor II
650 Views

This happens to me too - seems to be something specific to a build. It is not some transient noise problem. Surprised there is no definitive explanation/resolution to this problem.

0 Kudos
Altera_Forum
Honored Contributor II
650 Views

 

--- Quote Start ---  

This happens to me too - seems to be something specific to a build. It is not some transient noise problem. Surprised there is no definitive explanation/resolution to this problem. 

--- Quote End ---  

 

 

I have the same problem, it seems to be bound to a specific design. After a power cycle and a design change, seems to work again. However, the JTAG driver seems to go in a strage state and sometimes reinstalls itself after reconnect.
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

Found it - replacing all the assignements with values taken from another similar working project fixed the issue. However, I was suprised to see that the I/O standards have not bee imported using "assignments/import assignments". Pasting the qsf in a tcl console did the job.  

 

I have seen much more strange behaviour in importing assingments in 16.1 than before (9.1- 15.1), it seems to be safest to edit the the QSF files manually.
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

For the symptom of failing upload at 87/88% then having JTAG buggered (requiring a power-cycle) I have noticed it is design-specific and changes from build to build. Specifically, if I change signalTap config/size (or remove it altogether) it seems to clear it up.

0 Kudos
Reply