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

efinix: program reports success (returns 0) when programming fails #476

Open
AndrewD opened this issue Jul 25, 2024 · 5 comments
Open

efinix: program reports success (returns 0) when programming fails #476

AndrewD opened this issue Jul 25, 2024 · 5 comments
Labels
bug Something isn't working enhancement New feature or request

Comments

@AndrewD
Copy link

AndrewD commented Jul 25, 2024

Efinix: programming errors still result in a success return code so there is no way for a script to detect errors from the return value.

This interface needs to be able to propagate errors (not return void):

void program(unsigned int offset, bool unprotect_flash) override;

@trabucayre
Copy link
Owner

In fact for all vendor's drivers program method throw exceptions when something is wrong.
But it's true, changing program to a non void method may be more easy to manage
And for efinix most of errors doesn't produces exception.

@trabucayre trabucayre added bug Something isn't working enhancement New feature or request labels Jul 25, 2024
@AndrewD
Copy link
Author

AndrewD commented Jul 25, 2024

If throwing an exception is the existing pattern then following this for Efinix would be sufficient for now - openfpgaloader just returning a non-zero value on error is all we need.

@AndrewD AndrewD changed the title openfpgaloader reports success (returns 0) when programming fails efinix: program reports success (returns 0) when programming fails Jul 25, 2024
@trabucayre
Copy link
Owner

with this commit all errors are correctly handled by program() method.
It's good to you?

@harbaum
Copy link

harbaum commented Feb 13, 2025

Not meaning to hijack this. But does the efinix jtag loading work at all? I do have a t20-bga256 demo board and this is IMHO supposed to be supported.

openFPGALoader -b trion_t20_bga256_jtag ./outflow/efinix_blink.bit

Looks like everything worked well and the FPGA even shortly stops running. But afterwards it continues to execute the bitstream that was already installed before. The bitstream was built using the current efinity software and uploads successfully using the closed source programmer.

I can dig into this a little further as my usbmon script allows me to look into both USB communications and compare them. But before doing that I'd like to make sure that I am not doing someting fundamentally wrong here. The way I am trying to upload is supposed to work?

@harbaum
Copy link

harbaum commented Feb 13, 2025

I did a quick investigation on this.

openFPGAloader actually loads the bit file and i see its contents arriving on USB (although bit reversed as JTAG is LSB first). But it seems to be missing a byte. The bitsteam hex file is 2035950 bytes in total. These are 2035950 / 3 = 678650 bytes decoded. With my tool I actually see 678649 bytes to be sent into the FPGA, so the first observation is that one byte seems to be missing. usbmon only captures the first 32 bytes of each bulk transfer so I cannot exactly tell what byte is missing but it seems it's the last one.

The efinity programmer on the other hand sends a total of 679926 bytes which is an additional 1286 bytes over the bitfile itself. I see that it e.g. prepends the first transfer of 4096 bytes with 20 zero bytes. The following few bytes look like they come directly from the bitfile. It would need further investigation where the other 1266 bytes are being inserted and if they're also 0 bytes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants