Dynamic baud rate on UART no longer works

[0xDRRB]

Since commit 1b5fc97, adding a UART with add_uart() while specifying with_dynamic_baudrate=True makes the device unable to send data (with or without touching the tuning word).

Everything works fine by switching the parameter to False and setting a fixed baud rate with baudrate=38400, for example. Dynamic baud rate and tuning word adjustment worked fine before this commit (I checked).

[helium729]

@0xDRRB I have reproduced the error and submitted a PR to fix.

[0xDRRB]

@helium729 This does not seem to fix my problem. Here is what I have in my BaseSoC class:

        # Add second UART
        self.add_uart(
                name="myuart",
                uart_name="serial",
                uart_pads=platform.request("serial", 1),
                baudrate=38400,
                fifo_depth=16,
                with_dynamic_baudrate=True)

And here is what I use in my C code:

    // setup second UART
    baudrate = 38400;
    nexttuningword = (baudrate * 4294967296) / config_clock_frequency_read();
    csr_write_simple(nexttuningword, CSR_MYUART_PHY_TUNING_WORD_ADDR);

    printf("\nGeneric UART init\n");
    if (genuart_init(&myuart0ctx, CSR_MYUART_BASE) < 0) {
        printf("UART init error!\n");
    } else {
        printf("\nGeneric UART write string\n");
        putstring(myuart0ctx, "Coucou le monde :)\n");
    }

If I simply change with_dynamic_baudrate to False and remove the call to csr_write_simple(), there is activity on myuart. And I can actually see the message at 38,400 bps.

If I go back to commit e5e6473 (just before 1b5fc97 “cores: uart: make phy part of uart module”), everything works perfectly with or without with_dynamic_baudrate=True.

[helium729]

What I find:

• RS232PHY with with_dynamic_baudrate=True fails to transmit data in simulation. The TX line remains idle.
• My debugging shows that RS232ClkPhaseAccum seems to generate a tick immediately upon entering the RUN state, which causes the state machine to misbehave (likely exiting RUN state prematurely or skipping bits).
• The tuning_word value in the CSR now appears correct after last fix.
• The issue seems related to how RS232ClkPhaseAccum initializes or updates the phase accumulator when tuning_word is a Signal (dynamic) versus an integer (static).

I will investigate further to find out the exact reason.

Let's reopen this issue @enjoy-digital and I will try to fix it in a couple days, and create a PR soon.