Skip to content
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

Closed
slagernate opened this issue Sep 26, 2022 · 50 comments
Closed

litex demo: no response from serial #1441

slagernate opened this issue Sep 26, 2022 · 50 comments

Comments

@slagernate
Copy link
Contributor

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:

litex_term /dev/ttyUSB1 --kernel=demo.bin

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.

@slagernate slagernate changed the title litex_term hanging litex demo: litex_term hanging Sep 26, 2022
@cklarhorst
Copy link
Contributor

@slagernate At which point does it hang? After the upload or right at the beginning?
Did you check if /dev/ttyUSB1 has the normal bios output?

@slagernate
Copy link
Contributor Author

Right at the beginning I believe.

I’ve never seen a BIOS output with litex -.-

@cklarhorst
Copy link
Contributor

cklarhorst commented Sep 27, 2022

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 enter also not reveal a prompt?

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 --with-led-chaser to check if your fpga flashing process / clks etc. are working.

@slagernate
Copy link
Contributor Author

gtkterm -s 115200 -p /dev/ttyUSB1 produces a blank terminal --hitting enter does nothing, sadly.

I'm running:
python3 -m litex_boards.targets.lattice_crosslink_nx_evn --build --cpu-type=picorv32

with the following build script. Am flashing using ecpprog: ecpprog -S $(name_of_bitstream), and the LED chaser module (which is enabled by default I believe) is working.

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.

#!/usr/bin/env python3

#
# This file is part of LiteX-Boards.
#
# Copyright (c) 2020 David Corrigan <[email protected]>
# Copyright (c) 2020 Alan Green <[email protected]>
# SPDX-License-Identifier: BSD-2-Clause

from migen import *
from migen.genlib.resetsync import AsyncResetSynchronizer

from litex_boards.platforms import lattice_crosslink_nx_evn

from litex.soc.cores.ram import NXLRAM
from litex.soc.cores.clock import NXPLL
from litex.build.io import CRG
from litex.build.generic_platform import *

from litex.soc.cores.clock import *
from litex.soc.integration.soc_core import *
from litex.soc.integration.builder import *
from litex.soc.cores.led import LedChaser

from litex.build.lattice.oxide import oxide_args, oxide_argdict

kB = 1024
mB = 1024*kB


# CRG ----------------------------------------------------------------------------------------------

class _CRG(Module):
    def __init__(self, platform, sys_clk_freq):
        self.clock_domains.cd_por = ClockDomain()
        self.clock_domains.cd_sys = ClockDomain()

        # Built in OSC
        self.submodules.hf_clk = NXOSCA()
        hf_clk_freq = 12e6
        self.hf_clk.create_hf_clk(self.cd_por, hf_clk_freq)

        # Power on reset
        por_count = Signal(16, reset=2**16-1)
        por_done  = Signal()
        self.comb += por_done.eq(por_count == 0)
        self.sync.por += If(~por_done, por_count.eq(por_count - 1))

        self.rst_n = platform.request("gsrn")
        self.specials += AsyncResetSynchronizer(self.cd_por, ~self.rst_n)

        # PLL
        self.submodules.sys_pll = sys_pll = NXPLL(platform=platform, create_output_port_clocks=True)
        sys_pll.register_clkin(self.cd_por.clk, hf_clk_freq)
        sys_pll.create_clkout(self.cd_sys, sys_clk_freq)
        self.specials += AsyncResetSynchronizer(self.cd_sys, ~self.sys_pll.locked | ~por_done )


# BaseSoC ------------------------------------------------------------------------------------------

class BaseSoC(SoCCore):
    mem_map = {
        "rom"  : 0x00000000,
        "sram" : 0x40000000,
        "csr"  : 0xf0000000,
    }
    def __init__(self, sys_clk_freq=int(75e6), device="LIFCL-40-9BG400C", toolchain="radiant", with_led_chaser=True, **kwargs):
        platform = lattice_crosslink_nx_evn.Platform(device=device, toolchain=toolchain)

        # CRG --------------------------------------------------------------------------------------
        self.submodules.crg = _CRG(platform, sys_clk_freq)

        # SoCCore -----------------------------------------_----------------------------------------
        # Disable Integrated SRAM since we want to instantiate LRAM specifically for it
        kwargs["integrated_sram_size"] = 0
        # Make serial_pmods available
        platform.add_extension(lattice_crosslink_nx_evn.serial_pmods)
        SoCCore.__init__(self, platform, sys_clk_freq, ident="LiteX SoC on Crosslink-NX Evaluation Board", **kwargs)

        # 128KB LRAM (used as SRAM) ---------------------------------------------------------------
        size = 128*kB
        self.submodules.spram = NXLRAM(32, size)
        self.register_mem("sram", self.mem_map["sram"], self.spram.bus, size)

        # Leds -------------------------------------------------------------------------------------
        if with_led_chaser:
            self.submodules.leds = LedChaser(
                pads         = Cat(*[platform.request("user_led", i) for i in range(14)]),
                sys_clk_freq = sys_clk_freq)

