From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dong Aisheng Subject: Re: M_CAN message RAM initialization AppNote - was: Re: [PATCH V3 3/3] can: m_can: workaround for transmit data less than 4 bytes Date: Thu, 6 Nov 2014 09:57:17 +0800 Message-ID: <20141106015716.GB7642@shlinux1.ap.freescale.net> References: <1415193393-30023-1-git-send-email-b29396@freescale.com> <1415193393-30023-3-git-send-email-b29396@freescale.com> <545A3451.2090302@pengutronix.de> <545A692E.40002@hartkopp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Marc Kleine-Budde , , , , , To: Oliver Hartkopp Return-path: Content-Disposition: inline In-Reply-To: <545A692E.40002@hartkopp.net> Sender: linux-can-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Wed, Nov 05, 2014 at 07:15:10PM +0100, Oliver Hartkopp wrote: > Hi all, >=20 > just to close this application note relevant point ... >=20 > I got an answer from Florian Hartwich (Mr. CAN) from Bosch regarding > the bit error detection found by Dong Aisheng. >=20 > The relevant interrupts IR.BEU or IR.BEC monitor the message RAM: >=20 > 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 =E2=80=981=E2=80=99. This is done to avoi= d transmission > of corrupted data. >=20 > 0=3D No bit error detected when reading from Message RAM > 1=3D Bit error detected, uncorrected (e.g. parity logic) >=20 > 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. >=20 > 0=3D No bit error detected when reading from Message RAM > 1=3D Bit error detected and corrected (e.g. ECC) >=20 > --- >=20 > The Message RAM is usually equipped with a parity or ECC functionalit= y. > But RAM cells suffer a hardware reset and can therefore hold > arbitrary content at startup - including parity and/or ECC bits. >=20 > 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. >=20 > 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. >=20 > That's it. >=20 Thanks for sharing this information. Does it mean this issue is related to the nature of Message RAM and is supposed to exist on all M_CAN IP versions? > Regards, > Oliver >=20 Regards Dong Aisheng