Modbus serial communication error in UART3 but not UART1 on IMXRT1060 EVK

[creatorwonny]

Hi

I tried to implement modbus RTU master and there was an issue that slave received one packet divided into multiple packets when there are many data to write to slave. For example, if a write multiple holding register packet(FC:03, Addr:0, Num:100) is sent to slave then following data will be received to slave and the slave sends the response in normal case.

Rx:002192-01 10 00 00 00 64 C8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D4 93
Tx:002193-01 10 00 00 00 64 C1 E2

However, there was cases that slave received multiple packets which were divided from one packet as following. Because the slave received abnormal packet, it didn't send response to the master.

Rx:002256-01 10 00 00 00
Rx:002257-64 C8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Rx:002258-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D4 93

What's strange is that this issue was not occurred in UART1 with all baud rates. Unlike the UART1, UART 3 had this issue but it didn't have this issue with 115200bps baud rate setting. Given this symptom, I think clock setting is not correct. Please give me some advice on this issue.

In order to see only this issue, I used an example project of ipuart_interrupt_rb_transfer from SDK and modified it to send a packet of write multiple registers.

[Information]

BOARD: iMXRT1060 EVK

SDK: 2.9.3

TOOL: Modbus Slave from www.modbustools.com

[pateln948]

Can You share your port.c file ? 

[creatorwonny · Accepted solution]

This issue has been solved by setting the parity bit from none to even or odd. However, I still don't understand it. I tested it with PC or some devices  in a place where noise is very low so I believe none parity should work. Is there someone who can explain it?

[Omar_Anguiano]

Hello

Hope you are well. The UART instances are configured in the same way since they have the same registers to be configured. The LPUART1 is used to communicate to the console of the PC while the other instances can be connected through a pin of the device.
To verify that the baud rate is correctly set I suggest you use a logic analyzer to see the signal and have a more detailed description of what is happening. 

There is a tolerance of 3% for the baudrate value that is checked in the LPUART_Init() function. If the calculated baudrate is outside the 3% tolerance with the desired baudrate then the function returns the status "kStatus_LPUART_BaudrateNotSupport".

If you have more questions do not hesitate to ask me.
Best regards,
Omar

[creatorwonny]

Hello,

I already checked the codes and confirmed that it didn't return kStatus_LPUART_BaudrateNotSupport.

I assume it's not just a clock or baud rate problems. It seems the problem is related to circuit of the EVK board or something else.

The reason why I think like that first, modbus communication worked well even on UART3 if the transmission data wasn’t much (< 30 - 40bytes) regardless of any baud rates. The problem of receiving one packet to several packets only occurs when transmitted many data and it didn’t occur all the time only occasionally. I guess there is a case that sometime there is a delay than 3.5 characters of the baud rate in transmitting. According to modbus specification, it perceives the transmission end when there is a delay more than 3.5 character time between characters. A strange thing is that there is no issue or intermittently issue on UART3 with baud rate 9600, 19200 and 115200 but it occurs often with 38400 and 57600.

Second, it worked very well on UART1 regardless of any baud rates or any size of transmit data. According to what you said that ‘the configuration should be same way’ then it is more likely issue related to hardware because it’s different between UART1 and UART3. Do you have any idea why the result is different between of the two ports?

The test codes are very simple like below and I checked whether slave sending response or not by using serial monitoring program. The project files is attached in this post.

#define DEMO_LPUART          LPUART3
#define DEMO_LPUART_CLK_FREQ BOARD_DebugConsoleSrcFreq()

const uint8_t g_txPacketData[] = { /* MODBUS FC:03, ADDRESS:0, COUNT: 100 */
       0x01, 0x10, 0x00, 0x00, 0x00, 0x64, 0xC8, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
       0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xD4, 0x93
};

/*!
 * @brief Main function
 */
int main(void)
{
    uint8_t ch;
    lpuart_config_t config;

    BOARD_ConfigMPU();
    BOARD_InitBootPins();
    BOARD_InitBootClocks();

    /*
     * config.baudRate_Bps = 115200U;
     * config.parityMode = kLPUART_ParityDisabled;
     * config.stopBitCount = kLPUART_OneStopBit;
     * config.txFifoWatermark = 0;
     * config.rxFifoWatermark = 0;
     * config.enableTx = false;
     * config.enableRx = false;
     */

    LPUART_GetDefaultConfig(&config);
    config.baudRate_Bps = 38400UL;
    config.enableTx     = true;
    config.enableRx     = true;

    LPUART_Init(DEMO_LPUART, &config, DEMO_LPUART_CLK_FREQ);

    while (1)
    {
       LPUART_WriteBlocking(DEMO_LPUART, g_txPacketData, sizeof(g_txPacketData));
       SDK_DelayAtLeastUs(1000000U, SDK_DEVICE_MAXIMUM_CPU_CLOCK_FREQUENCY);
    }
}

