Able to program flash only with `-v` flag

[consanii]

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]

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]

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]

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]

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]

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]

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

[RCoeurjoly]

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

[consanii]

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

[RCoeurjoly]

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.