NXP SJA1000 will issue overload frame? when RX FIFO is full.

[SamLee1805]

According to the CAN 2.0 B specs,there are two kinds of OVERLOAD conditions, which both lead to the transmission of an OVERLOAD FLAG: 1. The internal conditions of a receiver, which requires a delay of the next DATA FRAME or REMOTE FRAME. 2. Detection of a ’dominant’ bit at the first and second bit of INTERMISSION. About the item 1 condition, will NXP SJA 1000 implement item 1 condition? If yes, cloud you describe more detail.

[JozefKozon]

Hi SamLee1805,

for consequences of the overload conditions please see below.

With Best Regards,

Jozef

[SamLee1805]

Hi, Sir,

    Excuse me, I know the overrun condition, but I want to ask a condition:

       Before the overrun condition was happened or else RX abnormal condition, will the overload frame be issued on the CAN bus by this controller?

[JozefKozon]

Hi SamLee1805,

I have contacted an application engineer with the question and he just sent me an answer. Please see below and a application note attached.

DESCRIPTION

Pls check Table 6 of SJA1000 App hint.

https://www.nxp.com.cn/docs/en/application-note/AN97076.pdf

With Best Regards,

Jozef

[SamLee1805]

I can't find the answer about this question,could you tell me which item of the table 6 to meet my question?

[JozefKozon]

Hi SamLee1805,

I apologize for not having an answer yet. So far I haven't received a reply from the application engineer. Today I have added more engineers in the loop. Hopefully they will answer me soon. 

Thank you for your patience.

With Best Regards,

Jozef

[JozefKozon · Accepted solution]

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