public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] CAN bus on olimex LPC-L2294
@ 2008-09-19 16:21 Bronislav Gabrhelik
  2008-09-22  8:32 ` [ECOS] " Bronislav Gabrhelik
  0 siblings, 1 reply; 2+ messages in thread
From: Bronislav Gabrhelik @ 2008-09-19 16:21 UTC (permalink / raw)
  To: eCos discuss mailing list

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.
TIA
Bronislav Gabrhelik

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [ECOS] Re: CAN bus on olimex LPC-L2294
  2008-09-19 16:21 [ECOS] CAN bus on olimex LPC-L2294 Bronislav Gabrhelik
@ 2008-09-22  8:32 ` Bronislav Gabrhelik
  0 siblings, 0 replies; 2+ messages in thread
From: Bronislav Gabrhelik @ 2008-09-22  8:32 UTC (permalink / raw)
  To: eCos discuss mailing list

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 <xxx@ahojky.com>:
> 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.
> TIA
> Bronislav Gabrhelik
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-09-21 20:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-19 16:21 [ECOS] CAN bus on olimex LPC-L2294 Bronislav Gabrhelik
2008-09-22  8:32 ` [ECOS] " Bronislav Gabrhelik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).