Repeated bytes being sent through UART

Hi,

I am facing a wierd problem when using the UART.

Each 500ms I send the following packet in the UART:

['C',0x01, 0x04, 't', 'e', 's', 't']

 

Randomly, it sends two times the first caracter:

['C','C',0x01, 0x04, 't', 'e', 's', 't']

 

What may be causing this?

  • What version of the SSP are you using?
  • In reply to O. R.:

    I am using SSP 1.3.0 on a S3A3.
  • In reply to Mad River:

    Hi Mad River,

    Any transfer drivers used?

    Regards,
    adboc
  • In reply to adboc:

    No, I am not using transfer drivers.

    I am having problems with the Synergy UART driver for while.

    I was also having a problem where the driver stopped working after sometime.

    I made another post about it (https://renesasrulz.com/synergy/f/synergy---forum/9464/uart-stops-working-after-a-few-minutes), and since I started using the LOCK function the driver didn't stopped anymore.

    But now the problem is the repetition of the first byte occasionally.

    Probably all these problem are related.

  • In reply to Mad River:

    Hi Mad River,

    I have tried to reproduce the issue on DK-S3A7 board (currently no access to S3A3) by creating a connection between SCI2 and SCI3. Everything is working as expected, no extra characters transmitted. How do you transmit/receive the data?

    Regards,
    adboc
  • In reply to adboc:

    Hi,

    To make it clear, the error doesn't occurs in every transmission, it occurs randomly.

    I am sending and receiving using these functions:

     

    void uart_send(const sf_comms_instance_t * uart, u8 * data, u16 size)
    {
        ssp_err_t ssp_err;

        ssp_err = uart_radio.p_api->lock(uart_radio.p_ctrl, SF_COMMS_LOCK_TX, TX_WAIT_FOREVER);

        ssp_err = uart_radio.p_api->write(uart_radio.p_ctrl, data, size, TX_WAIT_FOREVER);

        ssp_err = uart_radio.p_api->unlock(uart_radio.p_ctrl, SF_COMMS_LOCK_TX);
    }

     

    void uart3_rx_thread_entry(void)
    {
        u8 a_byte = 0;

        /* TODO: add your own code here */
        while (1)
        {
            uart_radio.p_api->read(uart_radio.p_ctrl, &a_byte, 1, TX_WAIT_FOREVER);
            serial_rx_callback(a_byte); // State machine that consumes each byte
        }
    }

  • In reply to Mad River:

    Hi Mad River,

    Please add the lock/unlock calls before/after the read API (using SF_COMMS_LOCK_RX option).

    Regards,
    adboc
  • In reply to adboc:

    Hi,

     

    As you suggested:

    void uart3_rx_thread_entry(void)
    {
        u8 a_byte = 0;

        /* TODO: add your own code here */
        while (1)
        {
            uart_radio.p_api->lock(uart_radio.p_ctrl, SF_COMMS_LOCK_RX, TX_WAIT_FOREVER);
            uart_radio.p_api->read(uart_radio.p_ctrl, &a_byte, 1, TX_WAIT_FOREVER);
            uart_radio.p_api->unlock(uart_radio.p_ctrl, SF_COMMS_LOCK_RX);

            radio_serial_rx_callback(a_byte);
        }
    }

     

    It didn't make any difference. The S3A3 keeps sending two times the first byte after a few transmissions.

  • In reply to Mad River:

    I made a workaround to prevent the receiver from miss the whole packet when the STARTER BYTE ('C') is repeated.

    I inserted a 0x00 before the packet. That way, when two 0s are sent due to the bug, the receiver simply ignores them and start decoding when receives the 'C'.

    To my surprise, a few packets are still being ignored.

    I inserted a breakpoint and discovered that it is repeating bytes IN THE MIDDLE of the packet as well:

  • In reply to Mad River:

    Hi Mad River,

    It looks like you're trying to receive on a byte-by-byte basis.

    Using a Framework for this isn't really suitable (unfortunately). Frameworks are better used for transferring large chunks of data.

    I would recommend going straight to the HAL driver and using the user callback to update your buffers when a byte is received. The callback will trigger when a single byte is received (given that the UART channel has been opened) even if you don't have requested a receive.
  • In reply to O. R.:

    Hi O.R.,

    I am receiving just fine.
    The repeated bytes are appearing in the data that is being sent from the S3A3.
    The problems occurs even when I am not running the uart rx thread, so I don't think the byte-by-byte reception is the problem here.
  • In reply to Mad River:

    Hi Mad River,

    I have read your other post. The fact that you were having the error SSP_ERR_IN_USE seems to indicate that you were having two different thread trying to access your low-level uart driver at the same time. Is your function uart_send() being called by a single thread or it can be called from several threads? Did you try before adding your lock() to place breakpoints on the few locations where SSP_ERR_IN_USE is returned? I would bet that your repeated character actually happens when you had the error SSP_ERR_IN_USE previously, so placing breakpoints may give you some hints.

    Franck
  • In reply to Franck:

    Hi Franck,

    Thank you for your reply.

     

    Franck
    Hi Mad River,

    seems to indicate that you were having two different thread trying to access your low-level uart driver at the same time

     

    It may be happening, but isn't the LOCK function supposed to prevent any problem to happen?

  • In reply to Mad River:

    Hi Mad River,

    From your original post, you said that you configured the S3A3 to send a 20 byte packet each 250ms. I was not expecting that you had other threads sending other data in between.

    So yes your lock should keep your 20 packet bytes united as long as you keep your lock active during the whole transfer. Just make sure that you send all your 20 bytes with a single call to uart_send(), otherwise you may have other threads inserting bytes in the middle of your transfer.

    Franck
  • In reply to Franck:

    Hi,

    Well, I am LOCKING, transfering (blocking mode = TX_WAIT_FOREVER) and UNLOCKING. It is not preventing the repeated bytes from happering.