# Build --------------------------------------------------------------------------------------------

def main():
    from litex.soc.integration.soc import LiteXSoCArgumentParser
    parser = LiteXSoCArgumentParser(description="LiteX SoC on Crosslink-NX Eval Board")
    target_group = parser.add_argument_group(title="Target options")
    target_group.add_argument("--build",         action="store_true",        help="Build design.")
    target_group.add_argument("--load",          action="store_true",        help="Load bitstream.")
    target_group.add_argument("--toolchain",     default="radiant",          help="FPGA toolchain (radiant or prjoxide).")
    target_group.add_argument("--device",        default="LIFCL-40-9BG400C", help="FPGA device (LIFCL-40-9BG400C or LIFCL-40-8BG400CES).")
    target_group.add_argument("--sys-clk-freq",  default=75e6,               help="System clock frequency.")
    target_group.add_argument("--serial",        default="serial",           help="UART Pins (serial (requires R15 and R17 to be soldered) or serial_pmod[0-2]).")
    target_group.add_argument("--prog-target",   default="direct",           help="Programming Target (direct or flash).")
    builder_args(parser)
    soc_core_args(parser)
    oxide_args(parser)
    args = parser.parse_args()

    soc = BaseSoC(
        sys_clk_freq = int(float(args.sys_clk_freq)),
        device       = args.device,
        toolchain    = args.toolchain,
        **soc_core_argdict(args)
    )
    builder = Builder(soc, **builder_argdict(args))
    print(args)
    builder_kargs = oxide_argdict(args) if args.toolchain == "oxide" else {'synth_mode': "lse"}
    if args.build:
        builder.build(**builder_kargs)

    if args.load:
        prog = soc.platform.create_programmer(args.prog_target)
        prog.load_bitstream(builder.get_bitstream_filename(mode="sram"))

if __name__ == "__main__":
    main()

@trabucayre
Copy link
Collaborator

Small question: have you checked resistors between TX/RX and FPGA? Same question for the FTDI interfaceB configuration
I don't remember if it's the same case as ecp5_evn, but for this it's required to follow these instructions.

@cklarhorst
Copy link
Contributor

cklarhorst commented Sep 27, 2022

The help says R15 and R17 needs to be soldered or if you use any serial pmod header you need to supply the --serial option.

@slagernate
Copy link
Contributor Author

slagernate commented Sep 27, 2022

Yes, I read the board platform file,
https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/lattice_crosslink_nx_evn.py (lines 28-33)
and installed R15 and R17 some time ago:

    # Section 6.2 UART Topology
    # Requires installation of 0-ohm jumpers R15 and R17 to properly route signals
    # Note that it is R15 and R17, not R16 and R17 as stated in the user guide
    ("serial", 0,
        Subsignal("rx", Pins("F16"), IOStandard("LVCMOS33")),
        Subsignal("tx", Pins("F18"), IOStandard("LVCMOS33")),
    ),

@trabucayre
Copy link
Collaborator

Check for security the FTDI configuration (or try to use external pmod uart).

@slagernate
Copy link
Contributor Author

Sorry, how do you recommend checking the FTDI configuration? I can try using a pmod uart in a bit.

@trabucayre
Copy link
Collaborator

Pmod is maybe the simpliest way to test yes (keep in mind to select correct serial_pmodxxx).
to check configuration (in fact to reconfigure interfaceB) this tool do the job (name is wrong since it address ecp5_evn AND crosslink_nx_evn.

@slagernate
Copy link
Contributor Author

slagernate commented Sep 27, 2022

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.

$ ./fixFT2232_ecp5evn -v 0x403 -p 0x6010

vendor 403 product 6010


Default configuration

VID:     0x0403
PID:     0x6010
Release: 0x0700
Self-Powered
Manufacturer: Lattice
Product:      Lattice CrossLink-NX Eval Board
Serial:       FT5OCAO4
Checksum      : 2799
Attached EEPROM: 93x56
PNP: 1
Channel A has Mode FIFO
Channel B has Mode FIFO
AL has 8 mA drive
AH has 8 mA drive
BL has 8 mA drive
BH has 8 mA drive


New configuration

VID:     0x0403
PID:     0x6010
Release: 0x0700
Self-Powered
Manufacturer: Lattice
Product:      Lattice CrossLink-NX Eval Board
Serial:       FT5OCAO4
Checksum      : 25b7
Attached EEPROM: 93x56
PNP: 1
Channel A has Mode FIFO
Channel B has Mode UART VCP
AL has 8 mA drive
AH has 8 mA drive
BL has 4 mA drive Slow Slew
BH has 4 mA drive Slow Slew
EEPROM updated
FTDI close: 0

@trabucayre
Copy link
Collaborator

Ok it's confirm by default ftdi interfaceB can't be used as uart interface (I don't know why lattice do that) :-/
I have to try with my board (not today) but it's based on an ES device, I'm not sure I will be able to reinstall radiant (if it's always possible to download the version compatible with my device).

@slagernate
Copy link
Contributor Author

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.

@trabucayre
Copy link
Collaborator

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.

@slagernate
Copy link
Contributor Author

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...

@slagernate
Copy link
Contributor Author

@trabucayre no luck using an external pmod with one of these 3.3V ftdi converters:

python3 lattice_crosslink_nx_evn.py --build --cpu-type picorv32 --serial serial_pmod0 > out.txt 2>&1

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:


    # Section 8.6 PMOD Header
    # PMOD signal number:
    #          1   2  3  4  7  8  9   10
    ("PMOD0", "D10 D9 D7 D8 D6 D5 D4  D3"),
    ("PMOD1", "E10 E9 E7 E8 E4 E3 E2  F1"),
    ("PMOD2", "J2  J1 K2 K1 K3 K4 D17 E18"),
]

# Test and Demo ------------------------------------------------------------------------------------

serial_pmods = [
    ("serial_pmod0", 0,
        Subsignal("rx", Pins("PMOD0:0"), IOStandard("LVCMOS33")),
        Subsignal("tx", Pins("PMOD0:1"), IOStandard("LVCMOS33")),
    ),

@cklarhorst
Copy link
Contributor

Just an Idea:
Put something like (I have not tested that code):

tmp = platform.request("serial_pmod0")
self.comb += [tmp[0].eq(tmp[1])] # connect RX with TX

in your BaseSoC class. To create a loopback. When you flash that, your serial terminal should show every character you typed.
Then at least you can be sure that you have connected everything correctly.

@slagernate
Copy link
Contributor Author

Hmm, was getting an error, TypeError: 'Record' object is not subscriptable so tried the following:

        tmp = platform.request("serial_pmod0")
        self.comb += tmp.tx.eq(tmp.rx) # connect RX with TX

with

python3 lattice_crosslink_nx_evn.py --build --cpu-type picorv32 > out.txt 2>&1

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.

@trabucayre
Copy link
Collaborator

Another idea:
ledChaser is enabled by default: have you leds blinking?
Just to know if the bitstream is compatible with your device (maybe a fail or incompatibility is ignored by the programmer tool?)

@slagernate
Copy link
Contributor Author

slagernate commented Sep 28, 2022

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:

python3 lattice_crosslink_nx_evn.py --build --cpu-type picorv32 --serial serial_pmod0 > out.txt 2>&1

I am not getting anything on the terminal with:

sudo gtkterm -s 115200 -p /dev/ttyUSB0

@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:

$ ecpprog -S build/lattice_crosslink_nx_evn/gateware/impl/lattice_crosslink_nx_evn_impl.bit 
init..
IDCODE: 0x110f1043 (LIFCL-40)
NX Status Register: 0x0000110100400100
reset..
ISC_ENABLE
ISC_ERASE
LSC_RESET_CRC
NX Status Register: 0x0000110100400e50
programming..
LSC_BITSTREAM_BURST
ISC_DISABLE
NX Status Register: 0x0000110100400100
Bye.

About to check this, but is 115200 the correct bitrate for the default serial UART?

@trabucayre
Copy link
Collaborator

your uart interface is ttyUSB1:

  • ttyUSB0 is the jtag interface
  • ttyUSB1 (ie interfaceB) is the uart)

@slagernate
Copy link
Contributor Author

Hmm but it seems ttyUSB1 doesn't exist:

$ ls /dev/ttyUSB*
/dev/ttyUSB0  /dev/ttyUSB2

also no response with the following:

sudo gtkterm -s 115200 -p /dev/ttyUSB2

@trabucayre
Copy link
Collaborator

Could you check TX pin with oscillo / LA ? maybe wrong freq / high error rate?

@cklarhorst
Copy link
Contributor

cklarhorst commented Sep 28, 2022

@slagernate
Could you please test:
lattice_crosslink_nx_evn.py --uart-name 'serial_pmod0'

So I can't test because I don't own that board, but I noticed if you specify --serial asd you don't get any error. So maybe that argument is somehow broken. On Xilinx boards, I most of the time use --uart-name and I tried it with your target file and the script doesn't complain.

@slagernate
Copy link
Contributor Author

slagernate commented Sep 28, 2022

@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)?

python3 lattice_crosslink_nx_evn.py --build --cpu-type picorv32 --uart-name 'serial_pmod0' > out.txt 2>&1

INFO:NXOSCA:Creating NXOSCA.
INFO:NXOSCA:Creating  ClkOut-1 por  of  12.00MHz  (+-50000.00ppm).
INFO:NXPLL:Creating NXPLL.
INFO:NXPLL:Registering  Single Ended   ClkIn  of  12.00MHz .
INFO:NXPLL:Creating  ClkOut0 sys  of  75.00MHz  (+-10000.00ppm).
INFO:SoC:         __   _ __      _  __   
INFO:SoC:        / /  (_) /____ | |/_/   
INFO:SoC:       / /__/ / __/ -_)>  <     
INFO:SoC:      /____/_/\__/\__/_/|_|   
INFO:SoC:   Build your hardware, easily! 
INFO:SoC: -------------------------------------------------------------------------------- 
INFO:SoC: Creating SoC... (2022-09-28 13:21:56) 
INFO:SoC: -------------------------------------------------------------------------------- 
INFO:SoC:FPGA device : LIFCL-40-9BG400C.
INFO:SoC:System clock: 75.000MHz.
INFO:SoCBusHandler:Creating Bus Handler...
INFO:SoCBusHandler: 32 -bit  wishbone  Bus,  4.0 GiB Address Space.
INFO:SoCBusHandler:Adding  reserved  Bus Regions...
INFO:SoCBusHandler:Bus Handler  created .
INFO:SoCCSRHandler:Creating CSR Handler...
INFO:SoCCSRHandler: 32 -bit CSR Bus,  32 -bit Aligned,  16.0 KiB Address Space,  2048 B Paging,  big  Ordering (Up to  32  Locations).
INFO:SoCCSRHandler:Adding  reserved  CSRs...
INFO:SoCCSRHandler:CSR Handler  created .
INFO:SoCIRQHandler:Creating IRQ Handler...
INFO:SoCIRQHandler:IRQ Handler (up to  32  Locations).
INFO:SoCIRQHandler:Adding  reserved  IRQs...
INFO:SoCIRQHandler:IRQ Handler  created .
INFO:SoC: -------------------------------------------------------------------------------- 
INFO:SoC: Initial SoC: 
INFO:SoC: -------------------------------------------------------------------------------- 
INFO:SoC: 32 -bit  wishbone  Bus,  4.0 GiB Address Space.
INFO:SoC: 32 -bit CSR Bus,  32 -bit Aligned,  16.0 KiB Address Space,  2048 B Paging,  big  Ordering (Up to  32  Locations).
INFO:SoC:IRQ Handler (up to  32  Locations).
INFO:SoC: -------------------------------------------------------------------------------- 
INFO:SoC:Controller  ctrl   added .
INFO:SoC:CPU  picorv32   added .
INFO:SoC:CPU  picorv32   adding  IO Region  0  at  0x80000000  (Size:  0x80000000 ).
INFO:SoCBusHandler: io0  Region  added  at Origin:  0x80000000 , Size:  0x80000000 , Mode:  RW , Cached:  False  Linker:  False .
INFO:SoC:CPU  picorv32   overriding   csr  mapping from  0xf0000000  to  0x82000000 .
INFO:SoC:CPU  picorv32   setting  reset address to  0x00000000 .
INFO:SoC:CPU  picorv32   adding  Bus Master(s).
INFO:SoCBusHandler: cpu_bus0   added  as Bus Master.
INFO:SoC:CPU  picorv32   adding  Interrupt(s).
INFO:SoCBusHandler: rom  Region  added  at Origin:  0x00000000 , Size:  0x00020000 , Mode:  R , Cached:  True  Linker:  False .
INFO:SoCBusHandler: rom   added  as Bus Slave.
INFO:SoC:RAM  rom   added  Origin:  0x00000000 , Size:  0x00020000 , Mode:  R , Cached:  True  Linker:  False .
INFO:SoCIRQHandler: uart  IRQ  allocated  at Location  0 .
INFO:SoCIRQHandler: timer0  IRQ  allocated  at Location  1 .
INFO:SoCBusHandler: sram  Region  added  at Origin:  0x40000000 , Size:  0x00020000 , Mode:  RW , Cached:  True  Linker:  False .
INFO:SoCBusHandler: sram   added  as Bus Slave.
INFO:SoC:CSR Bridge  csr   added .
INFO:SoCBusHandler: csr  Region  added  at Origin:  0x82000000 , Size:  0x00010000 , Mode:  RW , Cached:  False  Linker:  False .
INFO:SoCBusHandler: csr   added  as Bus Slave.
INFO:SoCCSRHandler: csr   added  as CSR Master.
INFO:SoCBusHandler:Interconnect:  InterconnectShared  ( 1  <->  3 ).
INFO:SoCCSRHandler: ctrl  CSR  allocated  at Location  0 .
INFO:SoCCSRHandler: identifier_mem  CSR  allocated  at Location  1 .
INFO:SoCCSRHandler: leds  CSR  allocated  at Location  2 .
INFO:SoCCSRHandler: timer0  CSR  allocated  at Location  3 .
INFO:SoCCSRHandler: uart  CSR  allocated  at Location  4 .
INFO:SoC: -------------------------------------------------------------------------------- 
INFO:SoC: Finalized SoC: 
INFO:SoC: -------------------------------------------------------------------------------- 
INFO:SoC: 32 -bit  wishbone  Bus,  4.0 GiB Address Space.
IO Regions: (1)
 io0                  : Origin:  0x80000000 , Size:  0x80000000 , Mode:  RW , Cached:  False  Linker:  False 
Bus Regions: (3)
 rom                  : Origin:  0x00000000 , Size:  0x00020000 , Mode:  R , Cached:  True  Linker:  False 
 sram                 : Origin:  0x40000000 , Size:  0x00020000 , Mode:  RW , Cached:  True  Linker:  False 
 csr                  : Origin:  0x82000000 , Size:  0x00010000 , Mode:  RW , Cached:  False  Linker:  False 
Bus Masters: (1)
-  cpu_bus0 
Bus Slaves: (3)
-  rom 
-  sram 
-  csr 
INFO:SoC: 32 -bit CSR Bus,  32 -bit Aligned,  16.0 KiB Address Space,  2048 B Paging,  big  Ordering (Up to  32  Locations).
CSR Locations: (5)
-  ctrl            :  0 
-  identifier_mem  :  1 
-  leds            :  2 
-  timer0          :  3 
-  uart            :  4 
INFO:SoC:IRQ Handler (up to  32  Locations).
IRQ Locations: (2)
-  uart    :  0 
-  timer0  :  1 
INFO:SoC: -------------------------------------------------------------------------------- 
INFO:NXOSCA:Config:
freq: 12.50MHz
div : 35
INFO:NXPLL:Config:
clki_div   : 1
clko0_freq : 75.27MHz
clko0_div  : 11
clko0_phase: 0.00°
vco        : 828.00MHz
clkfb_div  : 69
make[1]: Entering directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/libc'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/libc'
make[1]: Entering directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/libcompiler_rt'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/libcompiler_rt'
make[1]: Entering directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/libbase'
 CC       console.o
 CC       system.o
 CC       memtest.o
 CC       uart.o
 CC       spiflash.o
 CC       i2c.o
 CC       isr.o
 AR       libbase.a
