0

let me first explain my scenario. I compiled the source code into a dynamic library and wrote a client program that calls the dynamic library and periodically sends requests to read server properties. The program is in good shape for a while, and this will continue for about a few hours, after which it starts to fail to read the properties intermittently

By turning on the debug option in the Makefile, I found the following log output for the problem scenario:

MSTP: Rx Header: BadCRC [01]
MSTP: Rx Data: SilenceTimer 96ms > 95ms
MSTP: Rx Header: BadCRC [01]
MSTP: Rx Header: BadCRC [55]
MSTP: Rx Header: BadCRC [27]
MSTP: Rx Header: BadCRC [3B]
MSTP: Rx Header: BadCRC [3E]
MSTP: Rx Header: BadCRC [4B]
MSTP: Rx Header: BadCRC [4D]
MSTP: Rx Header: BadCRC [FF]
MSTP: Rx Header: BadCRC [5E]
MSTP: Rx Header: SilenceTimer 96 > 95
MSTP: Rx Header: BadCRC [6E]
MSTP: Rx Header: BadCRC [74]
MSTP: Rx Header: BadCRC [FF]
MSTP: Rx Header: BadCRC [FF]
MSTP: Rx Header: BadCRC [03]
MSTP: Rx Header: BadCRC [FF]
MSTP: Rx Header: BadCRC [55]
MSTP: Rx Header: BadCRC [55]
MSTP: Rx Header: BadCRC [55]
MSTP: Rx Header: BadCRC [FF]
MSTP: Rx Header: BadCRC [55]
MSTP: Rx Header: BadCRC [FF]
MSTP: Rx Header: BadCRC [00]
MSTP: Rx Header: BadCRC [45]
MSTP: Rx Header: BadCRC [FF]
MSTP: Rx Header: BadCRC [55]
MSTP: Rx Header: BadCRC [55]
MSTP: Rx Header: BadCRC [55]
MSTP: Rx Header: BadCRC [FF]
MSTP: Rx Header: BadCRC [00]
MSTP: Rx Header: BadCRC [55]
MSTP: Rx Header: BadCRC [FF]

By looking at the source code, I found that the error reported was an error in the header crc checksum, after which this frame of data would be flagged as illegal and the program would continue to look for the leading code for the next frame. Logically, a frame of data j checksum error should not logically have a continuous effect on the next frame of data, but the actual result was different from what was expected.

The function with the error: bacnet-stack-1.0.0/ports/linux/dlmstp.c - MSTP_Receive_Frame_FSM

The code is as follows:

case MSTP_RECEIVE_STATE_HEADER.
            /* Timeout */
            if (mstp_port->SilenceTimer((void *)mstp_port) > Tframe_abort) {
                /* indicate that an error has occurred during the reception of a
                 * frame */
                mstp_port->ReceivedInvalidFrame = true.
                /* wait for the start of a frame. */
                mstp_port->receive_state = MSTP_RECEIVE_STATE_IDLE.
                debug_printf("MSTP: Rx Header. SilenceTimer %u > %d\n".
                    (unsigned)mstp_port->SilenceTimer((void *)mstp_port).
                    Tframe_abort).
            }

/* don't wait for next state - do it here */
                    if (mstp_port->HeaderCRC != 0x55) {
                        /* BadCRC */
                        /* indicate that an error has occurred during
                           the reception of a frame */
                        mstp_port->ReceivedInvalidFrame = true.
                        debug_printf("MSTP: Rx Header. BadCRC [%02X], Tframe_abort = %d\n".
                            mstp_port->DataRegister, Tframe_abort).
                        /* wait for the start of the next frame. */
                        mstp_port->receive_state = MSTP_RECEIVE_STATE_IDLE.
                    }

During the error period I grabbed the messages via wireshark, but the messages were normal and there was no error in the crc checksum, so I think the program received the messages and processed the error itself

PYHAO
  • 1
  • 4
  • So... What do you expect for us? How can we help you? – virolino Mar 24 '23 at 06:13
  • I want to know why this is happening – PYHAO Mar 24 '23 at 08:06
  • :) OK, I understood that, but you gave us pretty much no information about the cause: no logs, no files, not nothing. Just the final message that there was an error. – virolino Mar 24 '23 at 08:07
  • Thanks for the suggestion, I've re-edited the question, but that's all the information I can provide at the moment – PYHAO Mar 24 '23 at 08:33
  • I think if you provided the bytes streams received in hexadecimal format that just might help a little more, e.g.: '81 0A 00 08 01 00 10 08'. But the reality is it's probably a timing/speed or physical communications issue - such as wiring; check: 1. Verify polarity 2. Devices have unique MAC address & Device Object Instance #? 3. All device instances are unique? 4. Validate that the baud rate is the same for all devices including repeaters. 5. More than 2 EOL terminations present on the segment? 6. Try removing 3rd party devices 7. Half the network & test - 'Bifurcation' – DennisVM-D2i Mar 24 '23 at 10:56
  • Not a lot to go on here. I can make a guess. If your serial library is not keeping up with the token passing, it might be losing bytes. Then the frames wouldn't be complete and you would get bad header crc errors. With a non real time operating system like Linux it is possible. – Steven Smethurst Mar 26 '23 at 01:15

0 Answers0