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
