Closed jschoch closed 8 months ago
this seems to have been a fluke... I get all sorts of errors when I moved the 9k out to the garage.
when i run wireshark it shows that there is an ARP and then immediately following the response the data segment of the following udp packet is duplicated and the length is doubled. not sure how this impacts the test-gui but it would be good to know if the socket timeout on the python side coincides with this problem. It is also odd that there are ICMP packets in there randomly. there is some setting for ICMP blocking or no-blocking that maybe is to blame.
I don't know enough verilog (or in general) to understand the gateware or how it deals with the flags Sn_IMR / Sn_IR but maybe it is ignoring the SEND_OK flag or something?
i have to check this, but please can you try to build the gateware with the gowin toolchain, i think nextpnr/ypsys have some issues
I attempted to get the code up and running in the gowin IDE last night. I had it running in GAO but I couldn't get it to do anything other than waffle between state 1 (idle) and 2 (sending command).
Can you clarify how it works? It seems that it waits for a packet, then immediately responds with a status update. There doesn't appear to be any initialization or setup of a "connection", it just seems to respond.
I don't quite understand your question, if the IDE is in the PATH, you can move the gateway directory start the compile with :
#riocore/Output/Tangoboard/Gateware# make clean gowin_build
and flash with:
#riocore/Output/Tangoboard/Gateware# make gowin_load
rm -rf rio.fs rio.json rio_pnr.json rio.tcl abc.history impl yosys.log
gw_sh rio.tcl
*** GOWIN Tcl Command Line Console ***
current device: GW1NR-9C GW1NR-LV9QN88PC6/I5
add new file: "pwmout.v"
add new file: "stepdir.v"
add new file: "modbus.v"
add new file: "uart_baud.v"
add new file: "uart_rx.v"
add new file: "uart_tx.v"
add new file: "w5500.v"
add new file: "debouncer.v"
add new file: "toggle.v"
add new file: "rio.v"
add new file: "pins.cst"
GowinSynthesis start
Running parser ...
Analyzing Verilog file '/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/pwmout.v'
Analyzing Verilog file '/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/stepdir.v'
Analyzing Verilog file '/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/modbus.v'
Analyzing Verilog file '/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/uart_baud.v'
Analyzing Verilog file '/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/uart_rx.v'
Analyzing Verilog file '/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/uart_tx.v'
Analyzing Verilog file '/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/w5500.v'
Analyzing Verilog file '/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/debouncer.v'
Analyzing Verilog file '/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/toggle.v'
Analyzing Verilog file '/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/rio.v'
Compiling module 'rio'("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/rio.v":49)
WARN (EX3780) : Using initial value of 'ESTOP' since it is never assigned("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/rio.v":88)
Compiling module 'pwmout(DIVIDER=2700)'("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/pwmout.v":2)
Compiling module 'pwmout(DIVIDER=18000)'("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/pwmout.v":2)
Compiling module 'stepdir'("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/stepdir.v":2)
WARN (EX3791) : Expression size 9 truncated to fit in target size 8("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/rio.v":370)
Compiling module 'modbus(RX_BUFFERSIZE=128,TX_BUFFERSIZE=128,ClkFrequency=27000000)'("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/modbus.v":2)
Compiling module 'uart_rx(ClkFrequency=27000000,Baud=9600)'("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/uart_rx.v":4)
Compiling module 'uart_baud(ClkFrequency=27000000,Baud=9600,Oversampling=8)'("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/uart_baud.v":4)
WARN (EX3791) : Expression size 9 truncated to fit in target size 8("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/modbus.v":53)
WARN (EX3791) : Expression size 9 truncated to fit in target size 8("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/modbus.v":60)
Compiling module 'uart_tx(ClkFrequency=27000000,Baud=9600)'("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/uart_tx.v":4)
Compiling module 'uart_baud(ClkFrequency=27000000,Baud=9600)'("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/uart_baud.v":4)
WARN (EX3791) : Expression size 9 truncated to fit in target size 8("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/modbus.v":86)
WARN (EX3791) : Expression size 9 truncated to fit in target size 8("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/modbus.v":95)
WARN (EX3791) : Expression size 32 truncated to fit in target size 8("/data2/src/ICE40-2023/serial-tx/riocore/Output/Tangoboard/Gateware/modbus.v":99)
...
I'm just wondering how the w5500.v works, that is what my question above was about.
but you got me thinking about the build env and my first attempts were built in WSL, and flashed with the gowin programmer.
In my x64 debian bookworm machine (the one I have been testing with) just took a look at the version of yosys and it is 0.23. going to see how updating that changes things.
using the gowin_build the stability is night and day better. Wireshark shows none of the double data length packets with the repeated data segment (34 len, with the 17 repeated twice in the data section of the UDP packet). I haven't tried the new yosys build yet, it took like 3 hours to build.
I'd love to try to figure out what the issue is but I need a better understanding of how the module works and how to tests it.
initialization:
end else if (state == STATE_INITIALIZING) begin
..
check if socket is open:
end else if (state == STATE_INITIALIZING && waiting_for_socket == 1'b1) begin
...
wait for new package:
end else if (state == STATE_IDLE) begin
if (rx_timer == 4'd10) begin
// check for new data
if (is_check_rx == 1) begin
// check poll result (data len > 0)
if (data_read[7:0] > 8'b0) begin
state <= STATE_RX_START;
end
end else begin
// poll command (have you rx data ?)
end
check size of received data:
end else if (state == STATE_RX_START) begin
rx_buffer_read_pointer <= rx_buffer_read_pointer + data_read[7:0];
if (rx_size == (BUFFER_SIZE_RX+HEADER_SIZE)) begin
rx_buffer_valid <= 1;
...
if ok, reading receive buffer:
end else if (state == STATE_PULLING_DATA && spi_clock_count > (rx_size+24-1)) begin
...
check if header is ok:
if (rx_buffer[BUFFER_SIZE_RX-1:BUFFER_SIZE_RX-32] == MSGID) begin
get destination ip and port from the reive header:
dst_ip <= rx_buffer[BUFFER_SIZE_RX+HEADER_SIZE-HEADER_IP_OFFSET-1:BUFFER_SIZE_RX+HEADER_SIZE-HEADER_IP_OFFSET-32];
dst_port <= rx_buffer[BUFFER_SIZE_RX+HEADER_SIZE-HEADER_PORT_OFFSET-1:BUFFER_SIZE_RX+HEADER_SIZE-HEADER_PORT_OFFSET-16];
back in the main module: check the data_output_valid flag (means data is received / wiznet5500 module data output is valid)
always @(posedge mclk) begin
sync <= 0;
if (data_output_valid == 1) begin
do_transmit <= 1;
timeout_counter <= 0;
pkg_timeout <= 0;
sync <= 1;
...
do_transmit <= 1 starts the trasmission
...
closing this, yosys doesn't work with the UDP code, you must use the gowin tools to get it to work without lots of packet errors, double packets etc.
here's my compile log output, hoping there is something in here regarding timing that makes for more stable w5500. What ever it did it seems much much more stable than previous builds