CAN-Bus verliert Pakete

haeberle · Oct 19th 2009

Hallo zusammen,

Ich habe folgende Probleme und dachte ich informier mal drüber. Vielleicht gibt es auch andere mit selbigen Problemen.
Oder jemand der dies bei ähnlichen Aufgabemn nicht beobachtet hat und mir dies dann auch mitteilen will.

Verwenden tu ich emlix Professional:

wenn ich z.B. 10 Pakete mit 8 datenbytes im Abstand von ca. 160us (so schnell ich es halt mit meiner CAN Karte rausbekomem) abschicke, sehe ich nur die 3 ersten und das letzte Paket sicher. dazwischen fehlen mehr alsd 50% der Pakte
Dies passiert auch bei 500kBit und 250kBit. Und - natürlich - auch, wenn DLC = 0 (also keine Daten) im Paket sind
Die baudrate lässt sich in einem startscript - direkt nach dem laden des modules - nicht setzten
Liegt auf dem CAN Bus ein Paket mit anderer Baudrate (500kBit oder 1MBit) an und der Bus ist auf z.B. 250k eingestellt bleibt das System beim aufruf con ifconfig can0 up hängen. Es geht erst weiter, wenn der andere teilnehmer auf die gleiche Baudarte eingestellt wird.
bei 125kBit und auf dem Bus und 1Mit Einstellung via baud rate set gibt es einen kernel opps (siehe ende des posts)

Für mich wäre das ein KO Kriterium für das Modul. Aber irgendwei kann ich nicht glauben dass das wirklich so ist.

Heinz

Code

# ifconfig can0 up
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c1ff4000
[00000000] *pgd=21dfd031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1] PREEMPT
Modules linked in: sd_mod g_ether at91_udc usb_storage scsi_mod vfat fat at91_mci mmc_block mmc_core spidev mcp251x atmel_spi
CPU: 0 Not tainted (2.6.27-PicoCOM1-Professional-BSP #1)
PC is at can_rcv+0x50/0x138
LR is at netif_receive_skb+0x274/0x2d0
pc : [<c0249330>] lr : [<c01e18dc>] psr: 20000013
sp : c1fedc10 ip : c1fedc30 fp : c1fedc2c
r10: c0326e74 r9 : c1fec000 r8 : 00000c00
r7 : 00000000 r6 : c1d57000 r5 : c1d0d240 r4 : c1d0d240
r3 : 00000000 r2 : c1e74610 r1 : c1d57000 r0 : c1d0d240
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: 21ff4000 DAC: 00000015
Process ifconfig (pid: 412, stack limit = 0xc1fec268)
Stack: (0xc1fedc10 to 0xc1fee000)
dc00: c1fedc3c c1d0d240 c0326e5c c1d57000
dc20: c1fedc5c c1fedc30 c01e18dc c02492f0 c1fedc4c c1fedc40 c0326dec 00000001
dc40: 00000040 fffff721 0000012c fffff721 c1fedc7c c1fedc60 c01e19c4 c01e1678
dc60: c0326dec 00000040 0000000a 00000002 c1fedca4 c1fedc80 c01e01ac c01e1948
dc80: c031d580 00000001 0000000a 00000002 00000001 00000002 c1fedcc4 c1fedca8
dca0: c003b924 c01e0148 c1fec000 c0305268 0000000d 00000000 c1fedcdc c1fedcc8
dcc0: c003b9e4 c003b8d4 0000000d c0305268 c1fedcfc c1fedce0 c0025058 c003b9a8
dce0: c00519f4 ffffffff fefff000 0000000d c1fedd84 c1fedd00 c00258c8 c0025010
dd00: c1fedda0 c1fedda0 00000001 80000013 c1fedd58 c1c5d040 c1fec000 c1fedd9c
dd20: 7fffffff c1d57428 00000002 c1fedd84 00000000 c1fedd48 c026a480 c026a510
dd40: 80000013 ffffffff bf000490 00000001 c1c5d040 c0031a90 c1fedda0 c1fedda0
dd60: c1fedd9c c1feddc0 c1d39980 0000000e c1d57360 c1da6a00 c1fedd94 c1fedd88
dd80: c026a690 c026a434 c1feddbc c1fedd98 c01b0cd8 c026a688 c1feddbc 00000001
dda0: c1fedd58 c1fedd58 00000003 c1d39960 c1fede3c c1feddc0 bf0030d0 c01b0c90
ddc0: c1fede08 c1fede08 c1da6a00 00000000 c01b0e48 c1fedd9c 00000003 00000000
dde0: 00100100 00200200 00000000 c1d39960 c1d39980 00000003 21d39960 21d39980
de00: 00000000 00000000 c1feddc0 c1feddc0 c1fede6c c1da6a00 c1d57360 000000c1
de20: 00000080 c1c3ca8c 00000000 c1d57000 c1fede54 c1fede40 bf0035ac bf003024
de40: c1d57000 00000041 c1fede6c c1fede58 c01e3390 bf0034f4 c1d57000 c1d57000
de60: c1fede8c c1fede70 c01e2c3c c01e3300 00000001 00000000 c1c3ca80 c1fedeb0
de80: c1fedefc c1fede90 c02237f0 c01e2ba0 00000020 00000000 beda7cf0 00008914
dea0: 306e6163 00000000 00000000 00000000 000000c1 4001a6a8 beda7f89 0006fa01
dec0: 000000c1 4001a6a8 beda7f89 0006fa01 00000080 beda7cf0 00008914 beda7cf0
dee0: beda7cf0 c0025e44 c1fec000 4002e000 c1fedf14 c1fedf00 c0224994 c0223514
df00: c1fec000 c1e25800 c1fedf34 c1fedf18 c01d4400 c02248d0 c01d4a74 c1e25800
df20: beda7cf0 00008914 c1fedf54 c1fedf38 c009f860 c01d421c 00000000 00000003
df40: c1e25800 00008914 c1fedf7c c1fedf58 c009fb80 c009f838 00000004 beda7ecc
df60: 00000003 beda7cf0 00008914 c1e25800 c1fedfa4 c1fedf80 c009fbf0 c009f8d0
df80: ffffffff 00000000 00070f5f 00000004 beda7ecc 00000036 00000000 c1fedfa8
dfa0: c0025cc0 c009fbc0 00070f5f 00000004 00000003 00008914 beda7cf0 00070f5f
dfc0: 00070f5f 00000004 beda7ecc 00000036 0006e170 00000000 4002e000 00000000
dfe0: 0000017a beda7cd8 0000d680 401f582c 20000010 00000003 00001302 00034225
Backtrace:
[<c02492e0>] (can_rcv+0x0/0x138) from [<c01e18dc>] (netif_receive_skb+0x274/0x2d0)
r6:c1d57000 r5:c0326e5c r4:c1d0d240
[<c01e1668>] (netif_receive_skb+0x0/0x2d0) from [<c01e19c4>] (process_backlog+0x8c/0x120)
[<c01e1938>] (process_backlog+0x0/0x120) from [<c01e01ac>] (net_rx_action+0x74/0x1ac)
r7:00000002 r6:0000000a r5:00000040 r4:c0326dec
[<c01e0138>] (net_rx_action+0x0/0x1ac) from [<c003b924>] (__do_softirq+0x60/0xd4)
[<c003b8c4>] (__do_softirq+0x0/0xd4) from [<c003b9e4>] (irq_exit+0x4c/0xa0)
r6:00000000 r5:0000000d r4:c0305268
[<c003b998>] (irq_exit+0x0/0xa0) from [<c0025058>] (__exception_text_start+0x58/0x70)
r4:c0305268
[<c0025000>] (__exception_text_start+0x0/0x70) from [<c00258c8>] (__irq_svc+0x48/0x8c)
Exception stack(0xc1fedd00 to 0xc1fedd48)
dd00: c1fedda0 c1fedda0 00000001 80000013 c1fedd58 c1c5d040 c1fec000 c1fedd9c
dd20: 7fffffff c1d57428 00000002 c1fedd84 00000000 c1fedd48 c026a480 c026a510
dd40: 80000013 ffffffff
r6:0000000d r5:fefff000 r4:ffffffff
[<c026a424>] (wait_for_common+0x0/0x1dc) from [<c026a690>] (wait_for_completion+0x18/0x1c)
[<c026a678>] (wait_for_completion+0x0/0x1c) from [<c01b0cd8>] (spi_sync+0x58/0x70)
[<c01b0c80>] (spi_sync+0x0/0x70) from [<bf0030d0>] (mcp251x_read_reg+0xbc/0xe4 [mcp251x])
r5:c1d39960 r4:00000003
[<bf003014>] (mcp251x_read_reg+0x0/0xe4 [mcp251x]) from [<bf0035ac>] (mcp251x_open+0xc8/0xe4 [mcp251x])
[<bf0034e4>] (mcp251x_open+0x0/0xe4 [mcp251x]) from [<c01e3390>] (dev_open+0xa0/0x10c)
r5:00000041 r4:c1d57000
[<c01e32f0>] (dev_open+0x0/0x10c) from [<c01e2c3c>] (dev_change_flags+0xac/0x18c)
r4:c1d57000
[<c01e2b90>] (dev_change_flags+0x0/0x18c) from [<c02237f0>] (devinet_ioctl+0x2ec/0x714)
r7:c1fedeb0 r6:c1c3ca80 r5:00000000 r4:00000001
[<c0223504>] (devinet_ioctl+0x0/0x714) from [<c0224994>] (inet_ioctl+0xd4/0x10c)
[<c02248c0>] (inet_ioctl+0x0/0x10c) from [<c01d4400>] (sock_ioctl+0x1f4/0x254)
r4:c1e25800
[<c01d420c>] (sock_ioctl+0x0/0x254) from [<c009f860>] (vfs_ioctl+0x38/0x98)
r6:00008914 r5:beda7cf0 r4:c1e25800
[<c009f828>] (vfs_ioctl+0x0/0x98) from [<c009fb80>] (do_vfs_ioctl+0x2c0/0x2f0)
r6:00008914 r5:c1e25800 r4:00000003
[<c009f8c0>] (do_vfs_ioctl+0x0/0x2f0) from [<c009fbf0>] (sys_ioctl+0x40/0x64)
r7:c1e25800 r6:00008914 r5:beda7cf0 r4:00000003
[<c009fbb0>] (sys_ioctl+0x0/0x64) from [<c0025cc0>] (ret_fast_syscall+0x0/0x2c)
r7:00000036 r6:beda7ecc r5:00000004 r4:00070f5f
Code: e5d23004 e3530008 9a000001 e3a03000 (e5833000)
Kernel panic - not syncing: Fatal exception in interrupt

Display More

haeberle · Oct 19th 2009

Was auch noch interessant - und da spreche ich natürlich F&S hauptsächlich an - wäre ist die Frage ob es bei bestimmten Baudraten auch unter Windows CE Verluste gibt.

Was passiert bei 1Mbit mit DLC=0 (höchte denkbare Paketrate)? Bekommt eine Applikation alle Pakete?

Heinz

GKollmann · Aug 19th 2011

na da scheint ja jemand auf arg verlorenen Posten zu agieren...

Bisher ohne CAN auf dem Picocom aber mit einer Idee die natürlich verpufft wenn CAN/Picocom nix taugt.

fs-support_HK · Aug 22nd 2011

We are mostly using the MCP2515 CAN controller on our boards. This controller is connected via SPI to the main CPU. As a conseqeunce, the performance of the CAN transmission is dependent on the performance of the SPI transmission. Under Windows CE we therefore can operate the CAN controller on the PicoCOM1 in two modes: indirectly via the SPI driver and with direct SPI access.

1. Via SPI driver
In this mode the CAN driver accesses the CAN controller by issuing calls to the SPI driver. This is the only way if there are other SPI devices connected to the SPI bus, as the SPI driver guarantees a correct synchronization of all SPI accesses. However using this additional SPI driver layer generates some overhead that reduces the CAN performance.

2. Direct SPI access
In this mode the CAN driver directly accesses the SPI bus by generating the SPI messages itself. Of course this only will work if there is no other device on the SPI bus than the CAN controller. By bypassing the SPI driver, this access method is more efficient, increasing the CAN performance.

As far as we know emlix only implemented method 1 under Linux on the PicoCOM1. So there may be some issues with CAN there.

In addition the SPI transfer on the Atmel controller used on the PicoCOM1 can not exceed 7 MHz and always needs to use DMA. Usually DMA is a good solution for fast transfers, but when regarding the short messages that need to be transferred to the CAN controller, the overhead for setting up DMA for each of these transfers is bigger than the gain from the fast transfer itself. Therefore this combination is not optimal.

Our newer PicoCOM boards PicoCOM3 and PicoCOM4 use another micro controller, where the SPI transmission can be much faster. On one hand, the basic SPI rate can be up to the maximum 10 MHz that the MCP2515 is capable of. And the overhead is also less because the SPI uses a FIFO where all messages fit into. So there is no need for using DMA, reducing all the DMA setup overhead. And these boards use a newer kernel version too, where some of the issues of the Linux CAN driver are already fixed.

In the end we would recommend PicoCOM3 or PicoCOM4 if you really need fast CAN transmission. But if CAN transmission can also happen at lower speeds, PicoCOM1 may still be suited well enough.

Share