Explain what the example is going to do?

[petterreinholdtsen]

It would be useful if the README in the example directory explain what the behaviour of the example should be. I guess it should blink the LEDs on the top of the board, but am unsure as I do not get anything like that when compiling and loading the example. This is the terminal output I get:

% make && sudo make load
yosys -q -p "synth_ice40 -blif rot.blif" rot.v
arachne-pnr -p rot.pcf rot.blif -o rot.txt
seed: 1
device: 1k
read_chipdb +/share/arachne-pnr/chipdb-1k.bin...
  supported packages: cb121, cb132, cb81, cm121, cm36, cm49, cm81, qn84, swg16tr, tq144, vq100
read_blif rot.blif...
prune...
read_pcf rot.pcf...
instantiate_io...
pack...

After packing:
IOs          6 / 96
GBs          0 / 8
  GB_IOs     0 / 8
LCs          65 / 1280
  DFF        29
  CARRY      23
  CARRY, DFF 0
  DFF PASS   5
  CARRY PASS 1
BRAMs        0 / 16
WARMBOOTs    0 / 1
PLLs         0 / 1

place_constraints...
promote_globals...
  promoted clk$2, 29 / 29
  promoted $abc$460$auto$rtlil.cc:1969:NotGate$402, 28 / 28
  promoted 2 nets
    1 sr/we
    1 clk
  2 globals
    1 sr/we
    1 clk
realize_constants...
  realized 1
place...
  initial wire length = 1022
  at iteration #50: temp = 9.13484, wire length = 452
  at iteration #100: temp = 3.81946, wire length = 357
  at iteration #150: temp = 1.44129, wire length = 174
  at iteration #200: temp = 0.0330434, wire length = 96
  final wire length = 96

After placement:
PIOs       4 / 96
PLBs       15 / 160
BRAMs      0 / 16

  place time 0.92s
route...
  pass 1, 0 shared.

After routing:
span_4     21 / 6944
span_12    7 / 1440

  route time 0.22s
write_txt rot.txt...
icebox_explain rot.txt > rot.ex
icepack rot.txt rot.bin
./ice4pi_prog rot.bin
4+0 oppføringer inn
4+0 oppføringer ut
4194304 byte (4,2 MB, 4,0 MiB) kopiert, 0,0959039 s, 43,7 MB/s
62+1 oppføringer inn
62+1 oppføringer ut
32220 byte (32 kB, 31 KiB) kopiert, 0,00150405 s, 21,4 MB/s
flashrom v1.2 on Linux 5.15.84-v7+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... 
Warning: Chip content is identical to the requested image.
Erase/write done.
flashrom v1.2 on Linux 5.15.84-v7+ (armv7l)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... 
Warning: Chip content is identical to the requested image.
Erase/write done.
%

The only activity I see on the leds is that four of them turn on during flashing.

[lightside-instruments]

Correct. This should work and you should see led blinking in a circle - 3 leds are on while one gets turned off in a clockwise rotation.

I will check if it is a software issue by reproducing the steps after apt update tomorrow. Will get back on this.

[lightside-instruments]

I just retried the steps from scratch and it works. If not a hardware issue this might be some GPIO conflict. Are you sure there are no preinstalled applications attempting to access GPIOs etc.

Here are the package versions (just updated to the latest bullseye state) my test worked with:

yosys                                       0.9-1+b2
fpga-icestorm                         0~20190913git0ec00d8-2
fpga-icestorm-chipdb            0~20190913git0ec00d8-2
arachne-pnr                            0.1+20190728gitc40fb22-2
arachne-pnr-chipdb              0.1+20190728gitc40fb22-2
flashrom                                  1.2-5

[petterreinholdtsen]

[lightside-instruments]

I just retried the steps from scratch and it works. If not a hardware issue this might be some GPIO conflict. Are you sure there are no preinstalled applications attempting to access GPIOs etc.

Not sure at all. The machine also have a pyjuice board connected for power. Perhaps the two are in each others hair? Will try without the pyjuice board.

-- Happy hacking Petter Reinholdtsen

[lightside-instruments]

pijuice uses only i2c pins so probably not the issue but do try without it in case there is some wierd powersupply correlation.

obviously the SPI connection and programming works since the verification is OK

If you see the LEDs changing intensity then then obviously they are driven from the FPGA ... so the question is why it stops.

The LEDs should turn on only when programming is finished and the iCE_CREST (pin 18) is released low to high transition. You could see very low intensity glow before programming is finished when the iCE_CREST is held down due to weak pullups.

[lightside-instruments]

One suggestion:

diff --git a/example/ice4pi_prog b/example/ice4pi_prog
index c747db8..81f4aaa 100755
--- a/example/ice4pi_prog
+++ b/example/ice4pi_prog
@@ -1,5 +1,5 @@
 #!/bin/bash
-echo 24 > /sys/class/gpio/export
+echo 24 > /sys/class/gpio/export || true
 echo out > /sys/class/gpio/gpio24/direction
 echo 1 >/sys/class/gpio/gpio24/value
 sleep 1
@@ -10,6 +10,5 @@ dd if=${1} conv=notrunc of=image
 flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=20000 -w image
 #workaround first time fails after initial programming
 flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=20000 -w image
-echo in > /sys/class/gpio/gpio24/direction
-echo 24 > /sys/class/gpio/unexport
+echo 1 >/sys/class/gpio/gpio24/value

[petterreinholdtsen]

[lightside-instruments]

One suggestion:

I tested removing the pijuice hat without any changes. The lights turn on during flashing, but go dark once the flashing is done.

Tried your patch for ice4pi_prog, but it did not have any effect on the light blinking

No clue what is wrong here.

One interesting thing is that the flashing claim the chip content is identical to the requested image, even after I modified the .v file slightly (changed the value used to compare to the divider by one). I expected this to create a different image for the flashing, but do not really know what I am doing.

-- Happy hacking Petter Reinholdtsen

[lightside-instruments]

One interesting thing is that the flashing claim the chip content is identical to the requested image, even after I modified the .v file slightly (changed the value used to compare to the divider by one). I expected this to create a different image for the flashing

this is a good clue ... the "make" command (default target with no parameter) should generate a new rot.bin file corresponding to your changes in rot.v

the "sudo make load" should pad with zeroes this file up to 4 MB and create a file called "image" then try to program it with "flashrom ... image"

The only way to get the message is to have identical image files in consecutive calls to flashrom. Can you doublecheck that "rot.bin" and "image" are sane.