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

Able to program flash only with -v flag #330

Open
consanii opened this issue May 8, 2024 · 9 comments
Open

Able to program flash only with -v flag #330

consanii opened this issue May 8, 2024 · 9 comments

Comments

@consanii
Copy link

consanii commented May 8, 2024

I am experiencing this weird behavior where if I try to program the flash normally using something like iceprog hardware.bin, it fails. However, if I add the verbose flag to actually see why it fails, it programs the flash without a problem. Specifically, it fails the verification check, so it programs the flash, and then when it reads back the content, it fails.

If I have to guess, it is something related to timing, as the printf() calls slow down the programming process. I tried to use the slow SPI flag, but I experience the same behavior. Also, the chip select bus is never released after this unsuccessful command, so other devices connected to the SPI bus cannot drive it low. I have to run a command that successfully completes (iceprog -t is enough) to release CS.

The flash chip that I have is the MT25QL128ABA1ESE-0SIT.

@RCoeurjoly
Copy link
Contributor

Are you using latest iceprog compiled from source?
Are you using a custom board or a commercial one? I don't think I have any board with MT25QL128ABA1ESE-0SIT, I will try to reproduce anyway.

@consanii
Copy link
Author

I am using the bundled version inside OSS CAD suite. As I downloaded it a month ago or so, I don't think is the latest version. I can try to compile fresh from source and see what happens.
And yes, it is a custom board.

@RCoeurjoly
Copy link
Contributor

Cannot reproduce. With and without -v flag it works for me.
My setup is the following:

  • latest iceprog compiled from source (commit 1a40ae7).
  • Executed from WSL
  • Alhambra-II board, featuring N25Q032A flash memory.

I am thinking maybe we could record the issue with rr (https://github.com/rr-debugger/rr), but then again if the issue is timing related, rr could mess with that.

@consanii
Copy link
Author

Yeah, I know it's not an issue super easy to reproduce. Also because it has something to do with the chip itself, as on all the other boards (all commercial, different flash chips than what I am using) iceprog works as expected.
I will look at rr tomorrow to see if I have the proper hardware to run it and if I am still able to reproduce the issue.

@RCoeurjoly
Copy link
Contributor

I think the problem is as follows:

When there is a verification failure, we do this:

fprintf(stderr, "Found difference between flash and file!\n");
mpsse_error(3);

mpsse_error ultimately exits:
exit(status);

So the following code does not execute:


		// ---------------------------------------------------------
		// Reset
		// ---------------------------------------------------------

		if (!disable_powerdown)
			flash_power_down();

		set_cs_creset(1, 1);
		usleep(250000);

This would explain why the chip select bus is never released after a failed verification.

Could you try my fork to see if the chip select issue persists? https://github.com/RCoeurjoly/icestorm

@consanii
Copy link
Author

I tried it out, but I still experience the same behaviour. After the verification failure, the CS bus is held high.

@RCoeurjoly
Copy link
Contributor

Could you try again? I made a mistake that should be fixed now.

@consanii
Copy link
Author

Yes, now it's working. The CS bus is correctly released after the verification failure.

@RCoeurjoly
Copy link
Contributor

Thanks for confirming. The solution for the cs bus is already in main after #331 got merged.

Regarding the flashing issue, could you include the failure message of the verification check?
Also, have you tried other .bin and all fail? I am thinking maybe it is related to the size of the .bin file.

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