icezprog flakey with Pi zero-W connected to icezero

[martynjriley]

Python programming routine works reliably. However, I get some programming errors with icezprog.c unless delays in ...

uint32_t spi_xfer(uint32_t data, int nbits)

... are increased.

This works for me ...

uwait_barrier_sync(25);

Some of the time! Still unreliable sometimes so not sure this is the problem!
Device is a Micron N25Q128A

[jcw]

Same here, but on a PiZ, not PiZ-W. It used to work reliably with a few simple tests. I did an apt update/upgrade of Raspbian today, and now it fails to upload most of the time (not sure there's a causal relation), although the upload does eventually succeed:

$ make prog
./icezprog icezero.bin
Flash ID: 20 BA 17 10 00 00 23 63 63 21 09 00 27 00 31 02 11 16 67 4E
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback..ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback.......ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback......ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback....ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback..........ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback..ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback...ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback.....ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback.......ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback..ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback.ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback...ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback....ERROR
Writing 0x000000 .. 0x00ffff: [erasing] [writing................] [readback................]
Writing 0x010000 .. 0x01ffff: [erasing] [writing................] [readback..ERROR

Update - working fine again, no changes to icezprog. Maybe there was some background activity while the above happened, hard to tell afterwards.

[noscene]

Same issue on PiZ W but replace 3 x uwait_barrier_sync(25); in spi_xfer works for me too.
thanks

[NiallCosgrove]

I believe the issue is caused by the -Os flag to gcc
No need to mess with uwait_barrier_syncat all. I suspect that the gcc size optimization causes some subtle change in the timing.

From icotools/examples/icezero/Makefile

icezprog: icezprog.c
gcc -o icezprog -Wall -Os icezprog.c -lwiringPi -lrt -lstdc++

Compile instead with:
gcc -o icezprog -Wall icezprog.c -lwiringPi -lrt -lstdc++
i.e remove the -Os flag.

This produces a stable and reliable icezprog for me instead of the string of read errors I used to get.

[thekroko]

I ran into the same issue with an Raspberry Pi Zero W, but removing the -Os flag didn't solve it for me. Changing the uwait_barrier_sync() to ~40 seems to work, but makes the process a bit slow.

I dug around in the code a bit, and added some delays to the spi_begin()/end() while removing the delay in the spi_xfer(). I also moved the digitalRead to the high-edge of CLK. Both things seem to help pretty well, so now it actually flashes significantly faster & without readback errors.

Code is currently forked here: https://github.com/thekroko/icotools

[jcw]

Note that without -Os different code will be generated. This could still be a cache flush issue.