By the way, I tested it by changing the UART clock selector and the clock divider. For baud 38400 on UART3, clock divider of 7 based on both PLL3 and OSC 24MHz worked well without the issue above but other baud rates except 9600 and 19200 had issue in communication to slave.

I will definitely check if there is a delay between data in transmitting, let you know.

Any ideas and advice would help me a lot.

Thanks

[Omar_Anguiano]

It will be helpful to check the frame with the oscilloscope to check if there is a delay between the data.  There might be an issue with the follower so it is important to check with the analyzer if the data output from the leader is coherent with the received by the follower. Another helpful test is to use a different pin in LPUART3 to see if this issue persists.

If you have more questions do not hesitate to ask me.
Best regards,
Omar

[creatorwonny]

Hi 

I checked the frame with oscilloscope and there seemed no delay between data. 

[ NORMAL ]

RX:000910-01 10 00 00 00 1E 3C 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 10 01 11 01 12 01 13 01 14 01 15 01 16 01 17 01 18 01 19 01 20 01 21 01 22 01 23 01 24 01 25 01 26 01 27 01 28 01 29 01 30 9E 2B 

TX:000911-01 0 00 00 00 1E 40 01

[ ERROR ]

RX:000912-01 10 00

RX:000913-00 00 1E 3C 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 10 01 11 01 12 01 13 01 14 01 15 01 16 01 17 01 18 01 19 01 20 01 21 01 22 01 23 01 24 01 25 01 26 01 27 01 28 01 29 01 30 9E 2B 

The above is the log data that the modbus slave received and there was a case that modbus slave recognized one packet as two packets and I captured the signal of GPIO_AD_B_07 pin when it happened. The time for each character was about 235us and no problematic delays were observed.

I tested and captured on UART1 and there wasn't problematic delay either. But there was difference in communication. As I mentioned, communication with the pins of UART_TXD_ISP after NTS0102 worked well. However communication with the pins of UART1_RX_TGTMCU before NTS0102 (remved jumper on J46) had the same issue like UART3. Should we use a chip like NTS0102 in order to communication with PC using USB-TO-SERIAL cable? 

[creatorwonny]

Hi,

Here are some more information about this issue. 

I captured the two points of the signals in UART1 and it communicated with PC through a USB cable which is connected to J41 on iMXRT1060 EVK. In this case, the communication is working well without any issues.

Rx:000060-09:59:54.612-01 10 00 00 00 1E 3C 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 10 01 11 01 12 01 13 01 14 01 15 01 16 01 17 01 18 01 19 01 20 01 21 01 22 01 23 01 24 01 25 01 26 01 27 01 28 01 29 01 30 9E 2B

Tx:000061-09:59:54.612-01 90 02 CD C1

[ evk_uart1_rs232_normal_002.jpg ]

[ evk_uart1_rs232_normal_003.jpg ]

However, if I use UART1 with J46 jumper opened then it has the same issue.

Rx:000078-10:04:36.168-01 10 00 00 00 1E 3C

Rx:000079-10:04:36.201-01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 10 01 11 01 12 01 13 01 14 01 15 01 16 01 17 01 18 01 19 01 20 01 21 01 22 01 23 01 24 01 25 01 26 01 27 01 28 01 29 01 30 9E 2B

[ evk_uart1_rs232_error_010.jpg ]

[ evk_uart1_rs232_error_011.jpg ]

In addition, UART3 also has the same issue.

Rx:000243-10:45:53.893-01 10

Rx:000244-10:45:53.926-00 00 00 1E 3C 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 10 01 11 01 12 01 13 01 14 01 15 01 16 01 17 01 18 01 19 01 20 01 21 01 22 01 23 01 24 01 25 01 26 01 27 01 28 01 29 01 30 9E 2B

[ evk_uart3_rs232_error_003.jpg ]

[ evk_uart3_rs232_error_004.jpg ]

For more information, I attached all files that captured the signals. I hope I can get any idea  about this issue.

Thanks

[creatorwonny]

Does anyone have any idea about this issue? how can I check the baudrate is set correctly?

[carstengroen]

By measuring it ?

[creatorwonny]

Hi carstengroen,

Yes, you are right. But I didn't just ask for baudrate alone, something related to setting of buadrate or clock, etc... Because it worked well if less than 40 bytes was sent to slave by modbus protocol.

In addition, it worked well without any issues on UART1 of the EVK regardless of any baudrates setting using the same program (only changed the UART port in codes) . But it didn't work on the other UART ports. According to this result, UART setting needs to be different for other port except UART1 on the iMXRT1060 EVK but I don't know about it so ask advice.