Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terasic DE0-Nano (Cyclone IV) board #428

Closed
sevan opened this issue Feb 4, 2024 · 2 comments
Closed

Terasic DE0-Nano (Cyclone IV) board #428

sevan opened this issue Feb 4, 2024 · 2 comments

Comments

@sevan
Copy link

sevan commented Feb 4, 2024

I have a 1st gen de0-nano board, and openFPGALoader sees the device when I scan the USB bus, but if I try to detect it, it is not detected unless I specify the cable to use. Is that expected or should the utility make the correct decision by default based on what's scanned? I'm using openFPGALoader v0.11.0

I've yet to try writing to it :) getting there, slowly.

openFPGALoader --scan-usb
Bus device vid:pid       probe type      manufacturer serial               product
020 013    0x09fb:0x6001 usb-blaster     Altera                           USB-Blaster
openFPGALoader --detect
No cable or board specified: using direct ft2232 interface
unable to open ftdi device: -3 (device not found)
JTAG init failed with: unable to open ftdi device
openFPGALoader --detect -c usb-blaster
index 0:
	idcode 0x20f30dd
	manufacturer altera
	family cyclone 10 LP
	model  10CL025
	irlength 10
@trabucayre
Copy link
Owner

scan-usb is used to detect all cables known by openFPGALoader.

But when you try detect or loading/writing a bitstream if no board (-b) or cable (-c) is provided openFPGALoader will uses the default value ft2232 (FTDI FT2232H without buffer/level shifter).
A message is displayed to explains this situation:

No cable or board specified: using direct ft2232 interface

So in your case you have to explicitly provides -c usb-blaster or -b de0nano to be able to load/write a bitstream.

I know the default behavior is error prone but I'm hesitant to remove that to avoid breaking backward compatibility.

@sevan
Copy link
Author

sevan commented Feb 6, 2024

I know the default behavior is error prone but I'm hesitant to remove that to avoid breaking backward compatibility.

That's fine, just double checking.
Thanks for the explanation.

@sevan sevan closed this as completed Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants