Community
cancel
Showing results for 
Search instead for 
Did you mean: 
RRomano001
New Contributor I
712 Views

Quartus18.x,19.1 issue1: Programmer

Jump to solution

Hi platform Linux:

target MAX10SC 04 08 16 25 50 EQFP 144 (custom board)

target MAX10SC 08 and 50 BGA484 Terasic DE10Lite, RoketBoard Arrow/terasic DECA

Quartus II lite 18.1 (programmer from 19.1 same)

Programmer: USB blaster, Terasic embedded programmer on DE10 Lite.

 

I don't use winxx platform, try'd on VM win 7 Pro where I use Terasic tools thru linux USB Blaster server, programmer 18/19 same issue.

Failed to setup USB blaster native driver on that platform...

Try'd on a stand alone Win7 only, same issue on device drivers, so again I cannot test native winzz USB blaster drivers. (install Quartus on win7 require a huge amount of time compared to few minutes on Linux/MAC so I am not interested test more on.)

 

**************************************************************************************

*** Test bench programmers 18.1 19.1:

**************************************************************************************

Programmer of latest version (18.x,19.1) fail reporting failure 0% after a while.

Unsuccessful operation: program, verify, blank check flash with .pof files.

After one of that operation Fpga remain in a limbo state, programmer never work again and require a power cycle.

Erase flash (.pof) work.

 

Verify leave board in an unknown state, old image never load at end of operation.

After power cycle of USB Blaster and regaining control of USB Blaster then a .sof can be loaded in ram also without power cycle of my custom board.

(NA on Terasic due to integrated programmer).

This is spread on all my board and Terasic too.

**************************************************************************************

*** TEST 2 Using programmer version 15.0 same hardware same platform:

**************************************************************************************

Blank check proceed to 100% so 18.x 19.1 erasure work for sure.

Program .pof proceed to 100% verify ok

verify .pof work

Load .sof work

Erase work

 

console output:

Info (209060): Started Programmer operation at Thu May 2 10:42:02 2019

Info (209016): Configuring device index 1

Info (209017): Device 1 contains JTAG ID code 0x0318A0DD

Info (209007): Configuration succeeded -- 1 device(s) configured

Info (209011): Successfully performed operation(s)

Info (209061): Ended Programmer operation at Thu May 2 10:42:04 2019

 

Leaving both 18.x (19.x too) 15.0 Quartus running at same time don't change behavior.

Failure on 18.x block hardware so try on 15.0 result in failure:

Console output:

 

Info (209060): Started Programmer operation at Thu May 2 10:58:44 2019

Error (209053): Unexpected error in JTAG server -- error code 35

Error (209012): Operation failed

Info (209061): Ended Programmer operation at Thu May 2 10:59:05 2019

 

power cycle USB blaster then verify on 15.0:

 

Info (209060): Started Programmer operation at Thu May 2 11:00:34 2019

Info (209017): Device 1 contains JTAG ID code 0x0318A0DD

Info (209021): Performing verification on device(s)

Info (209011): Successfully performed operation(s)

Info (209061): Ended Programmer operation at Thu May 2 11:01:09 2019

 

Edit:

 After verify image reload and restart, also power cycling board reload from flash as it was.

 

18.x seems has broken pipe to console and no messages appear on.

0 Kudos
1 Solution
ShafiqY_Intel
Employee
248 Views

Hi,

 

I think it might be your flash is not fully erase. (the reason you not able to verify)

The Programmer Engine supposed to NOT touch other flash partition except those defined with bitstream and user data.

 

Kindly follow the attachment pdf for step to fully erase.

(Since you are using MAX 10, use .pof file instead of .jic)

 

I hope this will help.

 

Thanks

View solution in original post

9 Replies
RRomano001
New Contributor I
248 Views

news?

ShafiqY_Intel
Employee
248 Views

Hi RRomano001,

 

I think your issue is quite similar with this one.

https://forums.intel.com/s/question/0D70P000006IEML/no-jtag-hardware-available-for-quartus-prime-pro...

 

Please let me know if you issue doen not improve

 

Thanks.😉

RRomano001
New Contributor I
248 Views

Hi, I browsed forum and known issue, no solution found.

Programmer 19.1 was installed on win7pro, same issue.

checked full quartus19.1 on Linux, no solution to none of issue, removed after a while to free up hdd space.

just to test plugged out then in USB Blaster, dmesg:

[170212.789879] usb 3-3.4.3: USB disconnect, device number 20

[170215.827861] usb 3-3.4.3: new full-speed USB device number 21 using xhci_hcd

[170215.941054] usb 3-3.4.3: New USB device found, idVendor=09fb, idProduct=6001

[170215.941061] usb 3-3.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[170215.941064] usb 3-3.4.3: Product: USB-Blaster(Altera)

[170215.941068] usb 3-3.4.3: Manufacturer: Altera

[170215.941071] usb 3-3.4.3: SerialNumber: 8D792F7A5454

 

so device is enumerated and in working order, it work from 15.0, fail on more recent version. Not sure if from 15.1 or 16.x, removed all release from 18.0 downto 15.1

lsusb:

Bus 003 Device 016: ID 0483:3748 STMicroelectronics ST-LINK/V2

Bus 003 Device 021: ID 09fb:6001 Altera Blaster

both device are on active debug over MAX10 board. Same issue is present if jtag server is accessed from Win7PROEN VM (Terasic toolkit) or real machine where it was win10 (Bleah) now dual boot win7proIT , ubuntu 18.4 (fresh new clean, prepared to parallel test quartus issue).

 

Edit:

 

Test after .pof action verify, required restart JTAGD too, dmesg report nothing, lsusb is same, just erase work on new version but not verify blank check nor program, this issue is stable from the past, just realized now is a software issue not hardware after 4 different adapter buy.

Original (old cyclone II kit), clone and Terasic on board suffer same way.

15.0 is retained due more recent version forbid use pin near pll clock input and old board need to be maintained.

Best regards

Roberto

 

ShafiqY_Intel
Employee
248 Views

Hi RRomano001,

 

If you are using 19.1, there is some issue with USB Blaster II when using Quartus 19.1 version. Please follow the following KDB for workaround.

https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base...

 

I hope this will help.

 

Thanks😉

 

RRomano001
New Contributor I
248 Views

NOPE NOPE NOPE NOOOOOOOPEEEEEEE!!!!!

PLEASE READ THOROUGH:

 

Your link report this issue:

USB BLASTER NOT WORKING.

THIS IS NOT NOT ****NOT**** my case!

 

Device drivers right are ok, Cable is working, I am using on regular basis.

 

USB Blaster is perfectly working as you can read from device enumerated and IN WORKING ORDER.

 

Programmer 19.1 fail EXACTLY SAME WAY of 18.1 and probably 17.x 18.0.

 

****************************************************************************************************************************************************

***********************************-----------------------------------------------------------------------------------******************************

============>>>>>>>>>>>>>_____ SOFTWARE Programmer of release 15.0 work hassle FREE. _____<<<<<<===============

***********************************-----------------------------------------------------------------------------------******************************

****************************************************************************************************************************************************

 

--->>>--- QUARTUS PROGRAMMER ---<<< <<not usb Blaster cable>>.

 

Issue to USB Blaster came from SOftware 18.x 19.x not from drivers.

Regards

 

ShafiqY_Intel
Employee
248 Views

Hi,

 

I'm apologize for misunderstanding to previous reply.

Is there any improvement to this issue?

 

If not, could you please send the screenshot for the error?

 

When you program using Quartus v18.1/19.1, did you compiled your design using Quartus v18.1/19.1 OR you just used old pof file (compiled in Quartus 15.1)?

 

Have you tried program it in Quartus Standard version?

 

Thanks

 

 

 

 

RRomano001
New Contributor I
248 Views

Hi, about heaven and hells.....

 

.sof or .pof compiled on different version has no impact on issue. 15.0 header or 18.1 header process same way on version so:

 

.pof .sof versionless:+

 

Programmer version 18.1 Lite, 19.1 (exist just one version). doesn't work, remember this appeared from 17.x (now removed).

Programmer version 15.0 Work forever.

 

Programming .pof with 15.0 version

just after .pof loaded .sof with 18.1 version

 Screenshot from 2019-06-01 00:53:52ed.png

.pof erase on 18.1 as written work for sure.

.pof on 18.1 version verify, programming fail after a while.

 Screenshot from 2019-06-01 00:55:55ed.png

ShafiqY_Intel
Employee
249 Views

Hi,

 

I think it might be your flash is not fully erase. (the reason you not able to verify)

The Programmer Engine supposed to NOT touch other flash partition except those defined with bitstream and user data.

 

Kindly follow the attachment pdf for step to fully erase.

(Since you are using MAX 10, use .pof file instead of .jic)

 

I hope this will help.

 

Thanks

View solution in original post

RRomano001
New Contributor I
248 Views

Ok after this ***USELESS*** answer I feel the pain of remain on Altera (now intel) platform.

 

Programmer versionless erase the flash, 18.x 19.x report error but it is fully erased as reported from 15.0 progremmer version it do all operation on .sof or .pof versionless.

Every version erase flash.. 18,.x 19.x Presumably after 16.x . New version erase but report error.

Version 18.x 19.x just program .sof file. .POF report error on program verify blank check.

 

Version 15.0 has no issue, it can program .pof .sof from every version is generated from. (verify and blank check work fine)

 

I am using a max10 not cyclone 10.

 

This resemble a M$ish answer and all answer are same value.... :(

I remember a long long time ago:

I was both unix and Dbase administrator on a large organization.

I was happy managing Oracle and Unix on a multiprocessor MOtorola (now frescale) SMP 4x 68030 and some networked backup same processor kind.

One of insane commercial people decided was time to enter M$ domain...

So dismantled mainframes , network was based on a modem bank and over 1000 terminal and data concentrator all around county where on service.

Answer to terminal where under 1 second on huge load.

So I told company people to hire a so called M$ admin, I don't like that platform, I assist on migration then I quit.

 

NT + SQL server, ( 2GB very expensive that time vs 256MB smp snooped cache on unix mainframe) they pay'd like a large flat and a supercar.

So starting migration of large dbase, all proceed till a point we forever got an error... M$ error...

Called assistance the kid answered with standard reply, then screaming due it was not able to understand technical language quitted...

After a week I told people to buy Oracle on NT, still remember I quit from this platform....

New admin (oh how much it was an arrogant and low skilled person.... ) installed Oracle but screamed a lot this is not a M$ product... I was proud manager told him this is a company need work not use what you want that doesn't work....

So migrated dbase, ( a lot slower than on mainframe ).. I quitted and company started his choice of bad service... minutes for query than under second.... They bought other cluster and so on... Intel was happy ... Administrative when realized mainframe was a lot less expensive not!

 

After this story I was just called another time from finance administrative.. They told me M$ answered, 6 mount later our question, answer was:

"Yes doing migration SQL server really emit that error....."

This service was so expensive like a supercar.... (or large flat if you prefer)

 

Is Altera now Intel this way of M$ized answer?

 

Sorry JonSnow, I flagged your answer as the best one in memory of this old episode...

I am sure no other solution exists than migrate away from Ex Altera now Intel and I fear M$ too...

Sorry I cannot accept answer say what it work must be done on another family...

I am waiting for Xilinx development tools to try migrate away.

Best regards

Roberto

Reply