Unnable to connect.

[jemo07]

Hello,

I just tried accessing the board after loading the bin... and I get an empty screen.

 ~/DevForth/iceBoard/swapforth/j1a>PYTHONPATH=../shell:$PYTHONPATH python3 shell.py -h /dev/ttyUSB1 -p ../common/ 


^CContacting... Traceback (most recent call last):
  File "/home/jemo/DevForth/iceBoard/swapforth/j1a/shell.py", line 72, in <module>
    swapforth.main(TetheredJ1a)
  File "/home/jemo/DevForth/iceBoard/swapforth/shell/swapforth.py", line 383, in main
    r.boot(image)
  File "/home/jemo/DevForth/iceBoard/swapforth/j1a/shell.py", line 55, in boot
    self.reset()
  File "/home/jemo/DevForth/iceBoard/swapforth/j1a/shell.py", line 35, in reset
    waitcr()
  File "/home/jemo/DevForth/iceBoard/swapforth/j1a/shell.py", line 32, in waitcr
    while ser.read(1) != chr(10):
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 565, in read
    ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout.time_left())
KeyboardInterrupt

This is the output loading the bin file;

 ~/DevForth/iceBoard/swapforth/j1a > iceprog icestorm/j1a.bin
init..
cdone: high
reset..
cdone: low
flash ID: 0x20 0xBA 0x16 0x10 0x00 0x00 0x23 0x82 0x02 0x99 0x17 0x00 0x77 0x00 0x29 0x15 0x07 0x18 0xEC 0xFE
file size: 32476
erase 64kB sector at 0x000000..
programming..
done.                 
reading..
VERIFY OK             
cdone: high
Bye.

I'm on linux

uname -a
Linux jemo-MBP 5.19.0-46-generic #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 21 15:35:31 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

I'm hoping you can provide some guidance on to solve this.

[RGD2]

The project does assume that /dev/ttyUSB1 is the right usb-serial adapter.

The icestick 'looks' like a typical ftdi USB-serial adaptor with two ports: the first is connected so as to allow its use as a programmer (which iceprog finds by its own method - clearly is working here).

The second is connected via just tx and rx as a TTL level uart, and it's this one that shell.py is to be connected to, so you can talk to the swapforth system.

Most of the time the problem is just that you may have another usb-serial adaptor already connected, so the numbering (the 1 in /dev/ttyUSB1) is wrong in this case.

run ls /dev/ttyUSB* and see if there are other entries there - perhaps ttyUSB1 is currently some other usb-serial adaptor coincidentally plugged into your system? Maybe /dev/ttyUSB3 is the one you need?

On the other hand, I have had j1a builds that refused to connect - usually due to wrong baud clock settings. The serial port on the j1a is a fixed-speed only, and needs tweaking if the design clk rate is changed, for example by getting different PLL settings using icepll. Shouldn't be doing it out of the box though.

[jemo07]

Hello and thank you for followup, yes, I can see the two USB devices..

ls /dev/ttyUSB*
/dev/ttyUSB0  /dev/ttyUSB1

If I remove the card, there are none.

ls /dev/ttyUSB*
zsh: no matches found: /dev/ttyUSB*

I'm not sure if this might be an issue with the diver?

apio system --lsftdi                                                          
(DEBUG) Profile path: /home/jemo/.icestudio/apio/profile.json
(DEBUG) Home_dir: /home/jemo/.icestudio/apio
(DEBUG) Run Command: lsftdi
(DEBUG) System_base_dir: /home/jemo/.icestudio/apio/packages/tools-oss-cad-suite
(DEBUG) System bin dir: /home/jemo/.icestudio/apio/packages/tools-oss-cad-suite/bin
(DEBUG) Executable file: /home/jemo/.icestudio/apio/packages/tools-oss-cad-suite/bin/lsftdi
Number of FTDI devices found: 1
Checking device: 0
Manufacturer: FTDI, Description: Dual RS232-HS

Maybe the APIO is breaking things?

[jemo07]

Hi, just tried it on another two boards, they all fail... not sure what could be going on... reading through this http://www.latticesemi.com/~/media/LatticeSemi/Documents/ApplicationNotes/IK/iCE40sysCLOCKPLLDesignandUsageGuide.pdf?document_id=47778 to see if I can get up to speed on possible issue. Where in the code should I address the clk?

[RGD2]

Hi, I think the issue is that the connect python script is actually for python 2.x not python3.

I took a fresh git clone of the repo, cd'd into j1a, and did make; make j1a with an icestick plugged in.
All went well, but make connect failed (Because I don't have python visible to root). So I tried with:

PYTHONPATH=../shell:$PYTHONPATH python shell.py -h /dev/ttyUSB1 -p ../common/

I had the same result you had - so it's certainly not just you. (my global 'python --version` is 3.10.8 on this system, I am using pyenv).

On a hunch, I wondered whether the issue is that the python code is written for python2.x, so:

in the j1a directory, I just did a pyenv versions to see if I had a python2.x around (I did), then enabled it locally with pyenv local 2.7.18, after which PYTHONPATH=../shell:$PYTHONPATH python shell.py -h /dev/ttyUSB1 -p ../common/
worked for me. I got:

Contacting... established
Loaded 143 words
>

(I had previously installed pyserial with pip).

pyenv is highly recommended to deal with issues of this nature, rather than using python3 or python2, you just call python directly. The above pyenv local setup automatically manages making that python2 of that specific installed version I had, in that directory.

Else, it's probably not a huge issue for someone to fix by bringing the python code in this project up to date.
(other outstanding 'easy' issue: changing to use nextpnr rather than arachne-pnr).

PS. 143 words is just basewords, you probably want to #include swapforth.fs at that point to get the complete system so nice things like -1 leds works. If you reconnect after that, you'll get Loaded 207 words if swapforth is loaded.
You can save out the exact state of the swapforth system ram, and have it ready to be rebuilt into the fpga image, by running (on the j1a, via shell.py) #flash build/nuc.hex then disconnecting and rerunning make; make j1a connect. This is how you get it to load an app right from poweron - the FPGA config also bootstraps the system with pre-programmed initial ram state.

PPS. Might be nice to be able to use icebram to update the fpga bitfile with the loaded forth state, rather than having to wait for the whole FPGA image to be rebuilt from source when the ram contents change - another nice little 'quality of life' project for someone ;)

[jemo07]

Ah, thank you for the follow up, this did fix the problem... now I can at least hunt down the issue and try to fix it for everyone... will be on two weeks time, I'm on stringent project at the moment. THANK YOU @RGD2 again for following up!

[arblake]

I did not have success with the python script but did succeed using GTKTerm