Hi SamLee1805,
please see below an answer from the application engineer I have just received.
DESCRIPTION
An application expert, at the time involved in the design of the SJA1000, came with the following extensive reply:
The so-called “Overload Frame” feature of CAN is from the very first days of CAN in the 1990th and was required for the very first CAN implementations just having a simple Receiver Buffer, which was needed to be read by the host on very short notice before the next frame comes in. At that time, Bosch invented the Overload Frame feature to allow a node pushing-out the next frame on the bus without any penalty of Error Counting in other nodes in the system. Actually, this feature was needed at that time due to the super slow first devices with very poor receive buffer construction.
This Overload Frame feature was never really wanted by any customer and as such, newer devices implemented more powerful receive buffer constructions with according Acceptance Filtering. These devices do not send any Overload Frame, even if the buffer internally would overflow. With other words: The SJA1000 does not actively send any Overload Frame, even if the buffer is full. In case of an overflow in the FIFO, the application loses frames. Nevertheless, every CAN compliant implementation has to tolerate overload frames from other nodes and has to behave accordingly and extend the time between frames. To my knowledge, there are no products in the market, which intentionally drive overload frames since no OEM would like to have such things in a system. Overload Frames would make the CAN bus less predictable with respect to available band width. So, nobody would send such frames today.
With Best Regards,
Jozef
