-
Notifications
You must be signed in to change notification settings - Fork 588
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
litex demo: no response from serial #1441
Comments
@slagernate At which point does it hang? After the upload or right at the beginning? |
Right at the beginning I believe. I’ve never seen a BIOS output with litex -.- |
So connecting to /dev/ttyUSB1 with a serial program like gtkterm or alike (check baudrate) then flashing the fpga doesn't produce any output? Does hitting Could you reveal your target build command and also how you flashed that fpga? I sadly don't know which board file the crosslinkNX is, but maybe the target supports the LEDChaser module. Most of the time, you could simply use |
I'm running: with the following build script. Am flashing using ecpprog: I had also tried using another toolchain for Lattice Nexus devices (prjoxide, but that apparently isn't working for @gatecat anyway). But below is using the Lattice tool chain (radiant / LSE synthesis tool). Any scrutiny or advice is greatly appreciated. Even just a hint as to how to debug this would be helpful. Thanks a lot.
|
Small question: have you checked resistors between TX/RX and FPGA? Same question for the FTDI interfaceB configuration |
The help says R15 and R17 needs to be soldered or if you use any serial pmod header you need to supply the |
Yes, I read the board platform file,
|
Check for security the FTDI configuration (or try to use external pmod uart). |
Sorry, how do you recommend checking the FTDI configuration? I can try using a pmod uart in a bit. |
Pmod is maybe the simpliest way to test yes (keep in mind to select correct serial_pmodxxx). |
gtkterm and litex_term still hanging after fresh upload and "fixing the FTDI" (changing from FIFO mode to UART VCP) --see below. Will try external UART next, using a different commercial ftdi interface.
|
Ok it's confirm by default ftdi interfaceB can't be used as uart interface (I don't know why lattice do that) :-/ |
Sorry, what do you mean "it's confirm by default ftdi interfaceB can't be used as uart interface"? Radiant install on linux is a pain, yeah. Ubuntu 22.04 didn't work for me, but 20.04 works. |
fifo mode is a special mode with 8bits parallel. When a FT2232 is configured in this mode it can't be used as uart (TX/RX) this why I have written this app after spending half an day to figure why I was not able to communicate with my ecp5_evn. With a luck I have radiant 2.0 somewhere in a external HD and with docker will be able to do tests. |
Ah, I see. Yeah both of my boards had FIFO mode as default. I appreciate your script a lot. My devices is ES2, FYI. Will try PMOD uart shortly... |
@trabucayre no luck using an external pmod with one of these 3.3V ftdi converters:
still getting a hanging uart terminal, even after swapping rx and tx (is there any way to easily remember these? :D). The platform file definition for serial_pmod0 mentions PMOD0:0 and PMOD0:1, which I assume is D10 and D9 here:
|
Just an Idea:
in your BaseSoC class. To create a loopback. When you flash that, your serial terminal should show every character you typed. |
Hmm, was getting an error,
with
and no luck (no characters reflected back in gtkterm) (even after swapping pins). Perhaps this is incorrect migen --will try some other migen syntax (I am new to it). I may also just connect a TTL source to RX and see if the TX pin responds on the board. |
Another idea: |
Okay, the loop back is working now. I may or may not have forgotten to plug in the right cable just now :D. So I am sure that my connections are OK. But I definitely had the cable plugged in yesterday. And when I go back to using:
I am not getting anything on the terminal with:
@trabucayre Yes, LED chaser is included, and the LED's are chasing each other. I am using ecpprog to upload the bitstream (and I am sure programming is working and I am using the right .bit file because the loopback is working). My command for this is:
About to check this, but is 115200 the correct bitrate for the default serial UART? |
your uart interface is ttyUSB1:
|
Hmm but it seems ttyUSB1 doesn't exist:
also no response with the following:
|
Could you check TX pin with oscillo / LA ? maybe wrong freq / high error rate? |
@slagernate So I can't test because I don't own that board, but I noticed if you specify |
@trabucayre The uart TX pin looks healthy (normal mode on o-scope showing nice 115200 kbps uart for each key I press). This was definitely helpful though, as now I can verify which ttyUSB* is the correct one (it's ttyUSB0 (I think ttyUSB1 is correct when using the lattice cable, but I'm using an external uart here)). @cklarhorst Just tried this (see below for my build output), no response in the gtkterm. Maybe there is something else wrong / perhaps the cpu is not executing.. is there a way for the CPU/BIOS to toggle an LED (I assume the LED chaser module is independent of the CPU)? @tcal-x, @davidcorrigan714, @alanvgreen would one of you still have your script for when you got your eval board working (with an external serial/UART interface I presume)?
Lattice Radiant toolchain omitted in order to fit comment in 65536 character limit
|
@slagernate There are macros defined in Note that once you write to the LEDs, the LED chasing will stop. That's the intended behavior of the chaser module. |
So digging deeper and looking at On my side, they are always set to:
Maybe just try to change the serial pins in the platform file to your correct ones.
|
@slagernate I suppose TX is for the adapter side and note FPGA side? My interested is to see if frames from embedded CPU are okay (no loopback) |
@cklarhorst ah, of course. Idk why I didnt' think to just check the pdc file to confirm. Alas, even after overriding the default serial uart pins (see below), I am getting the same thing. @trabucayre there is nothing coming out from the FPGA (stuck at 3.3V). Only the UART going into the FPGA is doing anything (when I type in gtkterm).
I will try tcal-x's suggestion of poking the LEDs to confirm if the CPU is even running. Any other debugging tips are welcome. |
It seems I am only able to write to the LEDs (by changing ‘bios/main.c’) if I place the write after the call to uart_init()… |
Interestingly, the following writes to the LEDs every time successfully:
here -k 16 specifies a clock divide ratio of 16 for the ecpprog program. If not included then the LED chaser shows up about 50% of the time. |
Did you check that JP2 is installed? Table 2.1 |
JP2 is installed, but not sure that would help, as I’m using an external serial port (pmod0) with an external ftdi converter. Will try different cpu (and maybe toolchain) in ~9 hours from now. |
@enjoy-digital is this common for basic uart to stop working? |
@cklarhorst (JP1 is removed FYI) |
When I build with a VexRiscV CPU the LEDs either 1) are all completely on (i.e. the bits are all 0), or 2) are driven by the LED chaser module.. which would indicate there's a different issue aside from uart_init(). |
I'm now mostly out of ideas :). |
sw4 appears to reset the board correctly (all LEDs light up). It seems likely that the bios code was updated and subsequently broke the crosslinknx eval board build file. Maybe I will try an older version of litex which lines up with when lattice_crosslink_nx_evn.py was working |
I can try and fire it up again in the next few days. Unfortunately LiteX broke Windows support with some Linux only compilation for one of the libraries and Radiant only works on an older version of Ubuntu than I have installed at the moment so it's a bit of a chore getting it all up again. Suppose starting with the older code may jog my memory. |
@davidcorrigan714 I would really super appreciate that! Thanks |
Well no dice for me either. Maybe it is the new BIOS. Bisecting the commits might be the quickest way to find the breaking change. I found my old bit file and that one boots right up, building off the latest doesn't boot. |
I have retried with my crosslinknx_env LIFLCL-40 9BG400CES:
bios is correctly displayed. I don't remember exactly but not all radiant 2.0 version works correctly. |
If ES2 accepts a bitstream built for ES could you try this one: |
Hi @trabucayre. Thanks a lot for your testing. I agree, it is impossible to squash a bug if we cannot reproduce it. Some comments:
@davidcorrigan714 you are also using the same chip as trabucayre (LIFCL-40 9BG400CES)? I wonder if trabucayre's bitstream would work on your board. Will try older versions of litex momentarily.. I think someone also mentioned trying an external clock too (more stable / reliable perhaps), so will give that a shot. |
Made some progress on getting it working on my board. I have the 9BG400CES version of the chip. Programming it seems a bit finicky, if I use 2.0.1.281.2 to generate the bitstream it programs fine, I haven't figured out how to get Radiant 3.2.1.217.3 to generate a bitstream that works for whatever reason. It errors out with "Failed to program SRAM Done. Mismatch to the device ID code." during programming. Did figure out the UART issue on mine though. In my case it turned out it wasn't reading the bios memory file during synthesis, so no bios, no uart activity. If you search the logs for "lattice_crosslink_nx_evn_rom.init" you should find a line confirming or erroring out when trying to read that in, same for the "lattice_crosslink_nx_evn_mem.init" file. I'm using a bit of an hacked up project using WSL to generate everything then just creating the Radiant project manually in Windows so not quite sure if that's going to be the same problem others are having. But if the LEDs are chasing, then the clocks are up and working so it wouldn't be a clocking issue. If it is the file issue, not quite sure what the right fix is, I just manually added the full path into lattice_crosslink_nx_evn.v which fixed it on mine though of course gets reset out with every regen. There should be a way to get the files in the right spots or add them to the project through some tcl commands. |
Looks like with the original ES version can't use any newer version of Radiant. From the user guide: "The CrossLink-NX Evaluation Board assembly is updated with the LIFCL-40-9BG400CES2 (ES2 silicon) device. With the Wonder if it's worth making a note of the ES/ES2 discrepancies in the code somewhere. |
@slagernate when I try to use |
Hi @trabucayre, @davidcorrigan714, all, Sorry for the delay in getting back. In trying to set up a reproducible environment, I was able to get it to work. I.e. bios is showing up consistently. I believe I may have installed something incorrectly initially. Thank you all for your help. The steps to reproduce are as follows, using multipass:
|
although it seems the BIOS CRC is failing:
|
switched from using |
I'm running through the README.md in the soc/software/demo folder. I'm able to build the bitstream and compile demo.bin. But litex_term is hanging when I run:
Am using a picorv32 cpu on the lattice crosslinkNX eval board. Am using the radiant tool chain, specifically with the LSE synthesis tool (the synplify pro tool is not working for me). I guess this may or may not be related to the wishbone tool hanging for me as well.
The text was updated successfully, but these errors were encountered: