RS485 half duplex communication problem

[roymessinger]

I've asked a similar question before, and the result mjbcswitzerland has given me (and proved to be correct) was to replace the 2 resistors shown in the picture (R189=0, R188 not assembled):

My board is installed on a big machine with lots of other electronics/mechanics going on. I have 2 boards on the machine. Each board is getting 24V and using DC/DC transfers it to 3.3. On this 24V I have other 'users' also.

What I am experiencing is that in one of the boards, whenever a different user (on the same 24V main power line) is turned on, I'm getting an endless loop of tx enable, shown here:

I did not see any voltage spikes on the 3.3 of the K64 nor on the 24V when the other user is turned on. I'm using a USB to RS485 dongle which is not shielded (ready made product) - so I'm guessing an outside noise is coupled on this cable. When it happens, even the slightest touch on this cable and it starts to show this tx enables, sometimes when I touch it it suddenly stops.

This goes forever, and obviously, the connection with the K64 is dead, until I power on it. Without turning On/Off this user, there is no problem with the connection.

The green line is the tx enable. The yellow line is the Rs485 transmission (A+)

a. Even if it is a noise problem, how come the K64 sends endless TX enable pulses ? I would have thought just a one time scenario, not all the time.

b. Any idea how to solve it? Maybe something with the RS485 termination resistors?

Thanks.

[roymessinger]

Just an update..

I've tried to disable all the exception transmissions from the board (because I've seen in the data I'm getting error packets, so I've figured I will only send correct packet when asked to), and now I'm getting the correct answer - but endlessly. Does it mean the tx fifo is always full? why is it?

I think this is a good start - but need some ideas...

It happens only when the other 'user' has been using the 24V of the board. As if the K64 has something wrong from this point forward.

[xiangjun_rong]

Hi, Roymessinger,

Frankly speaking, I do not know the background of your issue. From software, it seems that your code has issue:

void send_message_in_uart(unsigned char *query, unsigned char string_length)
{
while ((kUART_TxDataRegEmptyFlag & UART_GetStatusFlags(UART_CH_ACTIVE)))
       UART_WriteBlocking(UART_CH_ACTIVE, query, string_length);

while (!(UART1->S1 & UART_S1_TC_MASK))
    __asm("NOP");
}

uint32_t UART_GetStatusFlags(UART_Type *base)
{
    uint32_t status_flag;

    status_flag = base->S1 | ((uint32_t)(base->S2) << 8);

#if defined(FSL_FEATURE_UART_HAS_EXTENDED_DATA_REGISTER_FLAGS) && FSL_FEATURE_UART_HAS_EXTENDED_DATA_REGISTER_FLAGS
    status_flag |= ((uint32_t)(base->ED) << 16);
#endif

#if defined(FSL_FEATURE_UART_HAS_FIFO) && FSL_FEATURE_UART_HAS_FIFO
    status_flag |= ((uint32_t)(base->SFIFO) << 24);
#endif

    return status_flag;
}

void UART_WriteBlocking(UART_Type *base, const uint8_t *data, size_t length)
{
    /* This API can only ensure that the data is written into the data buffer but can't
    ensure all data in the data buffer are sent into the transmit shift buffer. */
    while (length--)
    {
        while (!(base->S1 & UART_S1_TDRE_MASK))
        {
        }
        base->D = *(data++);
    }
}

The UART_WriteBlocking() function polls  the uart flag to transmit data, it is unnecessary to add the while ((kUART_TxDataRegEmptyFlag & UART_GetStatusFlags(UART_CH_ACTIVE))) line, how about delet it.

BTW, can you use different GPIO to the DE and /RE pin?

Hope it can help you

BR

Xiangjun Rong

[roymessinger]

Thanks for your reply.

It seems EMI noise caused this issue. When I've replaced the communication cables to shielded (and replaced the usb dongle with PCI to RS485 board) the problem seemed to disappear. I do not understand how EMI noise can cause such issue (only toggling the DE line) but it does.

Nevertheless, regarding the While line, from your experience, can it also cause such issues?

I will try to delete it anyway.

I cannot use different GPIO as it is custom board and only UART1 is used.

Roy