1. Home
  2. Embedded Programming
  3. an interesting CAN driver issue

an interesting CAN driver issue

Hello All,

from past few days I was facing an intersting prob with CAN driver implementation. I was using the Star12 Xgate processor. The CAN driver was initialized properly and it was working with vector CAN Card XL. The frames transmitted from the CAN controller were seen on the Oscilloscope and the frames were appearing on the CANAlyzer Trace window properly. Everything worked perfectly fine. But when I replaced the vector CAN Card XL with CAN Card X, the frames stopped appearing on the trace window. But they were present on the CAN bus, I could verify the same with an oscilloscope. The code downloaded on the ECU was same as it was in case of CANCardXL.

after so much debugging I found that the DLC register was creating the problem. I wanted to transmit always an 8 bytes long frame. I was putting the value of dlc as -->> DLC_Reg |= 0x08; with this the frames were observed on the CAN CardXL. but not with CAN Card X.

When I changed the implementation to -->> DLC_Reg |= 0x08; The CAN Card X also worked fine. All frames started appearing on the CANalyzer trace window.

In both the cases, there were no error frames, no error counter increament, CANalyzer bus statistics window also showed the standard data frames increamenting on the bus.

So can any one of you please point out the DLC value was responsible for the frame reception on the CANalyzer trace window.

The same frame was not seen on CANCardX but on CANCardXL, it was visible and in both the cases the oscilloscope was showing the frame on the bus.

Please provide your feedback in understanding the root cause of the problem.

Regards Akhilesh

Reply to
Achilles
Loading thread data ...

The only viable conclusion to be drawn from that is that something about your CanCard X (the card itself, the drivers you're using with it, or its firmware) is plain and simply broken.

You're making no sense whatsoever. You changed it, to the exact same thing, and behaviour changes?

Reply to
Hans-Bernhard Bröker

I am sorry for my mistake. I changed the DLC register value assignment to DLC_Reg =3D 0x08;(direct assignment) from DLC_Reg |=3D 0x08; So I was directly assigning the value to DLC_Reg. And after that it worked with CANCardX.

I was also doubting the CAN Card X firmware, But the same CAN Card X was working with the vector CAN driver code for the same ECU. So we just eliminated that doubt.

Now do you have any other opinion about this problem?

Regards Achilles

Reply to
Achilles

On 31 May 2007 16:50:59 -0700, Achilles wrote in comp.arch.embedded:

The new statement, DLC_Reg = 0x08, unconditionally sets the value of the DLC_Reg to 8. Exactly one bit is set in the register, bit 3, and all other bits are zeroed.

The old statement, DLC_Reg |= 0x08, unconditionally sets bit 3 of the register to 1, whether it was previously 1 or 0. None of the other bits in the register are changed.

I would say that it was pretty obvious that some bit or bits in the register were not set to 0, and your first code left them at their non-zero value. Most likely, these bits had some improper value that the old code left unchanged, and the new code sets to 0 which is valid.

Put a breakpoint in your code and see what the value in DLC_Reg is before you modify it. Most likely it will not contain all 0 bits.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Reply to
Jack Klein

Or even worse, maybe it's a write only register and you are either reading random noise or some other read only register. To go even further down that road, the act of reading that read only register could have side effects.

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

Then whatever appeared to work with the other CAN card before was a fluke. The |= version of that code was just plain dumb wrong. It only ever worked by some freaky coincidence.

Reply to
Hans-Bernhard Bröker

I don't think the CANcardX supports a DLC > 8. CANcardXL should support it however. By setting bit 3 in the DLC the OP is basically setting a DLC somewhere between 8 and 15. Such frames are probably ignored by the CANcardX but properly handled by the XL.

--
Daniel Berglund
Reply to
Daniel Berglund

There's no such thing as "properly handling" a CAN frame with a DLC of more than 8 bytes. That's not a CAN frame, period. The only proper reaction to it is to reject it as a protocol violation.

Reply to
Hans-Bernhard Bröker

Yes, DLC > 8 is in the standard from 2003 and onwards. All existing CAN controllers (maybe with the exception of the 82526) can handle this. Turns out that this feature has been in the silicon verification suite since day 1.

In particular, the SJA1000 in the CANcardX and the CANcardXL can handle it.

Note that the *length* of the message still is at most 8. The DLC can be anything between 0 and 15, where a DLC from 9 to 15 means there's still just 8 bytes of data.

So by this after-the-fact extension of the CAN protocol you gain almost a full bit of extra information in each message :-)

And yes, there are people who use this feature. As I said it's fully compliant with the standard.

--
Daniel Berglund
Reply to
Daniel Berglund

could you please tell me from where I can download the CAN protocol specification > 2003

t=2E

Reply to
Achilles

Pardon my scepticism, but before I believe that one, I'll need an authoritative source. Care citing a reference?

Reply to
Hans-Bernhard Bröker

From ISO 11898-1 (2003):

8.4.2.3 DLC field The number of bytes in the data field shall be indicated by the DLC (see Table 4). This DLC shall consist of four (4) bits. The admissible number of data bytes for a data frame shall range from zero (0) to eight (8). DLCs in the range of zero (0) to seven (7) shall indicate data fields of length of zero (0) to seven (7) bytes. All other DLCs shall indicate that the data field is eight (8) bytes long.

You can compare this with the edition from 1993, where it is exactly as you state - DLC > 8 is illegal.

I have no (written) authoritative source to the second claim.

--
Daniel Berglund
Reply to
Daniel Berglund

Reply to
Daniel Berglund

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.