USB port instability


#1

Strange things happen here!

Starting from tiny_usb_examples-master found in the web, the “hello_world” example uses the USB port
seen by the PC as a virtual COM port.
It is possible to transmit and receive characters using the instantiated usb_uart module.

So I’ve implemented a receive engine that waits for a incoming character from usb_uart module and
saves it into a circular buffer.
Also a transmit engine that receives characters to send into another circular buffer and sends it one at time
to the usb_uart module.

They work, it is easy to implement a loopback connection so I can see all typed keys back on the
screen using a terminal emulator like Putty.

During this circuit development I’m faced sometimes in a problem: at boot after firmware download
the (user circuit) COM port was not anymore correctly registered by the PC.
Could be my circuit that begins to send characters on USB just after the boot?
So my first attempts were: to increase the resetn initial signal duration incrementing its counter width,
implementing a cold_start flag using the already defined delay_count[26:0], and so on.
I don’t know why but at the end the above problem is always disappeared.

But now I’m at the boundary.
I’m implementing a FSM to decode tha commands from host.
Provided the definitions:

parameter Nloc_buff=16;
parameter Nbits_buff_pnt=4;
//
reg [7:0] buffer_rx[0:Nloc_buff-1];
reg [7:0] buffer_tx[0:Nloc_buff-1];
reg [Nbits_buff_pnt-1:0] buffer_rx_rd_pnt=0, buffer_rx_wr_pnt=0, buffer_tx_rd_pnt=0, buffer_tx_wr_pnt=0;

wire there_are_rx_char = (buffer_rx_wr_pnt!=buffer_rx_rd_pnt);
reg [7:0] received_char;

look at the problem:

with this code the COM port is correctly registered

always @(posedge clk_48MHz) begin
if(cold_start && there_are_rx_char) begin // one char received
// received_char <= buffer_rx[buffer_rx_rd_pnt];
// buffer_rx_rd_pnt = buffer_rx_rd_pnt + 1’b1;
end
else received_char <= 8’d0; // no char received
end

uncommenting one line the COM port doesn’t register anymore:

always @(posedge clk_48MHz) begin
if(cold_start && there_are_rx_char) begin // one char received
received_char <= buffer_rx[buffer_rx_rd_pnt];
// buffer_rx_rd_pnt = buffer_rx_rd_pnt + 1’b1;
end
else received_char <= 8’d0; // no char received
end

BUT I’M NOT ALONE!
In top.v, arduino folder of tiny_usb_examples-master, I can see

always @(posedge clk_24mhz) begin
reset_cnt <= reset_cnt + !resetn;
uart_ready1 <= uart_ready;
uart_ready2 <= uart_ready1; // Not used, but breaks when I remove it
end

Any idea?


#2

Someone knows who is the yosys/arachne developers interested to have my project
as test case to fix the problem?


#3

In a desperate attempt I compiled the “Hello World” project under iceCube2.
I’ve fixed (–> no more WARNING) several problems detected here and there.

Now the remaining warning are listed below, anyway after the firmware download
the COM port is not properly recognized by Windows.

Hopeless attempt.

WARNING - synthesis: …/top.v(69): ram text_original_ramnet has no write-port on it. VDB-1038
WARNING - synthesis: Initial value found on net in_ep_data[7] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_data[6] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_data[5] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_data[4] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_data[3] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_data[2] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_data[1] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_data[0] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net setup_stage_end will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net status_stage_end will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net send_zero_length_data_pkt will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_data_free[2] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_data_free[1] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_data_free[0] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_acked[2] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_acked[1] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_acked[0] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net tx_pkt_start will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net tx_pid[3] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net tx_pid[2] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net tx_pid[1] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net tx_pid[0] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_xfr_end will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_num[1] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net in_ep_num[0] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net ep_put_addr_2__5__N_576 will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net ep_put_addr_1__5__N_577 will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net ep_put_addr_0__5__N_578 will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net out_ep_acked[1] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net out_ep_acked[0] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net tx_pkt_start will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net tx_pid[3] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net tx_pid[2] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net tx_pid[1] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net tx_pid[0] will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net out_xfr_start will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net new_pkt_end will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net rollback_data will be ignored due to unrecognized driver type
WARNING - synthesis: Initial value found on net out_ep_num[0] will be ignored due to unrecognized driver type


#4

No way, also with HighEffort iceCube2 gives a maximum frequency that is is far away the required 48 MHz:

4.1::Critical Path Report for clk_48mhz


Clock: clk_48mhz
Frequency: 23.94 MHz | Target: 48.01 MHz