RGD2

..... I just had an odd experiance. I copied that 99-etc file into rules.d and rebooted, but no change. Then I thought, well, how about the external eeprom? That failed...

Here's what bt shows, or rather doesn't: ```` pi@usbpi:~ $ gdb --args openFPGALoader bitfile.fs GNU gdb (Raspbian 10.1-1.7) 10.1.90.20210103-git Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL...

Didn't seem to help. Tested with a smaller 'recently deleted' file. Fortunately, just *looking* at the whole block device, about 8M at a time, about once every 50GB was good...

Well, j1b is 32 bit, whereas j1a is 16. But apart from that: The j1a is able to run on SRAM's having only pseudo-dual port, whereas the original J1 was...

Confirmed, mine does the same thing. I don't think you're missing a step. Hmm...

_I think_ it's a timing issue of some sort... there's a kludgy workaround: ``` >-1 -1 $10 io! drop ok >$10 io@ . 255 ok ``` I hit the same...

Seems fixed now with cliffordwolf/yosys@840a6dc, cseed/arachne-pnr@1a4fdf9, cliffordwolf/icestorm@b49d2d3, jamesbowman/swapforth@ef9aaa6. ``` sudo python shell.py -h /dev/ttyUSB1 -p ../common/ Contacting... established Loaded 207 words >-1 leds ok >0 leds ok >-1 $20 io!...

I'm seeing something similar - sometimes a line like 400 . Won't return 400 ok.

It shouldn't matter... Read up on resets in SRAM based FPGA's: there's a good argument that instead of having designed-in resets, one ought to just do a full FPGA reconfigure....

Reasons to reset are things like glitches or soft errors caused by ionising radiation. But if your design needs a reset, the whole FPGA probably also needs a reset, because...