This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CAN bus on olimex LPC-L2294

I have read more carefully documentation for CANMOD register. It
confirms that normal mode transmitted messages must be acknowledged.
So it seems transmitting works but receiving doesn't.

Bronislav Gabrhelik

2008/9/19 Bronislav Gabrhelik <>:
> I have hard time to make CAN working on OLIMEX LPC-L2294. Both
> transmitting and receiving doesn't work for me. I have two LPC-L2294
> boards wired by CAN cable made by me. I double verified that it is
> wired correctly.  Receiving didn't work, so I concentrated on
> transmitting and measured signal between driver and LPC with
> oscilloscope. The transmitting program is derived from test
> ecos/packages/devs/can/arm/lpc2xxx/current/tests/can_rx_tx.c . The
> application got stuck on 33rd message after sending 32 messages. Yes -
> the transmitting queue is configured to have length 32. The LPC is
> transmitting indefinitely the same pattern which will be described
> later. My thought was that CAN controller doesn't have a feedback for
> arbitration, so RD1 is not connected properly. I verified that signal
> is physically on RD1 by oscilloscope and that PINSEL1 was not
> overwritten by some other module.
> The first message (which I believe is transmitted indefinitely) ID is
> 0 and I use standard message (11bit identifier). The data length is 0.
> The CAN BUS speed is 100kbits, so 1bit width is 10 [usec]. I am not
> sure if this behavior is correct because message was not acknowledged
> by any node, but I tried to receive data be other board with no
> change.
> I see the following pattern repeatly
> d = dominant (L),  r = recessive(H),   5d = 5 dominant bits
> 5d-1r-5d-1r-5d-1r-5d-1r-5d-1r-5d-1r-4d-27r
> all 1r in pattern is bit stuffing
> I am not sure where is the Start-of-frame in this pattern to analyze
> it more precisely. But it seems that it transmitted 34 bits (5d*6+4d),
> which is can be data from Start-of-frame to CRC. But why block 27r
> doesn't contain stuffing bits? Is ACK by any node in CAN mandatory?
> I appreciate any input or thought.
> Bronislav Gabrhelik

Before posting, please read the FAQ:
and search the list archive:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]