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 Return-path: Received: from mail-bn1bon0139.outbound.protection.outlook.com ([157.56.111.139]:11230 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750990AbaKFC1X (ORCPT ); Wed, 5 Nov 2014 21:27:23 -0500 Content-Disposition: inline In-Reply-To: <545A692E.40002@hartkopp.net> Sender: linux-can-owner@vger.kernel.org List-ID: To: Oliver Hartkopp Cc: Marc Kleine-Budde , linux-can@vger.kernel.org, wg@grandegger.com, varkabhadram@gmail.com, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.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