From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Hartkopp Subject: M_CAN message RAM initialization AppNote - was: Re: [PATCH V3 3/3] can: m_can: workaround for transmit data less than 4 bytes Date: Wed, 05 Nov 2014 19:15:10 +0100 Message-ID: <545A692E.40002@hartkopp.net> References: <1415193393-30023-1-git-send-email-b29396@freescale.com> <1415193393-30023-3-git-send-email-b29396@freescale.com> <545A3451.2090302@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.160]:13847 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750860AbaKESPW (ORCPT ); Wed, 5 Nov 2014 13:15:22 -0500 In-Reply-To: <545A3451.2090302@pengutronix.de> Sender: linux-can-owner@vger.kernel.org List-ID: To: Marc Kleine-Budde , Dong Aisheng , linux-can@vger.kernel.org Cc: wg@grandegger.com, varkabhadram@gmail.com, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org Hi all, just to close this application note relevant point ... I got an answer from Florian Hartwich (Mr. CAN) from Bosch regarding th= e bit=20 error detection found by Dong Aisheng. The relevant interrupts IR.BEU or IR.BEC monitor the message RAM: Bit 21 BEU: Bit Error Uncorrected Message RAM bit error detected, uncorrected. Controlled by input signal= =20 m_can_aeim_berr[1] generated by an optional external parity / ECC logic= =20 attached to the Message RAM. An uncorrected Message RAM bit error sets=20 CCCR.INIT to =E2=80=981=E2=80=99. This is done to avoid transmission of= corrupted data. 0=3D No bit error detected when reading from Message RAM 1=3D Bit error detected, uncorrected (e.g. parity logic) Bit 20 BEC: Bit Error Corrected Message RAM bit error detected and corrected. Controlled by input signa= l=20 m_can_aeim_berr[0] generated by an optional external parity / ECC logic= =20 attached to the Message RAM. 0=3D No bit error detected when reading from Message RAM 1=3D Bit error detected and corrected (e.g. ECC) --- The Message RAM is usually equipped with a parity or ECC functionality. But RAM cells suffer a hardware reset and can therefore hold arbitrary = content=20 at startup - including parity and/or ECC bits. So when you write only the CAN ID and the first four bytes the last fou= r bytes=20 remain untouched. Then the M_CAN starts to read in 32bit words from the= start=20 of the Tx Message element. So it is very likely to trigger the message = RAM=20 error when reading the uninitialized 32bit word from the last four byte= s. =46inally it turns out that an initial writing (with any kind of data) = to the=20 entire message RAM is mandatory to create valid parity/ECC checksums. That's it. Regards, Oliver From mboxrd@z Thu Jan 1 00:00:00 1970 From: socketcan@hartkopp.net (Oliver Hartkopp) Date: Wed, 05 Nov 2014 19:15:10 +0100 Subject: M_CAN message RAM initialization AppNote - was: Re: [PATCH V3 3/3] can: m_can: workaround for transmit data less than 4 bytes In-Reply-To: <545A3451.2090302@pengutronix.de> References: <1415193393-30023-1-git-send-email-b29396@freescale.com> <1415193393-30023-3-git-send-email-b29396@freescale.com> <545A3451.2090302@pengutronix.de> Message-ID: <545A692E.40002@hartkopp.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi all, just to close this application note relevant point ... I got an answer from Florian Hartwich (Mr. CAN) from Bosch regarding the bit error detection found by Dong Aisheng. The relevant interrupts IR.BEU or IR.BEC monitor the message RAM: Bit 21 BEU: Bit Error Uncorrected Message RAM bit error detected, uncorrected. Controlled by input signal m_can_aeim_berr[1] generated by an optional external parity / ECC logic attached to the Message RAM. An uncorrected Message RAM bit error sets CCCR.INIT to ?1?. This is done to avoid transmission of corrupted data. 0= No bit error detected when reading from Message RAM 1= Bit error detected, uncorrected (e.g. parity logic) Bit 20 BEC: Bit Error Corrected Message RAM bit error detected and corrected. Controlled by input signal m_can_aeim_berr[0] generated by an optional external parity / ECC logic attached to the Message RAM. 0= No bit error detected when reading from Message RAM 1= Bit error detected and corrected (e.g. ECC) --- The Message RAM is usually equipped with a parity or ECC functionality. But RAM cells suffer a hardware reset and can therefore hold arbitrary content at startup - including parity and/or ECC bits. So when you write only the CAN ID and the first four bytes the last four bytes remain untouched. Then the M_CAN starts to read in 32bit words from the start of the Tx Message element. So it is very likely to trigger the message RAM error when reading the uninitialized 32bit word from the last four bytes. Finally it turns out that an initial writing (with any kind of data) to the entire message RAM is mandatory to create valid parity/ECC checksums. That's it. Regards, Oliver