make[1]: Leaving directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/libbase'
make[1]: Entering directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/libfatfs'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/libfatfs'
make[1]: Entering directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/liblitespi'
 CC       spiflash.o
 AR       liblitespi.a
make[1]: Leaving directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/liblitespi'
make[1]: Entering directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/liblitedram'
 CC       sdram.o
 CC       bist.o
 CC       sdram_dbg.o
 AR       liblitedram.a
make[1]: Leaving directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/liblitedram'
make[1]: Entering directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/libliteeth'
 CC       udp.o
 CC       mdio.o
 AR       libliteeth.a
make[1]: Leaving directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/libliteeth'
make[1]: Entering directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/liblitesdcard'
 CC       sdcard.o
 CC       spisdcard.o
 AR       liblitesdcard.a
make[1]: Leaving directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/liblitesdcard'
make[1]: Entering directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/liblitesata'
 CC       sata.o
 AR       liblitesata.a
make[1]: Leaving directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/liblitesata'
make[1]: Entering directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/bios'
 CC       boot.o
 CC       cmd_bios.o
 CC       cmd_mem.o
 CC       cmd_boot.o
 CC       cmd_i2c.o
 CC       cmd_spiflash.o
 CC       cmd_litedram.o
 CC       cmd_liteeth.o
 CC       cmd_litesdcard.o
 CC       cmd_litesata.o
 CC       sim_debug.o
 CC       main.o
 CC       crt0.o
 CC       bios.elf
chmod -x bios.elf
 OBJCOPY  bios.bin
chmod -x bios.bin
python3 -m litex.soc.software.crcfbigen bios.bin --little
python3 -m litex.soc.software.memusage bios.elf /home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/bios/../include/generated/regions.ld riscv64-unknown-elf

ROM usage: 23.56KiB 	(18.41%)
RAM usage: 2.74KiB 	(2.14%)

rm crt0.o
make[1]: Leaving directory '/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/software/bios'
INFO:SoC:Initializing ROM  rom  with contents (Size:  0x5e4c ).
INFO:SoC:Auto-Resizing ROM  rom  from  0x20000  to  0x5e4c .
WARNING - Create a new implementation in an existing sub-directory 'impl'.

"/home/nates/lscc/radiant/3.2/tcltk/linux/bin/tclsh" "lattice_crosslink_nx_evn_impl_synthesize.tcl"

synthesis -f lattice_crosslink_nx_evn_impl_lattice.synproj
synthesis:  version Radiant Software (64-bit) 3.2.0.18.0

Copyright (c) 1991-1994 by NeoCAD Inc. All rights reserved.
Copyright (c) 1995 AT&T Corp.   All rights reserved.
Copyright (c) 1995-2001 Lucent Technologies Inc.  All rights reserved.
Copyright (c) 2001 Agere Systems   All rights reserved.
Copyright (c) 2002-2022 Lattice Semiconductor Corporation,  All rights reserved.
Wed Sep 28 13:21:59 2022


Command Line:  synthesis -f lattice_crosslink_nx_evn_impl_lattice.synproj 

INFO - synthesis: Lattice Synthesis Engine Launched.
Synthesis options:
The -a option is LIFCL.
The -t option is CABGA400.
The -sp option is 9_High-Performance_1.0V.
The -p option is LIFCL-40.
        
...        

Lattice Radiant toolchain omitted in order to fit comment in 65536 character limit

...

Saving bit stream in "/home/nates/litex/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/gateware/impl/lattice_crosslink_nx_evn_impl.bit".
Bitstream generation complete!

Total CPU Time: 6 secs 
Total REAL Time: 6 secs 
Peak Memory Usage: 792 MB

@tcal-x
Copy link
Collaborator

tcal-x commented Sep 28, 2022

@slagernate There are macros defined in $builddir/software/include/generated/csr.h for poking the LEDs, so yeah, add a call in the BIOS code to write a non-zero value (or a zero value). You might need to add #include "generated/csr.h" if there isn't one already.

Note that once you write to the LEDs, the LED chasing will stop. That's the intended behavior of the chaser module.

@cklarhorst
Copy link
Contributor

cklarhorst commented Sep 28, 2022

So digging deeper and looking at build/lattice_crosslink_nx_evn/gateware/lattice_crosslink_nx_evn.pdc I found out that the serial_tx rx pins are not changed by either --uart-name or --serial.

On my side, they are always set to:

ldc_set_location -site {F16} [get_ports serial_rx]
ldc_set_port -iobuf {IO_TYPE=LVCMOS33} [get_ports serial_rx]
ldc_set_location -site {F18} [get_ports serial_tx]
ldc_set_port -iobuf {IO_TYPE=LVCMOS33} [get_ports serial_tx]

Maybe just try to change the serial pins in the platform file to your correct ones.

 ("serial", 0,
        Subsignal("rx", Pins("F16"), IOStandard("LVCMOS33")),
        Subsignal("tx", Pins("F18"), IOStandard("LVCMOS33")),
    ),

@trabucayre
Copy link
Collaborator

@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)

@slagernate
Copy link
Contributor Author

slagernate commented Sep 28, 2022

@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).

ldc_set_location -site {D10} [get_ports serial_rx]
ldc_set_location -site {D9} [get_ports serial_tx]

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.

@slagernate
Copy link
Contributor Author

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()

@slagernate slagernate changed the title litex demo: litex_term hanging litex demo: litex_term hanging (uart not working) Sep 28, 2022
@slagernate
Copy link
Contributor Author

Interestingly, the following writes to the LEDs every time successfully:

ecpprog -S -k 16 build/lattice_crosslink_nx_evn/gateware/impl/lattice_crosslink_nx_evn_impl.bit

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.

@cklarhorst
Copy link
Contributor

Did you check that JP2 is installed? Table 2.1
(I think that table also says that for the board serial, you have to remove JP1)
Maybe also try another CPU type like VexRiscV.

@slagernate
Copy link
Contributor Author

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.

@slagernate
Copy link
Contributor Author

@enjoy-digital is this common for basic uart to stop working?

@slagernate
Copy link
Contributor Author

@cklarhorst (JP1 is removed FYI)

@slagernate
Copy link
Contributor Author

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().

@slagernate slagernate changed the title litex demo: litex_term hanging (uart not working) litex demo: no response from serial Sep 29, 2022
@cklarhorst
Copy link
Contributor

cklarhorst commented Sep 29, 2022

I'm now mostly out of ideas :).
Did you already try to push the buttons (especially sw4 for reset) on the board?
Maybe your sys_clk is somehow wrong, you could try to connect sys_clk to an IO (same way as you build the loopback) and measure that with an oscilloscope.

@slagernate
Copy link
Contributor Author

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

@davidcorrigan714
Copy link
Contributor

davidcorrigan714 commented Sep 30, 2022

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.

@slagernate
Copy link
Contributor Author

@davidcorrigan714 I would really super appreciate that! Thanks

@davidcorrigan714
Copy link
Contributor

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.

@trabucayre
Copy link
Collaborator

I have retried with my crosslinknx_env LIFLCL-40 9BG400CES:

  • a new user -> empty .local and no risk with residuals
  • litex from scratch with: ./litex_setup.py --init --install --user --config=full and ./litex_setup.py --gcc riscv
  • radiant version Version 2.0.1.281.2 (synplify used for synthesis)
  • a digilent pmod uart connect on pmod0
  • command ./lattice_crosslink_nx_evn.py --build --serial serial_pmod0
  • a screen : screen /dev/ttyUSB1 115200

bios is correctly displayed.

I don't remember exactly but not all radiant 2.0 version works correctly.
Minor differences (but I think not relevant): I use a gentoo (up to date) and openFPGALoader
I usually prefers when it's possible to reproduce an issue -> it's more easy to find why it's not working...

@trabucayre
Copy link
Collaborator

If ES2 accepts a bitstream built for ES could you try this one:
http://kmf2.trabucayre.com/lattice_crosslink_nx_evn.bit

@slagernate
Copy link
Contributor Author

Hi @trabucayre. Thanks a lot for your testing. I agree, it is impossible to squash a bug if we cannot reproduce it. Some comments:
If you have a CES device, shouldn't your ./lattice_crosslink_nx_evn.py command include --device LIFCL-40-8BG400CES? Unfortunately, the bitstream you sent won't flash to my board (even if I changed the IDCODE manually).
Some ideas to try:
A. Build for CES2 (which is the same as the 'C' devices) and share the resulting bitstream for me to try
B. Use the same synthesis tool (Lattice LSE) I am using (currently synplify pro won't synthesize for me on the command line (Radiant 3.2.0.18.0) --it spits out: @E| Mal-formed command line - please check for extra quotes in macro specification. Can specify LSE with builder_kargs = {'synth_mode': "lse"}, i.e.:

    builder_kargs = oxide_argdict(args) if args.toolchain == "oxide" else {'synth_mode': "lse"} 

@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.

@davidcorrigan714
Copy link
Contributor

davidcorrigan714 commented Oct 2, 2022

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.

@davidcorrigan714
Copy link
Contributor

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
ES2 device, the board is supported by Lattice Radiant version 2.2 or later. With the previous ES device, the board is
supported only by Lattice Radiant version 2.0"

Wonder if it's worth making a note of the ES/ES2 discrepancies in the code somewhere.

@trabucayre
Copy link
Collaborator

@slagernate when I try to use --device LIFCL-40-9BG400CES radiant complains about invalid argument. and with lse the bitstream is not working at all (no blink).
@davidcorrigan714 Yes I have seen radiant 3 is not compatible with ES. Your mismatch is due to idcode : highest nibble is different between ES and ES2/final. But ES2 have the same idcode as not ES.

@slagernate
Copy link
Contributor Author

slagernate commented Feb 9, 2023

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:

# Set up multipass instance called "x"
multipass launch focal --name x --memory 8G --disk 64G --cpus 8
multipass shell x
sudo apt update
sudo apt install python3-pip

# download utilites (for prjoxide)
sudo apt-get install build-essential clang bison flex libreadline-dev \
                 gawk tcl-dev libffi-dev git mercurial graphviz   \
                 xdot pkg-config python python3 libftdi-dev \
                 qt5-default python3-dev libboost-all-dev cmake libeigen3-dev


mkdir shared

# get yosys (https://github.com/YosysHQ/oss-cad-suite-build/releases)
# using alias (mp="multipass")
exit
mp transfer ~/Downloads/oss-cad-suite-linux-x64-20230208.tgz x:shared
mp shell x
cd shared
tar -xzvf oss-cad-suite-linux-x64-20230208.tgz
cd ~
echo 'export PATH="/home/ubuntu/shared/oss-cad-suite/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

# Download rust (for prjoxide)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# prjoxide (https://github.com/gatecat/prjoxide#building-the-prjoxide-tool)
git clone --recursive https://github.com/gatecat/prjoxide
cd prjoxide/libprjoxide/
cargo install --path prjoxide

# nextpnr (required by prjoxide)
git clone --recursive https://github.com/YosysHQ/nextpnr
cd nextpnr
cmake -DARCH=nexus -DOXIDE_INSTALL_PREFIX=$HOME/.cargo .
make -j8 # if you do not have enough memory, this will fail (2Gb failed)
# the above make command hung for me, but open restarting vm, appeared to work

# LiteX install
mkdir l
cd l
wget https://raw.githubusercontent.com/enjoy-digital/litex/master/litex_setup.py
chmod +x litex_setup.py
./litex_setup.py --init --install --user --config=full
echo 'export "PATH=$PATH:/home/ubuntu/.local/bin"' >> ~/.bashrc
source ~/.bashrc

# For RISC-V development
pip3 install meson
echo 'export "PATH=$PATH:/home/ubuntu/.local/bin"' >> ~/.bashrc
source ~/.bashrc
sudo ./litex_setup.py --gcc=riscv

# Test litex works via sim
pip3 install ninja
sudo apt install libevent-dev libjson-c-dev verilator
litex_sim --cpu-type=vexriscv

cd ~/l/litex-boards/litex_boards/targets
./lattice_crosslink_nx_evn.py --build --toolchain oxide

exit
mp transfer -r x:l/litex-boards/litex_boards/targets/build/lattice_crosslink_nx_evn/gateware/ .
# upload bitstream with favorite programmer (ecpprog, openFPGALoader, openOCD, etc.)
ecpprog -S gateware/lattice_crosslink_nx_evn.bit 

# Talk to litex via serial # you may have to plug / replug the USB cable
gtkterm -p /dev/ttyUSB1 -s 115200

@slagernate
Copy link
Contributor Author

slagernate commented Feb 9, 2023

although it seems the BIOS CRC is failing:


        __   _ __      _  __
       / /  (_) /____ | |/_/
      / /__/ / __/ -_)>  <
     /____/_/\__/\__/_/|_|
   Build your hardware, easily!

 (c) Copyright 2012-2022 Enjoy-Digital
 (c) Copyright 2007-2015 M-Labs

 BIOS built on Feb  8 2023 16:37:18
 BIOS CRC failed (expected 43588215, got 4250c025)
 The system will continue, but expect problems.

 LiteX git sha1: d256a5e3

--=============== SoC ==================--
CPU:		VexRiscv @ 75MHz
BUS:		WISHBONE 32-bit @ 4GiB
CSR:		32-bit data
ROM:		128.0KiB
SRAM:		128.0KiB


--============== Boot ==================--
Booting from serial...
Press Q or ESC to abort boot completely.
sL5DdSMmkekro
             Timeout
No boot medium found

--============= Console ================--

litex> mem_list
Available memory regions:
ROM   0x00000000 0x20000 
SRAM  0x10000000 0x20000 
CSR   0xf0000000 0x10000 

litex> 

@slagernate
Copy link
Contributor Author

slagernate commented Feb 9, 2023

switched from using register_mem() to add_slave() for the sram and now the bios crc passes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants