Can't connect using Python or Picocom when building from scratch #15
Comments
|
Tried reverting to revision 4f6ece5, that builds from scratch OK. Maybe it's something to do with the PLL implementation? |
|
1e8708f works as well. |
|
Hmm, interesting. Just to confirm, this is with latest Also, I am building on 64-bit Linux. When I go to 05cad81 and a956fe0 I see both fail to place with the above tools. But the latest does place successfully, and does seem to be alive. |
|
Thanks for getting back to me. Cloned a fresh copy of swapforth: Then started to make and program: Then tried to connect with Python... it hung with no output for a while, pressed ^C and got the output (note that 'Contacting...' came out after pressing ctrl+C) |
|
Oh, is this 32-bit or 64-bit? |
64 Bit looks like to me. Admittedly, I'm running in VMware Fusion, but that shouldn't effect it? (also, I'm online right now, so if there's any checks you can recommend I'd be able to run them quickly!) Thanks much! |
|
Yes, please do you get: |
|
Yep! hmm.... |
|
Just to be sure, for a test, I've just cloned again, programmed the icestick and run the python shell. Here's what I get: So, that works! |
|
There's a difference in the bin files? |
|
(swapforth_2 is the freshly cloned directory btw, swapforth is where I'm trying to build from scratch) |
|
Right. At this point it looks like yosys/arache-pnr is where the difference lies. OK... puzzling. |
|
Yep, also, my colleague B was having similar troubles. It's likely he was If you think of anything else you'd like me to check, or if you want to On Fri, Oct 16, 2015 at 12:19 AM, James Bowman [email protected]
|
|
@BarnabyShearer was also suffering from this. |
|
One thing... you are running a more recent Ubuntu than me. |
|
I'm on 15.04, what's yours? Happy to spin up another VM to try it? |
|
Will do... I am on On Thu, Oct 15, 2015 at 4:54 PM, Ryan [email protected] wrote:
James Bowman |
|
I'm on Ubuntu 14.04.3 LTS, with much the same problem... connecting after a clean build results in no action. short HEAD's are:
When I drop the rebuild: This one works... |
|
Oh, just a note: the first build works fine, it's the second one (after #flash build/nuc.hex, and rerunning make -C icestorm and reprogramming icestorm/j1a.bin ) that doesn't, for me at least. |
|
Running with the master j1a.bin, adding some code, then using Shouldn't this procedure result in a new image with the added code included? @jamesbowman : Should I make a new issue for this? |
|
@RGD2 no new issue, thanks. These are all the same root cause. Under some circumstances the synthesis toolchain (arache-pnr, yoysys, icestorm) produces a bad FPGA image. |
|
Well, is there something I could do to help? I'm newcomer to forth, but I already know I want swapforth in my labs, controlling my equipment. |
|
Hey all, should be able to get back on this soon BTW. I haven't tested R
|
|
This one's closed for me. @robot-army is it still broken at your end? |
|
Works on livebooted Ubuntu 15.10 (if you enable universe and multiverse in "Software & Updates" first) |
|
Hi, I'm experimenting with icestick & swapforth too, but on Windows with tools compiled using last mingw-w64-gcc-6.1.0 x64 toolchain. I'm using development versions of yosys and arachne-pnr form their respective master branches. |
|
I have the same issue. I'm running a fully updated Arch Linux and the latest checkouts of all the necessary tools and swapforth. No output when using the python shell here as well. EDIT: The version of j1a.bin in the repos also does not work. |
|
Hi, for no output running python shell I had to comment out: .. in reset() function. I am running latest Arch as well. I also found I had to run shell.py with python2 not python3, otherwise the #flash command would not work. See my reported issues here: [(https://github.com//issues/38)] |
|
As soon as I get my icestick back I'll test! On Sep 28, 2016 7:17 PM, "bmentink" [email protected] wrote:
|
I've tried this with the latest Arch Linux, and with both Python 2 and 3 I get the expected output: However, I do not see any output from commands. Here's an example: Again, this is with both Python 2 and 3. The led blinking and easter examples also do not work. After trying a few commands, the system behaves as if I had written something else, like outputting the output of I did follow the building from scratch part of the README. EDIT: However the blinking example does not work: I cannot fill in the rest of the new words Did something change in the language? |
|
Is it locking up after the first newline in that blink example there? Does it work if you put the whole example on one line? (which should cause shell.py to send it as a line). |
…amesbowman#39 This contains an alternate buart() module for asynchronous RS232. - will resynchronise itself at every start bit transition - rejects bad characters - does not clobber last valid data - keeps the most recently received character, 'valid' flag always clears on read. - works reliably up to 921600 baud on both ice40hx8k breakout and iceStick - works with other 'logic level' rs232 devices offboard, or via max232 chips to true rs232 ports. - easy to instantiate multiple ports with different baud rates This also adds a "make pcon" option to remember the settings for connecting with picocom, which is useful for testing character-by-character operation, as well as manual control over the reset line. It sometimes works if the uart connection is marginal, and shell.py gets stuck on connect.
…amesbowman#39 This contains an alternate buart() module for asynchronous RS232. - will resynchronise itself at every start bit transition - rejects bad characters - does not clobber last valid data - keeps the most recently received character, 'valid' flag always clears on read. - works reliably up to 921600 baud on both ice40hx8k breakout and iceStick - works with other 'logic level' rs232 devices offboard, or via max232 chips to true rs232 ports. - easy to instantiate multiple ports with different baud rates This also adds a "make pcon" option to remember the settings for connecting with picocom, which is useful for testing character-by-character operation, as well as manual control over the reset line. It sometimes works if the uart connection is marginal, and shell.py gets stuck on connect.
|
To make it work, I had the same experience as robot-army: Another issue I had was with the #flash command, still in shell.py, had to change one line in the serialize() function (last argument of ljust, binary string litteral instead of character that gave me an error, note: I'm using python 3) |
…amesbowman#39 This contains an alternate buart() module for asynchronous RS232. - will resynchronise itself at every start bit transition - rejects bad characters - does not clobber last valid data - keeps the most recently received character, 'valid' flag always clears on read. - works reliably up to 921600 baud on both ice40hx8k breakout and iceStick - works with other 'logic level' rs232 devices offboard, or via max232 chips to true rs232 ports. - easy to instantiate multiple ports with different baud rates
Hi there,
I've tried building from scratch as per the reference document here: https://github.com/jamesbowman/swapforth/raw/master/j1a/doc/j1a-reference.pdf
The Verilog seems to build and program OK, but when trying to connect using the python terminal I get nothing.
Note that using the j1a.bin as build in the repo works fine and gives me the correct response of:
Contacting... established
Loaded 208 words
I've tried checking out the last build that changed the j1a.bin file and building from scratch there, but it failed as well.
Colour me confused, any tips?
The text was updated successfully, but these errors were encountered: