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

Add picorv32 support for Alhambra board #32

Closed
drtrigon opened this Issue Oct 22, 2018 · 76 comments

Comments

Projects
None yet
5 participants
@drtrigon
Copy link

drtrigon commented Oct 22, 2018

According to cliffordwolf/picorv32#92 picorv32 RISC soft core runs on Alhambra board. Is it possible to add support for this to FPGArduino?

@emard

This comment has been minimized.

Copy link
Member

emard commented Oct 22, 2018

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Oct 23, 2018

I try to help with whatever I can. The toolchain I used successfully is "RISC-V GNU toolchain and libraries for a pure RV32I target" as mentioned in https://github.com/cliffordwolf/picorv32#building-a-pure-rv32i-toolchain. It uses riscv32-unknown-elf-gcc, riscv32-unknown-elf-objcopy and from icestorm/icestudio toolchain iceprog (see https://github.com/FPGAwars/Alhambra-II-FPGA/blob/master/examples/picorv32/picosoc/Makefile).

@emard

This comment has been minimized.

Copy link
Member

emard commented Oct 23, 2018

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Oct 26, 2018

Can you try to use our f32c-rv32 compiled binary to get LED blinky on picorv32?

I tried, but not with much success... I used code from a working project and just tried to replace the toolchain with yours, see attached Makefile.txt (the commented parts are the ones from the working toolchain for reference).

Running it results in (the .elf file has a size of 0 bytes):

$ make prog
../../fpgarduino/f32c/bin/riscv-elf-gcc -std=gnu11 -DHX8KDEMO -march=RV32I -Wl,-Bstatic,-T,sections.lds,--strip-debug -ffreestanding -nostdlib -o firmware.elf start.s firmware.c
collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
$HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: /tmp/cc4XMh7D.o: ABI is incompatible with that of the selected emulation
$HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: failed to merge target specific data of file /tmp/cc4XMh7D.o
$HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: /tmp/cc39QdcM.o: ABI is incompatible with that of the selected emulation
$HOME/Downloads/icestudio/fpgarduino/f32c/bin/../lib/gcc/riscv-elf/4.9.2/../../../../riscv-elf/bin/ld: failed to merge target specific data of file /tmp/cc39QdcM.o
make: *** [firmware.elf] Fehler 1

So my questions:

  • Can you be more specific what I should test exactly (source files, commands for compiling, etc.)?
  • Would it be possible to integrate the picorv32 icestorm/icestudio toolchain as it is open source too (e.g. the programmer could be needed)?
@emard

This comment has been minimized.

Copy link
Member

emard commented Oct 26, 2018

@gornjas

This comment has been minimized.

Copy link
Contributor

gornjas commented Oct 26, 2018

Our current riscv toolchain is exactly the same as the mips version, i.e. is gcc-7.2 based and should be perfectly fine. The question is why the OP has fetched the long obsoleted 4.9.2 toolchain - could that be a bug in our Arduino json / packaging?

@emard

This comment has been minimized.

Copy link
Member

emard commented Oct 26, 2018

@gornjas

This comment has been minimized.

Copy link
Contributor

gornjas commented Oct 27, 2018

How did that regression happen? I thought we already switched over to 7.2 a year ago, and were using gcc-6 based toolchains prior to that. The bm/package_fpga_index.json is clearly referencing 7.2 based toolchains.

I'm inclined to wipe out all the pre-7.2 .zip archives from the web, otherwise we'll be getting into this again and again...

@emard

This comment has been minimized.

Copy link
Member

emard commented Oct 27, 2018

@gornjas

This comment has been minimized.

Copy link
Contributor

gornjas commented Oct 27, 2018

How's that possible? There's a single integrated toolchain archive for both mips + riscv toolchains per OS/architecture (win32, osx, lin32, lin64)? I.e. they are not downloaded separately, and there's no way to separate them in the json?

@gornjas

This comment has been minimized.

Copy link
Contributor

gornjas commented Oct 27, 2018

I removed the pre gcc-7.2 toolchains from the bm on our website as a precaution for this to reocur.

@emard

This comment has been minimized.

Copy link
Member

emard commented Oct 27, 2018

@emard

This comment has been minimized.

Copy link
Member

emard commented Oct 27, 2018

@emard

This comment has been minimized.

Copy link
Member

emard commented Oct 27, 2018

@drtrigon

This comment has been minimized.

@gornjas

This comment has been minimized.

Copy link
Contributor

gornjas commented Oct 27, 2018

The 7.2-based toolchain for 32-bit linux was built at the same time the 64-bit version was. We have 5 different toolchains based on gcc-7.2 since 2017 so there's no reason to use anything else:

login% ls -l tool
-r--r--r-- 1 marko fpgasvn 68284749 Nov 15 2017 f32c-fbsd64-toolchain-7_2.tar.gz
-r--r--r-- 1 marko fpgasvn 79048039 Nov 15 2017 f32c-lin32-toolchain-7_2.tar.gz
-r--r--r-- 1 marko fpgasvn 72986821 Nov 14 2017 f32c-lin64-toolchain-7_2.tar.gz
-rw-r--r-- 1 marko fpgasvn 82335149 Nov 24 2017 f32c-osx-toolchain-7_2.tgz
-r--r--r-- 1 marko fpgasvn 93959677 Nov 9 2017 f32c-win32-toolchain-7_2.zip

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Oct 27, 2018

Ok a lot of links on http://www.nxlab.fer.hr/fpgarduino/ are broken now but I figured the name of the new one to be www.nxlab.fer.hr/fpgarduino/bm/f32c-lin64-toolchain-7_2.tar.gz now, using that I got following result:

$ make prog
../../fpgarduino/f32c/bin/riscv32-elf-gcc -DHX8KDEMO -march=rv32imc -Wl,-Bstatic,-T,sections.lds,--strip-debug -ffreestanding -nostdlib -o firmware.elf start.s firmware.c
cc1: error: requested ABI requires -march to subsume the 'D' extension
make: *** [firmware.elf] Fehler 1

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Oct 27, 2018

It is no problem for integrate from licensing point of view but we lack of ing-hours to assemble all parts into stuff that works. I can package another riscv compiler and all required programming tools and libs, if you succeed with anything that leads to a blink led

As explained in cliffordwolf/picorv32#92 you can find a working example in https://github.com/FPGAwars/Alhambra-II-FPGA/tree/master/examples/picorv32/picosoc (see e.g. https://github.com/FPGAwars/Alhambra-II-FPGA/blob/master/examples/picorv32/picosoc/Makefile).
The toolchain used can be found in https://github.com/cliffordwolf/picorv32#building-a-pure-rv32i-toolchain (risc-v gcc) and https://github.com/FPGAwars/toolchain-icestorm/releases/ (iceprog).
Do you need more info? More specific details?
What I do not have are includes to make it compatible with Arduino source code.

@gornjas

This comment has been minimized.

Copy link
Contributor

gornjas commented Oct 27, 2018

$ make prog
../../fpgarduino/f32c/bin/riscv32-elf-gcc -DHX8KDEMO -march=rv32imc -Wl,-Bstatic,-T,sections.lds,--strip-debug -ffreestanding -nostdlib -o firmware.elf start.s firmware.c
cc1: error: requested ABI requires -march to subsume the 'D' extension
make: *** [firmware.elf] Fehler 1

Hi drtrigon,

pls. try adding -mabi=ilp32 to riscv32-elf-gcc invocation options.

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Oct 27, 2018

Works! The created .elf file differs by one byte from the one the original toolchain generated a few days before. Nice! Uploaded using iceprog.

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Oct 28, 2018

Do you need more info from my side?

@emard

This comment has been minimized.

Copy link
Member

emard commented Oct 28, 2018

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Oct 28, 2018

Oh, by the way the links on http://www.nxlab.fer.hr/fpgarduino/ are still broken, quite some confusion with "_", "-" and "." going on there, e.g.:

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Nov 9, 2018

Any news?

@emard

This comment has been minimized.

Copy link
Member

emard commented Nov 9, 2018

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Nov 9, 2018

Sorry to hear that but thanks a lot for your work! (I'm eager to test it on Alhambra... ;)

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Dec 4, 2018

What is the current status? Do you have an estimate by when I can start using it on the Alhambra?

@emard

This comment has been minimized.

Copy link
Member

emard commented Dec 4, 2018

@q3k

This comment has been minimized.

Copy link

q3k commented Jan 9, 2019

I will get you all I know about how to get f32c to synthesize&pr under verific+yosys+nextpnr for ice40 - I just haven't had time to get to it yet :(.

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 13, 2019

Thanks a lot @emard this is great news! Took the code from your repo and modified makefile and scripts/ulx3s_trellis.mk in order to point to my toolchain:

F32C-COMPILER-PATH=../toolchain-fpgarduino/f32c/bin

and

YOSYS ?= $(HOME)/.icestudio/apio/packages/toolchain-icestorm/bin/yosys

finally running make all yields this:

~/Downloads/icestudio/Alhambra_picorv32-picosoc/prjtrellis-picorv32-master$ make all
$HOME/.icestudio/apio/packages/toolchain-icestorm/bin/yosys \
        -p "hierarchy -top top" \
        -p "synth_ecp5 -noccu2 -json dvi.json" \
        top.v attosoc.v picorv32.v simpleuart.v 

 /----------------------------------------------------------------------------\
 |                                                                            |
 |  yosys -- Yosys Open SYnthesis Suite                                       |
 |                                                                            |
 |  Copyright (C) 2012 - 2016  Clifford Wolf <clifford@clifford.at>           |
 |                                                                            |
 |  Permission to use, copy, modify, and/or distribute this software for any  |
 |  purpose with or without fee is hereby granted, provided that the above    |
 |  copyright notice and this permission notice appear in all copies.         |
 |                                                                            |
 |  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES  |
 |  WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF          |
 |  MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR   |
 |  ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES    |
 |  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN     |
 |  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF   |
 |  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.            |
 |                                                                            |
 \----------------------------------------------------------------------------/

 Yosys 0.7 (Apio build) (git sha1 8c071a2, gcc 4.8.4-2ubuntu1~14.04.3 -fPIC -Os)


-- Parsing `top.v' using frontend `verilog' --

1. Executing Verilog-2005 frontend.
Parsing Verilog input from `top.v' to AST representation.
Generating RTLIL representation for module `\top'.
Successfully finished Verilog frontend.

-- Parsing `attosoc.v' using frontend `verilog' --

2. Executing Verilog-2005 frontend.
Parsing Verilog input from `attosoc.v' to AST representation.
Generating RTLIL representation for module `\attosoc'.
Generating RTLIL representation for module `\picosoc_regs'.
Successfully finished Verilog frontend.

-- Parsing `picorv32.v' using frontend `verilog' --

3. Executing Verilog-2005 frontend.
Parsing Verilog input from `picorv32.v' to AST representation.
Generating RTLIL representation for module `\picorv32'.
Generating RTLIL representation for module `\picorv32_regs'.
Generating RTLIL representation for module `\picorv32_pcpi_mul'.
Generating RTLIL representation for module `\picorv32_pcpi_fast_mul'.
Generating RTLIL representation for module `\picorv32_pcpi_div'.
Generating RTLIL representation for module `\picorv32_axi'.
Generating RTLIL representation for module `\picorv32_axi_adapter'.
Generating RTLIL representation for module `\picorv32_wb'.
Successfully finished Verilog frontend.

-- Parsing `simpleuart.v' using frontend `verilog' --

4. Executing Verilog-2005 frontend.
Parsing Verilog input from `simpleuart.v' to AST representation.
Generating RTLIL representation for module `\simpleuart'.
Successfully finished Verilog frontend.

-- Running command `hierarchy -top top' --

5. Executing HIERARCHY pass (managing design hierarchy).

5.1. Analyzing design hierarchy..
Top module:  \top
Used module:     \attosoc
Used module:         \simpleuart
Used module:         \picorv32

5.2. Executing AST frontend in derive mode using pre-parsed AST for module `\picorv32'.
Parameter \BARREL_SHIFTER = 0
Parameter \COMPRESSED_ISA = 0
Parameter \ENABLE_MUL = 1
Parameter \ENABLE_DIV = 0
Parameter \ENABLE_IRQ = 0
Parameter \ENABLE_IRQ_QREGS = 0
Parameter \PROGADDR_RESET = 0
Parameter \PROGADDR_IRQ = 0
Parameter \STACKADDR = 32768
Generating RTLIL representation for module `$paramod$01fe0ba9b03a5d6bd76e78007a69836c7928969b\picorv32'.

5.3. Analyzing design hierarchy..
Top module:  \top
Used module:     \attosoc
Used module:         \simpleuart
Used module:         $paramod$01fe0ba9b03a5d6bd76e78007a69836c7928969b\picorv32
Used module:             \picorv32_pcpi_mul

5.4. Analyzing design hierarchy..
Top module:  \top
Used module:     \attosoc
Used module:         \simpleuart
Used module:         $paramod$01fe0ba9b03a5d6bd76e78007a69836c7928969b\picorv32
Used module:             \picorv32_pcpi_mul
Removing unused module `\picorv32_wb'.
Removing unused module `\picorv32_axi_adapter'.
Removing unused module `\picorv32_axi'.
Removing unused module `\picorv32_pcpi_div'.
Removing unused module `\picorv32_pcpi_fast_mul'.
Removing unused module `\picorv32_regs'.
Removing unused module `\picorv32'.
Removing unused module `\picosoc_regs'.
Removed 8 unused modules.

-- Running command `synth_ecp5 -noccu2 -json dvi.json' --
ERROR: No such command: synth_ecp5 (type 'help' for a command overview)
make: *** [dvi.json] Fehler 1
~/Downloads/icestudio/Alhambra_picorv32-picosoc/prjtrellis-picorv32-master$ 

...so what is the proper substitute for synth_ecp5 ?

@q3k: Would be great to get you hints - looking forward to this...

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 13, 2019

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 14, 2019

@emard: ;) ...ok - thanks! Was not aware of such a obvious replacement. Added and did a fast/short test.

My current synth_ice40 (came with icestudio) seems to be old as it does not have the -json option. Is it possible to generate the bitstream etc. w/o using the json output? If not, I'll need some time to get a current toolchain... currently it ran until and finished step 6.28 - then make complains about finding no rule for creating empty_lfe5u-85f.config. This is strange because the rule $(BOARD)_$(FPGA_SIZE)f_$(PROJECT).config is still existing (I did not remove it).

@q3k: As the ice40 toolchain comming with icestudio contains arachne-pnr I'll go and use this until something forces me to change (errors/incompatibilities, size of final design, etc.). Do you remember why you used nextpnr? Was there a reason that forced you to use it? Or was it just by accident (because you had it installed already, you where familiar with it, etc.)?

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 14, 2019

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 14, 2019

@uXeBoy

This comment has been minimized.

Copy link

uXeBoy commented Jan 15, 2019

Have made a fork, and have it close to working with iCE40 on the 'myStorm BlackIce II':

https://github.com/uXeBoy/prjtrellis-picorv32

When I hit enter, instead of 'rv32>' I get five garbage characters back, so maybe just COM port settings / parity etc need adjusting on the PC side?

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 15, 2019

@uXeBoy

This comment has been minimized.

Copy link

uXeBoy commented Jan 15, 2019

Working now! Was definitely something to do with the built-in serial, but not sure what exactly? Switched to using one of these instead and it's all good:

https://raw.githubusercontent.com/uXeBoy/prjtrellis-picorv32/master/blink.gif

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 15, 2019

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 16, 2019

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 17, 2019

Thanks for all the hints so far! Now I had a bit more time to look into it. I started a new Makefile drtrigon/prjtrellis-picorv32@dd55eb3 and now I use blif instead of json backend, so the yosys step passes properly. However the arachne-pnr step throws: fatal error: failed to place: placed 32 RAMs of 68 / 32 so it does not fit into the available BRAM. From manpage http://manpages.org/arachne-pnr I do not see any parameters that allow optimization, so what to remove or disable? Other question is how to connect the clock signal properly, I see clk_25mhz but the Alhambra 2 has a 12 MHz clock signal, see drtrigon/prjtrellis-picorv32@f028af7.

I add here the output of the failing step:

arachne-pnr -d 8k -P tq144:4k -o top.asc -p demo.pcf top.blif
seed: 1
device: 8k
read_chipdb +/share/arachne-pnr/chipdb-8k.bin...
  supported packages: cb132, cb132:4k, cm121, cm121:4k, cm225, cm225:4k, cm81, cm81:4k, ct256, tq144:4k
read_blif top.blif...
prune...
read_pcf demo.pcf...
demo.pcf:21: warning: no port `clk' in top-level module `top', constraint ignored.
demo.pcf:24: warning: no port `flash_csb' in top-level module `top', constraint ignored.
demo.pcf:25: warning: no port `flash_miso' in top-level module `top', constraint ignored.
demo.pcf:26: warning: no port `flash_mosi' in top-level module `top', constraint ignored.
demo.pcf:27: warning: no port `flash_clk' in top-level module `top', constraint ignored.
instantiate_io...
pack...

After packing:
IOs          19 / 107
GBs          0 / 8
  GB_IOs     0 / 8
LCs          2852 / 7680
  DFF        647
  CARRY      433
  CARRY, DFF 126
  DFF PASS   224
  CARRY PASS 17
BRAMs        68 / 32
WARMBOOTs    0 / 1
PLLs         0 / 2

place_constraints...
promote_globals...
  promoted clk_25mhz$2, 909 / 909
  promoted $abc$27963$n5, 435 / 435
  promoted $abc$27963$n2173, 66 / 66
  promoted $abc$27963$n2227, 64 / 64
  promoted $abc$27963$n2163, 52 / 53
  promoted $abc$27963$n2161, 49 / 49
  promoted $abc$27963$n3, 31 / 31
  promoted $abc$27963$n1, 6 / 6
  promoted 8 nets
    3 sr/we
    4 cen/wclke
    1 clk
  8 globals
    3 sr/we
    4 cen/wclke
    1 clk
realize_constants...
  realized 1
place...
fatal error: failed to place: placed 32 RAMs of 68 / 32
@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 17, 2019

Btw.: I would also like to test it with https://github.com/f32c/f32c but when I looked into it I was a bit overwhelmed by the options and variants that are in there. Do I understand correct, it only exists in VHDL but not in Verilog? Thus I would first have to setup the yosys plugin (and by that next-pnr too according to http://www.clifford.at/icestorm/) or better the whole icestorm toolchain as icestudio contains a yosys w/o plugin support (and w/o json output).

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 17, 2019

@emard: OK, managed to make it synthesize by reducing memory usage in attosoc.vwith MEM_WORDS = 2048 see drtrigon/prjtrellis-picorv32@557f71a. Now it takes 20 of 32 BRAM blocks. However I have no idea whether that's ok? As soon as you can give me feedback about MEM_WORDS, the clock signal and the baudrate setting I'll upload and test it!

@uXeBoy

This comment has been minimized.

Copy link

uXeBoy commented Jan 17, 2019

@drtrigon - to use the 12MHz clock you will need to change reg_uart_clkdiv = 416/2 in firmware.c to reg_uart_clkdiv = 104 (12,000,000 / 115200 = 104.166666667)

@emard - the reason for my issue with serial has been found, reg_uart_clkdiv should be 217 to use with 25MHz, not 208 (416/2)

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 17, 2019

Ok, changed the setting as suggested (thanks for the hint @uXeBoy) and just connected clk with clk_25mhz, see drtrigon/prjtrellis-picorv32@41b7980. Uploaded it, but no blinking leds (yet)... have tried to set https://github.com/drtrigon/prjtrellis-picorv32/blob/master/firmware.c#L62 to 1 in order to enable it, but no change... suggestions? ideas?

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 17, 2019

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 17, 2019

@emard: Thanks for the hints. If I got the math right, I have for 1/4 of the memory size (8K) to set hex(2048*4-16) = 1FF0 instead of 7FF0 and hex(2048*4) = 0x002000 instead of 0x008000 as done in drtrigon/prjtrellis-picorv32@623c3a6 but still no reaction...

I don't understand your comment about rising the clock. At the moment I just connected the 12MHz to your clk_25mhz signal. Do I have to adopt dividers for that also?

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 18, 2019

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 18, 2019

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 18, 2019

@emard: Thanks again for your hints and efforts. Currently I am stuck as I must be doing something fundamentally wrong. I double checked the RX, TX connections, swapped them several times, there is no prompt appearing. What happens is when I swap RX/TX I get some leds on like 0b10101010. When I enable the stuff on line 62 https://github.com/drtrigon/prjtrellis-picorv32/blob/master/firmware.c#L62 I get a led pattern like 0b00001111. Adding LED = 0xFF; in firmware.c right before prompt label does not change anything. I never get serial output. Summary; something happens but I have no clue what currently...

Do I need to use an additional USB-SERIAL adapter? I want to use the one (ftdi chip) on the board that is used to upload fpga bitstreams etc.

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 18, 2019

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 18, 2019

@emard: Thanks a lot for the feedback - I did not find where in code these LED patterns are set - if you say that's a indication of running code, that's a very good sign. Thanks!

I have several icestudio projects using the same picorv32 and they work - that is where the idea for this feature request comes from. I can provide them also later e.g. as I have implemented GPIO (read and write) including tri-state port etc. - that's a nice topic for later.

Coming back to the current problem; by using LED = 0xFF; as "breakpoint" replacement I am trying to track down where my code hangs. What I found is that is does not pass beyond https://github.com/drtrigon/prjtrellis-picorv32/blob/master/firmware.c#L78 (does not leave the do while after the loop label). To me it looks like serial issue. The divider (104) is ok, I used the same in the other mentioned projects successfully. The thing is I double checked the TX/RX signals again and am 99% sure that they are wrong now - but if I swap them, no C code gets executed at all (LED = 0xFF; in very first line does nothing)... ideas?

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 18, 2019

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 18, 2019

@emard: Ok following improvement; I pulled your latest code and merged. Now I see a rv32> prompt after reset! What puzzles me is that the leds do not react to or show the value of the last byte sent.

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 18, 2019

@emard: Testting the helloworld.c now ... sending from FPGA to PC works but it seems the back path does not ... have to investigate that...

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 18, 2019

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 18, 2019

@drtrigon

This comment has been minimized.

Copy link
Author

drtrigon commented Jan 18, 2019

rv32> prompt is good, if LEDs don't follow typing I would suspect bad FPGA synthesys, upgrade your ICE40 tools.

Either this or something is wrong with my RISCV32-GCC toolchain. Could you may be point me to the proper one?

In any case I can honestly say that I currently have no clue what's going on... I tested with this file https://github.com/drtrigon/prjtrellis-picorv32/blob/master/helloworld.c. What works are line 45+46 and if everything else is commented as in the current version also line 53. But that's all... e.g. the while loop does not work - the leds blink once and then stay off. I changed the delay loop and once the output text was printed a few times (so it looped) but then stopped also. So to summarize; something works but there are various strange artifacts.

Also when you have rv32> prompt, you can immediately try sending a binary from FPGArduino. Follow my README.md and upload the blink

I would love to go forward and try this, but currently I don't think it makes sense... wrong? (currently it does not react on S or ENTER)

@emard

This comment has been minimized.

Copy link
Member

emard commented Jan 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment