* RTCan missing frames
@ 2019-02-11 9:16 Johannes Holtz
2019-02-11 11:14 ` Philippe Gerum
[not found] ` <5f653b5a-e82f-ce42-c8c6-3fa05ccce53d@grandegger.com>
0 siblings, 2 replies; 23+ messages in thread
From: Johannes Holtz @ 2019-02-11 9:16 UTC (permalink / raw)
To: xenomai
Hi,
In my application i set up a RTCAN socket and a pair of rt-threads. One
to read and one to write. Writing works perfectly and I receive answers
in the initial phase of the program.
In particular I send CANopen NMT messages out and receive the responses
from the other Nodes in the Network.
2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0:
CAN ID 0x000 FC 0x0 DLC 2
0 82 00
2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control Node
0:8:
CAN ID 0x708 FC 0xe DLC 1
0 00
2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control Node
0:9:
CAN ID 0x709 FC 0xe DLC 1
0 00
2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node
0:3:
CAN ID 0x703 FC 0xe DLC 1
0 00
2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node
0:4:
CAN ID 0x704 FC 0xe DLC 1
0 00
2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node
0:5:
CAN ID 0x705 FC 0xe DLC 7
0 00 06 07 00
4 00 01 01
2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0:
CAN ID 0x000 FC 0x0 DLC 3
0 07 00 00
2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1:
CAN ID 0x101 FC 0x2 DLC 0
As you can see, I capture 7 frames. However, the RX count from
/proc/rtcan/devices is 10.
If I send specific SDO requests to one of the node which have answered I
don't capture a response but the RX count increases and rtcanrecv
program captures the correct response. Only my application's read
doesn't return.
I have not altered the filters and the RX and TX timeouts are at
100micro sec. I also don't get error frames. The RX_BufFull indicator
from /proc/rtcan/sockets keeps growing.
Also the rtcanrecv utility shows garbage if i let it run but if I
restart it after each request the first response is printed correctly.
Can you give me any advice? I followed every example and documentation
about rtcan but I'm running out of ideas what the cause could be.
I'm still using the "old" 2.6.3 xenomai but I sincerely hope this is not
an old known issue. I rather hope there is something wrong with my approach.
I'm thankful for every hint.
Cheers,
Johannes
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: RTCan missing frames 2019-02-11 9:16 RTCan missing frames Johannes Holtz @ 2019-02-11 11:14 ` Philippe Gerum 2019-02-11 11:53 ` Johannes Holtz 2019-02-11 14:18 ` Johannes Holtz [not found] ` <5f653b5a-e82f-ce42-c8c6-3fa05ccce53d@grandegger.com> 1 sibling, 2 replies; 23+ messages in thread From: Philippe Gerum @ 2019-02-11 11:14 UTC (permalink / raw) To: Johannes Holtz, xenomai On 2/11/19 10:16 AM, Johannes Holtz via Xenomai wrote: > Hi, > > In my application i set up a RTCAN socket and a pair of rt-threads. One > to read and one to write. Writing works perfectly and I receive answers > in the initial phase of the program. > > In particular I send CANopen NMT messages out and receive the responses > from the other Nodes in the Network. > > 2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0: > CAN ID 0x000 FC 0x0 DLC 2 > 0 82 00 > 2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control Node > 0:8: > CAN ID 0x708 FC 0xe DLC 1 > 0 00 > 2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control Node > 0:9: > CAN ID 0x709 FC 0xe DLC 1 > 0 00 > 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node > 0:3: > CAN ID 0x703 FC 0xe DLC 1 > 0 00 > 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node > 0:4: > CAN ID 0x704 FC 0xe DLC 1 > 0 00 > 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node > 0:5: > CAN ID 0x705 FC 0xe DLC 7 > 0 00 06 07 00 > 4 00 01 01 > 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0: > CAN ID 0x000 FC 0x0 DLC 3 > 0 07 00 00 > 2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1: > CAN ID 0x101 FC 0x2 DLC 0 > > As you can see, I capture 7 frames. However, the RX count from > /proc/rtcan/devices is 10. > > If I send specific SDO requests to one of the node which have answered I > don't capture a response but the RX count increases and rtcanrecv > program captures the correct response. Only my application's read > doesn't return. > You mean recvmsg() does not return, correct? > I have not altered the filters and the RX and TX timeouts are at > 100micro sec. I also don't get error frames. The RX_BufFull indicator > from /proc/rtcan/sockets keeps growing. > RX_BufFull increasing means that the (raw) socket's ring buffer is overflowing, which makes sense if it is not emptied by reading from it on the other end. > Also the rtcanrecv utility shows garbage if i let it run but if I > restart it after each request the first response is printed correctly. > > > Can you give me any advice? I followed every example and documentation > about rtcan but I'm running out of ideas what the cause could be. > We have no idea of the CPU architecture you are working on, your target kernel is undefined, just like the CAN chip you have been using which makes it impossible to find out which RTCAN driver is involved. This does not help. > I'm still using the "old" 2.6.3 xenomai but I sincerely hope this is not Not only old (2013), but officially EOL. > an old known issue. Looking into the commit logs from the Xenomai git tree regarding any change in the RTCAN stack since 2.6.3 would be a good start. https://gitlab.denx.de/Xenomai/xenomai/tree/eol/v2.6.x https://gitlab.denx.de/Xenomai/xenomai/tree/next > I rather hope there is something wrong with my > approach. > > I'm thankful for every hint Enabling the *DRIVERS_CAN_DEBUG Kconfig switch may give you more hints. -- Philippe. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-11 11:14 ` Philippe Gerum @ 2019-02-11 11:53 ` Johannes Holtz 2019-02-11 14:18 ` Johannes Holtz 1 sibling, 0 replies; 23+ messages in thread From: Johannes Holtz @ 2019-02-11 11:53 UTC (permalink / raw) To: Philippe Gerum, xenomai Am 11.02.19 um 12:14 schrieb Philippe Gerum: > On 2/11/19 10:16 AM, Johannes Holtz via Xenomai wrote: >> Hi, >> >> In my application i set up a RTCAN socket and a pair of rt-threads. One >> to read and one to write. Writing works perfectly and I receive answers >> in the initial phase of the program. >> >> In particular I send CANopen NMT messages out and receive the responses >> from the other Nodes in the Network. >> >> 2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0: >> CAN ID 0x000 FC 0x0 DLC 2 >> 0 82 00 >> 2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control Node >> 0:8: >> CAN ID 0x708 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control Node >> 0:9: >> CAN ID 0x709 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >> 0:3: >> CAN ID 0x703 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >> 0:4: >> CAN ID 0x704 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >> 0:5: >> CAN ID 0x705 FC 0xe DLC 7 >> 0 00 06 07 00 >> 4 00 01 01 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0: >> CAN ID 0x000 FC 0x0 DLC 3 >> 0 07 00 00 >> 2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1: >> CAN ID 0x101 FC 0x2 DLC 0 >> >> As you can see, I capture 7 frames. However, the RX count from >> /proc/rtcan/devices is 10. >> >> If I send specific SDO requests to one of the node which have answered I >> don't capture a response but the RX count increases and rtcanrecv >> program captures the correct response. Only my application's read >> doesn't return. >> > You mean recvmsg() does not return, correct? No, I have used rt_dev_recv() as I thought it would suffice. I short test with a different call hasn't shown any difference. > >> I have not altered the filters and the RX and TX timeouts are at >> 100micro sec. I also don't get error frames. The RX_BufFull indicator >> from /proc/rtcan/sockets keeps growing. >> > RX_BufFull increasing means that the (raw) socket's ring buffer is > overflowing, which makes sense if it is not emptied by reading from it > on the other end. > >> Also the rtcanrecv utility shows garbage if i let it run but if I >> restart it after each request the first response is printed correctly. >> >> >> Can you give me any advice? I followed every example and documentation >> about rtcan but I'm running out of ideas what the cause could be. >> > We have no idea of the CPU architecture you are working on, your target > kernel is undefined, just like the CAN chip you have been using which > makes it impossible to find out which RTCAN driver is involved. This > does not help. root@machinectrl:~# uname -a Linux machinectrl 3.8.13-intel-atom #3 SMP Wed Jan 2 11:56:35 CET 2019 i686 GNU/Linux root@machinectrl:~# xeno-config --version 2.6.4 root@machinectrl:~# cat /proc/rtcan/rtcan0/info Device rtcan0 Controller SJA1000 Board EMS-CPC-PCI Clock-Hz 8000000 Baudrate 1000000 Bit-time brp=1 prop_seg=2 phase_seg1=3 phase_seg2=2 sjw=1 sam=1 Ctrl-Mode State active TX-Counter 27 RX-Counter 167 Errors 0 Refcount 0 [ 3.171332] RT-Socket-CAN 0.90.2 - (C) 2006 RT-Socket-CAN Development Team [ 3.172383] RTCAN SJA1000 driver initialized [ 3.173287] rtcan: registered rtcan0 [ 3.173351] EMS-CPC-PCI-CAN 0000:07:02.0: Channel #1 at 0xf84fa400, irq 17 registered as rtcan0 [ 3.173450] rtcan: registered rtcan1 [ 3.173508] EMS-CPC-PCI-CAN 0000:07:02.0: Channel #2 at 0xf84fa600, irq 17 registered as rtcan1 > >> I'm still using the "old" 2.6.3 xenomai but I sincerely hope this is not > Not only old (2013), but officially EOL. > >> an old known issue. > Looking into the commit logs from the Xenomai git tree regarding any > change in the RTCAN stack since 2.6.3 would be a good start. > > https://gitlab.denx.de/Xenomai/xenomai/tree/eol/v2.6.x > https://gitlab.denx.de/Xenomai/xenomai/tree/next Thank you for the references. >> I rather hope there is something wrong with my >> approach. >> >> I'm thankful for every hint > Enabling the *DRIVERS_CAN_DEBUG Kconfig switch may give you more hints. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-11 11:14 ` Philippe Gerum 2019-02-11 11:53 ` Johannes Holtz @ 2019-02-11 14:18 ` Johannes Holtz 1 sibling, 0 replies; 23+ messages in thread From: Johannes Holtz @ 2019-02-11 14:18 UTC (permalink / raw) To: Philippe Gerum, xenomai Am 11.02.19 um 12:14 schrieb Philippe Gerum: > On 2/11/19 10:16 AM, Johannes Holtz via Xenomai wrote: >> Hi, >> >> In my application i set up a RTCAN socket and a pair of rt-threads. One >> to read and one to write. Writing works perfectly and I receive answers >> in the initial phase of the program. >> >> In particular I send CANopen NMT messages out and receive the responses >> from the other Nodes in the Network. >> >> 2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0: >> CAN ID 0x000 FC 0x0 DLC 2 >> 0 82 00 >> 2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control Node >> 0:8: >> CAN ID 0x708 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control Node >> 0:9: >> CAN ID 0x709 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >> 0:3: >> CAN ID 0x703 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >> 0:4: >> CAN ID 0x704 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >> 0:5: >> CAN ID 0x705 FC 0xe DLC 7 >> 0 00 06 07 00 >> 4 00 01 01 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0: >> CAN ID 0x000 FC 0x0 DLC 3 >> 0 07 00 00 >> 2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1: >> CAN ID 0x101 FC 0x2 DLC 0 >> >> As you can see, I capture 7 frames. However, the RX count from >> /proc/rtcan/devices is 10. >> >> If I send specific SDO requests to one of the node which have answered I >> don't capture a response but the RX count increases and rtcanrecv >> program captures the correct response. Only my application's read >> doesn't return. >> > You mean recvmsg() does not return, correct? I tried the same code with recvmsg() instead and get sometimes EINVAL back but no MSG_OOB flag is set. The iov_len is always 16 and thus presumably doesn't exceed ssize_t. Weird. > >> I have not altered the filters and the RX and TX timeouts are at >> 100micro sec. I also don't get error frames. The RX_BufFull indicator >> from /proc/rtcan/sockets keeps growing. >> > RX_BufFull increasing means that the (raw) socket's ring buffer is > overflowing, which makes sense if it is not emptied by reading from it > on the other end. > >> Also the rtcanrecv utility shows garbage if i let it run but if I >> restart it after each request the first response is printed correctly. >> >> >> Can you give me any advice? I followed every example and documentation >> about rtcan but I'm running out of ideas what the cause could be. >> > We have no idea of the CPU architecture you are working on, your target > kernel is undefined, just like the CAN chip you have been using which > makes it impossible to find out which RTCAN driver is involved. This > does not help. > >> I'm still using the "old" 2.6.3 xenomai but I sincerely hope this is not > Not only old (2013), but officially EOL. > >> an old known issue. > Looking into the commit logs from the Xenomai git tree regarding any > change in the RTCAN stack since 2.6.3 would be a good start. > > https://gitlab.denx.de/Xenomai/xenomai/tree/eol/v2.6.x > https://gitlab.denx.de/Xenomai/xenomai/tree/next > >> I rather hope there is something wrong with my >> approach. >> >> I'm thankful for every hint > Enabling the *DRIVERS_CAN_DEBUG Kconfig switch may give you more hints. > ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <5f653b5a-e82f-ce42-c8c6-3fa05ccce53d@grandegger.com>]
* Re: RTCan missing frames [not found] ` <5f653b5a-e82f-ce42-c8c6-3fa05ccce53d@grandegger.com> @ 2019-02-11 11:55 ` Johannes Holtz 2019-02-11 12:40 ` Wolfgang Grandegger 0 siblings, 1 reply; 23+ messages in thread From: Johannes Holtz @ 2019-02-11 11:55 UTC (permalink / raw) To: Wolfgang Grandegger, xenomai Am 11.02.19 um 12:26 schrieb Wolfgang Grandegger: > Hello, > > Am 11.02.19 um 10:16 schrieb Johannes Holtz via Xenomai: >> Hi, >> >> In my application i set up a RTCAN socket and a pair of rt-threads. One >> to read and one to write. Writing works perfectly and I receive answers >> in the initial phase of the program. >> >> In particular I send CANopen NMT messages out and receive the responses >> from the other Nodes in the Network. >> >> 2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0: >> CAN ID 0x000 FC 0x0 DLC 2 >> 0 82 00 >> 2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control Node >> 0:8: >> CAN ID 0x708 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control Node >> 0:9: >> CAN ID 0x709 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >> 0:3: >> CAN ID 0x703 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >> 0:4: >> CAN ID 0x704 FC 0xe DLC 1 >> 0 00 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >> 0:5: >> CAN ID 0x705 FC 0xe DLC 7 >> 0 00 06 07 00 >> 4 00 01 01 >> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0: >> CAN ID 0x000 FC 0x0 DLC 3 >> 0 07 00 00 >> 2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1: >> CAN ID 0x101 FC 0x2 DLC 0 >> >> As you can see, I capture 7 frames. However, the RX count from >> /proc/rtcan/devices is 10. >> >> If I send specific SDO requests to one of the node which have answered I >> don't capture a response but the RX count increases and rtcanrecv >> program captures the correct response. Only my application's read >> doesn't return. > Then there seem to be a problem with the read in you application. Can > you show use the related code? > > Wolfgang. Here is the main function of the rx thread. This will be executed every 1ms. void can_rx_run(rt_thread_data_t *rt_data) { can_thread_data_t *data = (can_thread_data_t *) rt_data->data; data->time++; static can_frame_t frame_buffer[RX_BUF_SZ]; static can_frame_t *frame = NULL; static can_bus_t *bus = NULL; int bytes = 1, ret, buf_i = 0; uint32_t bus_idx = 0; if ((data->time > 10)&& (data->time%2)) { bytes = 1; for (bus_idx = 0; bus_idx < data->n_buses; bus_idx++) { bus = &data->buses[bus_idx]; if(!bus->ready) continue; while (bytes > 0 && (buf_i<2)) { frame = &frame_buffer[buf_i]; memset(frame, 0, sizeof (*frame)); bytes = rt_dev_recv(bus->socket, frame, sizeof (*frame), MSG_DONTWAIT); if (bytes < 0) { if ((bytes != -ETIMEDOUT) && (bytes != -EAGAIN)) { rtlog(data->log, data->time, LOG_TAG_ERROR, "Connection ended unexpected ret %d errno %d", bytes); }else{ bytes = 1; } break; } else if (bytes == 0) { rtlog(data->log, data->time, LOG_TAG_ERROR, "CAN Bus Connection closed by peer"); break; } // move pointer forward for the next frame buf_i = (buf_i + 1) % RX_BUF_SZ; log_frame(data->log, data->time, frame, bus_idx); ret = check_frame_integrity(data->log, data->time, frame); if (ret) { rtlog(data->log, data->time, LOG_TAG_ERROR, "Frame didn't pass integrity check %d", ret); continue; } ret = process_frame(data->ipc_socket, frame, bus_idx); if (ret < 0) { rtlog(data->log, data->time, LOG_TAG_ERROR, "failed to accept RX CAN frame %d from Node %u", ret); } } } } } ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-11 11:55 ` Johannes Holtz @ 2019-02-11 12:40 ` Wolfgang Grandegger 2019-02-11 13:13 ` Johannes Holtz 0 siblings, 1 reply; 23+ messages in thread From: Wolfgang Grandegger @ 2019-02-11 12:40 UTC (permalink / raw) To: Johannes Holtz, xenomai Hello, Am 11.02.19 um 12:55 schrieb Johannes Holtz: > Am 11.02.19 um 12:26 schrieb Wolfgang Grandegger: >> Hello, >> >> Am 11.02.19 um 10:16 schrieb Johannes Holtz via Xenomai: >>> Hi, >>> >>> In my application i set up a RTCAN socket and a pair of rt-threads. One >>> to read and one to write. Writing works perfectly and I receive answers >>> in the initial phase of the program. >>> >>> In particular I send CANopen NMT messages out and receive the responses >>> from the other Nodes in the Network. >>> >>> 2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0: >>> CAN ID 0x000 FC 0x0 DLC 2 >>> 0 82 00 >>> 2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control Node >>> 0:8: >>> CAN ID 0x708 FC 0xe DLC 1 >>> 0 00 >>> 2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control Node >>> 0:9: >>> CAN ID 0x709 FC 0xe DLC 1 >>> 0 00 >>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >>> 0:3: >>> CAN ID 0x703 FC 0xe DLC 1 >>> 0 00 >>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >>> 0:4: >>> CAN ID 0x704 FC 0xe DLC 1 >>> 0 00 >>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >>> 0:5: >>> CAN ID 0x705 FC 0xe DLC 7 >>> 0 00 06 07 00 >>> 4 00 01 01 >>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0: >>> CAN ID 0x000 FC 0x0 DLC 3 >>> 0 07 00 00 >>> 2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1: >>> CAN ID 0x101 FC 0x2 DLC 0 >>> >>> As you can see, I capture 7 frames. However, the RX count from >>> /proc/rtcan/devices is 10. >>> >>> If I send specific SDO requests to one of the node which have answered I >>> don't capture a response but the RX count increases and rtcanrecv >>> program captures the correct response. Only my application's read >>> doesn't return. >> Then there seem to be a problem with the read in you application. Can >> you show use the related code? >> >> Wolfgang. > > Here is the main function of the rx thread. This will be executed every > 1ms. > > void can_rx_run(rt_thread_data_t *rt_data) { > can_thread_data_t *data = (can_thread_data_t *) rt_data->data; > data->time++; > static can_frame_t frame_buffer[RX_BUF_SZ]; > static can_frame_t *frame = NULL; > static can_bus_t *bus = NULL; > int bytes = 1, ret, buf_i = 0; > uint32_t bus_idx = 0; > if ((data->time > 10)&& (data->time%2)) { > bytes = 1; > for (bus_idx = 0; bus_idx < data->n_buses; bus_idx++) { > bus = &data->buses[bus_idx]; > if(!bus->ready) continue; > while (bytes > 0 && (buf_i<2)) { > frame = &frame_buffer[buf_i]; > memset(frame, 0, sizeof (*frame)); > bytes = rt_dev_recv(bus->socket, frame, sizeof > (*frame), MSG_DONTWAIT); > if (bytes < 0) { > if ((bytes != -ETIMEDOUT) && (bytes != -EAGAIN)) { > rtlog(data->log, data->time, LOG_TAG_ERROR, > "Connection ended unexpected ret %d errno %d", bytes); > }else{ > bytes = 1; > } > break; > } else if (bytes == 0) { > rtlog(data->log, data->time, LOG_TAG_ERROR, "CAN Bus > Connection closed by peer"); > break; > } > // move pointer forward for the next frame > buf_i = (buf_i + 1) % RX_BUF_SZ; > > log_frame(data->log, data->time, frame, bus_idx); > ret = check_frame_integrity(data->log, data->time, frame); > if (ret) { > rtlog(data->log, data->time, LOG_TAG_ERROR, > "Frame didn't pass integrity check %d", ret); > continue; > } > ret = process_frame(data->ipc_socket, frame, bus_idx); > if (ret < 0) { > rtlog(data->log, data->time, LOG_TAG_ERROR, > "failed to accept RX CAN frame %d from Node %u", > ret); > } > } > } > } > } And the code setting up the socket? Wolfgang. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-11 12:40 ` Wolfgang Grandegger @ 2019-02-11 13:13 ` Johannes Holtz 2019-02-11 15:06 ` Wolfgang Grandegger 0 siblings, 1 reply; 23+ messages in thread From: Johannes Holtz @ 2019-02-11 13:13 UTC (permalink / raw) To: Wolfgang Grandegger, xenomai Am 11.02.19 um 13:40 schrieb Wolfgang Grandegger: > Hello, > > Am 11.02.19 um 12:55 schrieb Johannes Holtz: >> Am 11.02.19 um 12:26 schrieb Wolfgang Grandegger: >>> Hello, >>> >>> Am 11.02.19 um 10:16 schrieb Johannes Holtz via Xenomai: >>>> Hi, >>>> >>>> In my application i set up a RTCAN socket and a pair of rt-threads. One >>>> to read and one to write. Writing works perfectly and I receive answers >>>> in the initial phase of the program. >>>> >>>> In particular I send CANopen NMT messages out and receive the responses >>>> from the other Nodes in the Network. >>>> >>>> 2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0: >>>> CAN ID 0x000 FC 0x0 DLC 2 >>>> 0 82 00 >>>> 2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control Node >>>> 0:8: >>>> CAN ID 0x708 FC 0xe DLC 1 >>>> 0 00 >>>> 2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control Node >>>> 0:9: >>>> CAN ID 0x709 FC 0xe DLC 1 >>>> 0 00 >>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >>>> 0:3: >>>> CAN ID 0x703 FC 0xe DLC 1 >>>> 0 00 >>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >>>> 0:4: >>>> CAN ID 0x704 FC 0xe DLC 1 >>>> 0 00 >>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control Node >>>> 0:5: >>>> CAN ID 0x705 FC 0xe DLC 7 >>>> 0 00 06 07 00 >>>> 4 00 01 01 >>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0: >>>> CAN ID 0x000 FC 0x0 DLC 3 >>>> 0 07 00 00 >>>> 2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1: >>>> CAN ID 0x101 FC 0x2 DLC 0 >>>> >>>> As you can see, I capture 7 frames. However, the RX count from >>>> /proc/rtcan/devices is 10. >>>> >>>> If I send specific SDO requests to one of the node which have answered I >>>> don't capture a response but the RX count increases and rtcanrecv >>>> program captures the correct response. Only my application's read >>>> doesn't return. >>> Then there seem to be a problem with the read in you application. Can >>> you show use the related code? >>> >>> Wolfgang. >> Here is the main function of the rx thread. This will be executed every >> 1ms. >> >> void can_rx_run(rt_thread_data_t *rt_data) { >> can_thread_data_t *data = (can_thread_data_t *) rt_data->data; >> data->time++; >> static can_frame_t frame_buffer[RX_BUF_SZ]; >> static can_frame_t *frame = NULL; >> static can_bus_t *bus = NULL; >> int bytes = 1, ret, buf_i = 0; >> uint32_t bus_idx = 0; >> if ((data->time > 10)&& (data->time%2)) { >> bytes = 1; >> for (bus_idx = 0; bus_idx < data->n_buses; bus_idx++) { >> bus = &data->buses[bus_idx]; >> if(!bus->ready) continue; >> while (bytes > 0 && (buf_i<2)) { >> frame = &frame_buffer[buf_i]; >> memset(frame, 0, sizeof (*frame)); >> bytes = rt_dev_recv(bus->socket, frame, sizeof >> (*frame), MSG_DONTWAIT); >> if (bytes < 0) { >> if ((bytes != -ETIMEDOUT) && (bytes != -EAGAIN)) { >> rtlog(data->log, data->time, LOG_TAG_ERROR, >> "Connection ended unexpected ret %d errno %d", bytes); >> }else{ >> bytes = 1; >> } >> break; >> } else if (bytes == 0) { >> rtlog(data->log, data->time, LOG_TAG_ERROR, "CAN Bus >> Connection closed by peer"); >> break; >> } >> // move pointer forward for the next frame >> buf_i = (buf_i + 1) % RX_BUF_SZ; >> >> log_frame(data->log, data->time, frame, bus_idx); >> ret = check_frame_integrity(data->log, data->time, frame); >> if (ret) { >> rtlog(data->log, data->time, LOG_TAG_ERROR, >> "Frame didn't pass integrity check %d", ret); >> continue; >> } >> ret = process_frame(data->ipc_socket, frame, bus_idx); >> if (ret < 0) { >> rtlog(data->log, data->time, LOG_TAG_ERROR, >> "failed to accept RX CAN frame %d from Node %u", >> ret); >> } >> } >> } >> } >> } > And the code setting up the socket? > > Wolfgang. static int set_bus_mode(can_bus_t* bus, int mode) { uint32_t *new_mode = (can_mode_t *) &bus->device.ifr_ifru; *new_mode = mode; int res = rt_dev_ioctl(bus->socket, SIOCSCANMODE, &bus->device); if(res) { return CAN_BUS_INIT_ERROR_MODESET; } return 0; } void bus_shutdown (can_bus_t *bus) { set_bus_mode(bus, CAN_MODE_STOP); if (bus->socket < 0) return; rt_dev_close (bus->socket); bus->socket = -1; printf("shutdown bus %d\n", bus->bus_index); return; } int bus_init (can_bus_t *bus, const int BUS, const uint32_t BAUDRATE, const int64_t TIMEOUT_SEND, const int64_t TIMEOUT_RECV) { struct sockaddr_can addr; bus->bus_index = BUS; int res; static unsigned int err_mask = CAN_ERR_MASK; /* static unsigned int err_mask = CAN_ERR_CRTL // Controller Problems (see data[1]) | CAN_ERR_BUSOFF // Bus Off | CAN_ERR_RESTARTED // Controller Restarted | CAN_ERR_TX_TIMEOUT // TX timeout (netdevice driver). | CAN_ERR_LOSTARB // Lost arbitration (see data[0]). | CAN_ERR_PROT // Protocol violations (see data[2], data[3]). | CAN_ERR_TRX // Transceiver status (see data[4]). | CAN_ERR_ACK // Received no ACK on transmission. //| CAN_ERR_BUSERROR // Bus error (may flood!). //| CAN_ERR_MASK // All error flags. ; */ // create socket bus->socket = rt_dev_socket (PF_CAN, SOCK_RAW, CAN_RAW); if (bus->socket < 0) { printf("%s > failed to get socket %d\n",__func__, bus->socket); return CAN_BUS_INIT_ERROR_RT_DEV_SOCKET; } // device index snprintf (bus->device.ifr_ifrn.ifrn_name, IF_NAMESIZE, "rtcan%d", bus->bus_index); res = rt_dev_ioctl (bus->socket, SIOCGIFINDEX, &bus->device); if (res) { printf("%s > failed to set IF name %s error %d\n", __func__, bus->device.ifr_ifrn.ifrn_name, res); bus_shutdown (bus); return CAN_BUS_INIT_ERROR_SIOCGIFINDEX; } // receive CAN error frames (also pseudo frames) res = rt_dev_setsockopt (bus->socket, SOL_CAN_RAW, CAN_RAW_ERR_FILTER, &err_mask, sizeof (err_mask)); if (res) { bus_shutdown (bus); return CAN_BUS_INIT_ERROR_SETSOCKOPT; } // bind recv addr.can_family = AF_CAN; addr.can_ifindex = bus->device.ifr_ifindex; res = rt_dev_bind (bus->socket, (struct sockaddr *) &addr, sizeof (addr)); if (res < 0) { printf("%s > rt_dev_bind failed with %d\n", __func__, res); bus_shutdown (bus); return CAN_BUS_INIT_ERROR_BIND; } // baudrate can_baudrate_t *baudrate = (can_baudrate_t *) &bus->device.ifr_ifru; *baudrate = BAUDRATE; res = rt_dev_ioctl (bus->socket, SIOCSCANBAUDRATE, &bus->device); if (res) { bus_shutdown (bus); return CAN_BUS_INIT_ERROR_BAUDRATE; } // timeout send if (TIMEOUT_SEND) { res = rt_dev_ioctl (bus->socket, RTCAN_RTIOC_SND_TIMEOUT, &TIMEOUT_SEND); if (res) { bus_shutdown (bus); return CAN_BUS_INIT_ERROR_TIMEOUT_SEND; } } // timeout recv if (TIMEOUT_RECV) { res = rt_dev_ioctl (bus->socket, RTCAN_RTIOC_RCV_TIMEOUT, &TIMEOUT_RECV); if (res) { bus_shutdown (bus); return CAN_BUS_INIT_ERROR_TIMEOUT_RECV; } } bus->ready = true; return set_bus_mode(bus, CAN_MODE_START); } ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-11 13:13 ` Johannes Holtz @ 2019-02-11 15:06 ` Wolfgang Grandegger 2019-02-11 15:12 ` Johannes Holtz 0 siblings, 1 reply; 23+ messages in thread From: Wolfgang Grandegger @ 2019-02-11 15:06 UTC (permalink / raw) To: Johannes Holtz, xenomai Hello, at a first glance, your code looks good, but you are using the native api.. more inline... Am 11.02.19 um 14:13 schrieb Johannes Holtz: > Am 11.02.19 um 13:40 schrieb Wolfgang Grandegger: >> Hello, >> >> Am 11.02.19 um 12:55 schrieb Johannes Holtz: >>> Am 11.02.19 um 12:26 schrieb Wolfgang Grandegger: >>>> Hello, >>>> >>>> Am 11.02.19 um 10:16 schrieb Johannes Holtz via Xenomai: >>>>> Hi, >>>>> >>>>> In my application i set up a RTCAN socket and a pair of rt-threads. >>>>> One >>>>> to read and one to write. Writing works perfectly and I receive >>>>> answers >>>>> in the initial phase of the program. >>>>> >>>>> In particular I send CANopen NMT messages out and receive the >>>>> responses >>>>> from the other Nodes in the Network. >>>>> >>>>> 2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0: >>>>> CAN ID 0x000 FC 0x0 DLC 2 >>>>> 0 82 00 >>>>> 2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control >>>>> Node >>>>> 0:8: >>>>> CAN ID 0x708 FC 0xe DLC 1 >>>>> 0 00 >>>>> 2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control >>>>> Node >>>>> 0:9: >>>>> CAN ID 0x709 FC 0xe DLC 1 >>>>> 0 00 >>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>> Node >>>>> 0:3: >>>>> CAN ID 0x703 FC 0xe DLC 1 >>>>> 0 00 >>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>> Node >>>>> 0:4: >>>>> CAN ID 0x704 FC 0xe DLC 1 >>>>> 0 00 >>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>> Node >>>>> 0:5: >>>>> CAN ID 0x705 FC 0xe DLC 7 >>>>> 0 00 06 07 00 >>>>> 4 00 01 01 >>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0: >>>>> CAN ID 0x000 FC 0x0 DLC 3 >>>>> 0 07 00 00 >>>>> 2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1: >>>>> CAN ID 0x101 FC 0x2 DLC 0 >>>>> >>>>> As you can see, I capture 7 frames. However, the RX count from >>>>> /proc/rtcan/devices is 10. >>>>> >>>>> If I send specific SDO requests to one of the node which have >>>>> answered I >>>>> don't capture a response but the RX count increases and rtcanrecv >>>>> program captures the correct response. Only my application's read >>>>> doesn't return. What do you mean with "doesn't return". rt_can_recv(MSG_DONTWAIT) should not block. What does it return? >>>> Then there seem to be a problem with the read in you application. Can >>>> you show use the related code? >>>> >>>> Wolfgang. >>> Here is the main function of the rx thread. This will be executed every >>> 1ms. >>> >>> void can_rx_run(rt_thread_data_t *rt_data) { >>> can_thread_data_t *data = (can_thread_data_t *) rt_data->data; >>> data->time++; >>> static can_frame_t frame_buffer[RX_BUF_SZ]; >>> static can_frame_t *frame = NULL; >>> static can_bus_t *bus = NULL; >>> int bytes = 1, ret, buf_i = 0; >>> uint32_t bus_idx = 0; >>> if ((data->time > 10)&& (data->time%2)) { >>> bytes = 1; >>> for (bus_idx = 0; bus_idx < data->n_buses; bus_idx++) { >>> bus = &data->buses[bus_idx]; >>> if(!bus->ready) continue; >>> while (bytes > 0 && (buf_i<2)) { >>> frame = &frame_buffer[buf_i]; >>> memset(frame, 0, sizeof (*frame)); >>> bytes = rt_dev_recv(bus->socket, frame, sizeof >>> (*frame), MSG_DONTWAIT); >>> if (bytes < 0) { >>> if ((bytes != -ETIMEDOUT) && (bytes != -EAGAIN)) { >>> rtlog(data->log, data->time, LOG_TAG_ERROR, >>> "Connection ended unexpected ret %d errno %d", bytes); >>> }else{ >>> bytes = 1; >>> } >>> break; >>> } else if (bytes == 0) { >>> rtlog(data->log, data->time, LOG_TAG_ERROR, "CAN >>> Bus >>> Connection closed by peer"); >>> break; >>> } >>> // move pointer forward for the next frame >>> buf_i = (buf_i + 1) % RX_BUF_SZ; >>> >>> log_frame(data->log, data->time, frame, bus_idx); >>> ret = check_frame_integrity(data->log, data->time, >>> frame); >>> if (ret) { >>> rtlog(data->log, data->time, LOG_TAG_ERROR, >>> "Frame didn't pass integrity check %d", ret); >>> continue; >>> } >>> ret = process_frame(data->ipc_socket, frame, bus_idx); >>> if (ret < 0) { >>> rtlog(data->log, data->time, LOG_TAG_ERROR, >>> "failed to accept RX CAN frame %d from >>> Node %u", >>> ret); >>> } >>> } >>> } >>> } >>> } >> And the code setting up the socket? >> >> Wolfgang. > > static int set_bus_mode(can_bus_t* bus, int mode) { > uint32_t *new_mode = (can_mode_t *) &bus->device.ifr_ifru; > *new_mode = mode; > int res = rt_dev_ioctl(bus->socket, SIOCSCANMODE, &bus->device); > if(res) { > return CAN_BUS_INIT_ERROR_MODESET; > } > return 0; > } > > void bus_shutdown (can_bus_t *bus) { > > set_bus_mode(bus, CAN_MODE_STOP); > > if (bus->socket < 0) > return; > > rt_dev_close (bus->socket); > bus->socket = -1; > > printf("shutdown bus %d\n", bus->bus_index); > return; > } > > int bus_init (can_bus_t *bus, const int BUS, const uint32_t BAUDRATE, > const int64_t TIMEOUT_SEND, const int64_t TIMEOUT_RECV) { > struct sockaddr_can addr; > bus->bus_index = BUS; > int res; > static unsigned int err_mask = CAN_ERR_MASK; > /* > static unsigned int err_mask = CAN_ERR_CRTL // Controller > Problems (see data[1]) > | CAN_ERR_BUSOFF // Bus Off > | CAN_ERR_RESTARTED // > Controller Restarted > | CAN_ERR_TX_TIMEOUT // TX > timeout (netdevice driver). > | CAN_ERR_LOSTARB // Lost > arbitration (see data[0]). > | CAN_ERR_PROT // Protocol > violations (see data[2], data[3]). > | CAN_ERR_TRX // Transceiver > status (see data[4]). > | CAN_ERR_ACK // Received no > ACK on transmission. > //| CAN_ERR_BUSERROR // Bus > error (may flood!). > //| CAN_ERR_MASK // All > error flags. > ; > */ > // create socket > bus->socket = rt_dev_socket (PF_CAN, SOCK_RAW, CAN_RAW); > if (bus->socket < 0) { > printf("%s > failed to get socket %d\n",__func__, bus->socket); > return CAN_BUS_INIT_ERROR_RT_DEV_SOCKET; > } > > // device index > snprintf (bus->device.ifr_ifrn.ifrn_name, IF_NAMESIZE, "rtcan%d", > bus->bus_index); > res = rt_dev_ioctl (bus->socket, SIOCGIFINDEX, &bus->device); > if (res) { > printf("%s > failed to set IF name %s error %d\n", __func__, > bus->device.ifr_ifrn.ifrn_name, res); > bus_shutdown (bus); > return CAN_BUS_INIT_ERROR_SIOCGIFINDEX; > } > > // receive CAN error frames (also pseudo frames) > res = rt_dev_setsockopt (bus->socket, SOL_CAN_RAW, > CAN_RAW_ERR_FILTER, &err_mask, sizeof (err_mask)); > if (res) { > bus_shutdown (bus); > return CAN_BUS_INIT_ERROR_SETSOCKOPT; > } > > // bind recv > addr.can_family = AF_CAN; > addr.can_ifindex = bus->device.ifr_ifindex; > res = rt_dev_bind (bus->socket, (struct sockaddr *) &addr, sizeof > (addr)); > if (res < 0) { > printf("%s > rt_dev_bind failed with %d\n", __func__, res); > bus_shutdown (bus); > return CAN_BUS_INIT_ERROR_BIND; > } > > // baudrate > can_baudrate_t *baudrate = (can_baudrate_t *) &bus->device.ifr_ifru; > *baudrate = BAUDRATE; > res = rt_dev_ioctl (bus->socket, SIOCSCANBAUDRATE, &bus->device); > if (res) { > bus_shutdown (bus); > return CAN_BUS_INIT_ERROR_BAUDRATE; > } > > // timeout send > if (TIMEOUT_SEND) { > res = rt_dev_ioctl (bus->socket, RTCAN_RTIOC_SND_TIMEOUT, > &TIMEOUT_SEND); > if (res) { > bus_shutdown (bus); > return CAN_BUS_INIT_ERROR_TIMEOUT_SEND; > } > } > > // timeout recv > if (TIMEOUT_RECV) { > res = rt_dev_ioctl (bus->socket, RTCAN_RTIOC_RCV_TIMEOUT, > &TIMEOUT_RECV); > if (res) { > bus_shutdown (bus); > return CAN_BUS_INIT_ERROR_TIMEOUT_RECV; > } > } > > bus->ready = true; > return set_bus_mode(bus, CAN_MODE_START); > } > > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-11 15:06 ` Wolfgang Grandegger @ 2019-02-11 15:12 ` Johannes Holtz 2019-02-11 16:46 ` Wolfgang Grandegger 0 siblings, 1 reply; 23+ messages in thread From: Johannes Holtz @ 2019-02-11 15:12 UTC (permalink / raw) To: Wolfgang Grandegger, xenomai Am 11.02.19 um 16:07 schrieb Wolfgang Grandegger: > Hello, > > at a first glance, your code looks good, but you are using the native > api.. more inline... > > Am 11.02.19 um 14:13 schrieb Johannes Holtz: >> Am 11.02.19 um 13:40 schrieb Wolfgang Grandegger: >>> Hello, >>> >>> Am 11.02.19 um 12:55 schrieb Johannes Holtz: >>>> Am 11.02.19 um 12:26 schrieb Wolfgang Grandegger: >>>>> Hello, >>>>> >>>>> Am 11.02.19 um 10:16 schrieb Johannes Holtz via Xenomai: >>>>>> Hi, >>>>>> >>>>>> In my application i set up a RTCAN socket and a pair of rt-threads. >>>>>> One >>>>>> to read and one to write. Writing works perfectly and I receive >>>>>> answers >>>>>> in the initial phase of the program. >>>>>> >>>>>> In particular I send CANopen NMT messages out and receive the >>>>>> responses >>>>>> from the other Nodes in the Network. >>>>>> >>>>>> 2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0: >>>>>> CAN ID 0x000 FC 0x0 DLC 2 >>>>>> 0 82 00 >>>>>> 2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control >>>>>> Node >>>>>> 0:8: >>>>>> CAN ID 0x708 FC 0xe DLC 1 >>>>>> 0 00 >>>>>> 2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control >>>>>> Node >>>>>> 0:9: >>>>>> CAN ID 0x709 FC 0xe DLC 1 >>>>>> 0 00 >>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>>> Node >>>>>> 0:3: >>>>>> CAN ID 0x703 FC 0xe DLC 1 >>>>>> 0 00 >>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>>> Node >>>>>> 0:4: >>>>>> CAN ID 0x704 FC 0xe DLC 1 >>>>>> 0 00 >>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>>> Node >>>>>> 0:5: >>>>>> CAN ID 0x705 FC 0xe DLC 7 >>>>>> 0 00 06 07 00 >>>>>> 4 00 01 01 >>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0: >>>>>> CAN ID 0x000 FC 0x0 DLC 3 >>>>>> 0 07 00 00 >>>>>> 2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1: >>>>>> CAN ID 0x101 FC 0x2 DLC 0 >>>>>> >>>>>> As you can see, I capture 7 frames. However, the RX count from >>>>>> /proc/rtcan/devices is 10. >>>>>> >>>>>> If I send specific SDO requests to one of the node which have >>>>>> answered I >>>>>> don't capture a response but the RX count increases and rtcanrecv >>>>>> program captures the correct response. Only my application's read >>>>>> doesn't return. > What do you mean with "doesn't return". rt_can_recv(MSG_DONTWAIT) should > not block. What does it return? It only returns EAGAIN like there is nothing to read. > >>>>> Then there seem to be a problem with the read in you application. Can >>>>> you show use the related code? >>>>> >>>>> Wolfgang. >>>> Here is the main function of the rx thread. This will be executed every >>>> 1ms. >>>> >>>> void can_rx_run(rt_thread_data_t *rt_data) { >>>> can_thread_data_t *data = (can_thread_data_t *) rt_data->data; >>>> data->time++; >>>> static can_frame_t frame_buffer[RX_BUF_SZ]; >>>> static can_frame_t *frame = NULL; >>>> static can_bus_t *bus = NULL; >>>> int bytes = 1, ret, buf_i = 0; >>>> uint32_t bus_idx = 0; >>>> if ((data->time > 10)&& (data->time%2)) { >>>> bytes = 1; >>>> for (bus_idx = 0; bus_idx < data->n_buses; bus_idx++) { >>>> bus = &data->buses[bus_idx]; >>>> if(!bus->ready) continue; >>>> while (bytes > 0 && (buf_i<2)) { >>>> frame = &frame_buffer[buf_i]; >>>> memset(frame, 0, sizeof (*frame)); >>>> bytes = rt_dev_recv(bus->socket, frame, sizeof >>>> (*frame), MSG_DONTWAIT); >>>> if (bytes < 0) { >>>> if ((bytes != -ETIMEDOUT) && (bytes != -EAGAIN)) { >>>> rtlog(data->log, data->time, LOG_TAG_ERROR, >>>> "Connection ended unexpected ret %d errno %d", bytes); >>>> }else{ >>>> bytes = 1; >>>> } >>>> break; >>>> } else if (bytes == 0) { >>>> rtlog(data->log, data->time, LOG_TAG_ERROR, "CAN >>>> Bus >>>> Connection closed by peer"); >>>> break; >>>> } >>>> // move pointer forward for the next frame >>>> buf_i = (buf_i + 1) % RX_BUF_SZ; >>>> >>>> log_frame(data->log, data->time, frame, bus_idx); >>>> ret = check_frame_integrity(data->log, data->time, >>>> frame); >>>> if (ret) { >>>> rtlog(data->log, data->time, LOG_TAG_ERROR, >>>> "Frame didn't pass integrity check %d", ret); >>>> continue; >>>> } >>>> ret = process_frame(data->ipc_socket, frame, bus_idx); >>>> if (ret < 0) { >>>> rtlog(data->log, data->time, LOG_TAG_ERROR, >>>> "failed to accept RX CAN frame %d from >>>> Node %u", >>>> ret); >>>> } >>>> } >>>> } >>>> } >>>> } >>> And the code setting up the socket? >>> >>> Wolfgang. >> static int set_bus_mode(can_bus_t* bus, int mode) { >> uint32_t *new_mode = (can_mode_t *) &bus->device.ifr_ifru; >> *new_mode = mode; >> int res = rt_dev_ioctl(bus->socket, SIOCSCANMODE, &bus->device); >> if(res) { >> return CAN_BUS_INIT_ERROR_MODESET; >> } >> return 0; >> } >> >> void bus_shutdown (can_bus_t *bus) { >> >> set_bus_mode(bus, CAN_MODE_STOP); >> >> if (bus->socket < 0) >> return; >> >> rt_dev_close (bus->socket); >> bus->socket = -1; >> >> printf("shutdown bus %d\n", bus->bus_index); >> return; >> } >> >> int bus_init (can_bus_t *bus, const int BUS, const uint32_t BAUDRATE, >> const int64_t TIMEOUT_SEND, const int64_t TIMEOUT_RECV) { >> struct sockaddr_can addr; >> bus->bus_index = BUS; >> int res; >> static unsigned int err_mask = CAN_ERR_MASK; >> /* >> static unsigned int err_mask = CAN_ERR_CRTL // Controller >> Problems (see data[1]) >> | CAN_ERR_BUSOFF // Bus Off >> | CAN_ERR_RESTARTED // >> Controller Restarted >> | CAN_ERR_TX_TIMEOUT // TX >> timeout (netdevice driver). >> | CAN_ERR_LOSTARB // Lost >> arbitration (see data[0]). >> | CAN_ERR_PROT // Protocol >> violations (see data[2], data[3]). >> | CAN_ERR_TRX // Transceiver >> status (see data[4]). >> | CAN_ERR_ACK // Received no >> ACK on transmission. >> //| CAN_ERR_BUSERROR // Bus >> error (may flood!). >> //| CAN_ERR_MASK // All >> error flags. >> ; >> */ >> // create socket >> bus->socket = rt_dev_socket (PF_CAN, SOCK_RAW, CAN_RAW); >> if (bus->socket < 0) { >> printf("%s > failed to get socket %d\n",__func__, bus->socket); >> return CAN_BUS_INIT_ERROR_RT_DEV_SOCKET; >> } >> >> // device index >> snprintf (bus->device.ifr_ifrn.ifrn_name, IF_NAMESIZE, "rtcan%d", >> bus->bus_index); >> res = rt_dev_ioctl (bus->socket, SIOCGIFINDEX, &bus->device); >> if (res) { >> printf("%s > failed to set IF name %s error %d\n", __func__, >> bus->device.ifr_ifrn.ifrn_name, res); >> bus_shutdown (bus); >> return CAN_BUS_INIT_ERROR_SIOCGIFINDEX; >> } >> >> // receive CAN error frames (also pseudo frames) >> res = rt_dev_setsockopt (bus->socket, SOL_CAN_RAW, >> CAN_RAW_ERR_FILTER, &err_mask, sizeof (err_mask)); >> if (res) { >> bus_shutdown (bus); >> return CAN_BUS_INIT_ERROR_SETSOCKOPT; >> } >> >> // bind recv >> addr.can_family = AF_CAN; >> addr.can_ifindex = bus->device.ifr_ifindex; >> res = rt_dev_bind (bus->socket, (struct sockaddr *) &addr, sizeof >> (addr)); >> if (res < 0) { >> printf("%s > rt_dev_bind failed with %d\n", __func__, res); >> bus_shutdown (bus); >> return CAN_BUS_INIT_ERROR_BIND; >> } >> >> // baudrate >> can_baudrate_t *baudrate = (can_baudrate_t *) &bus->device.ifr_ifru; >> *baudrate = BAUDRATE; >> res = rt_dev_ioctl (bus->socket, SIOCSCANBAUDRATE, &bus->device); >> if (res) { >> bus_shutdown (bus); >> return CAN_BUS_INIT_ERROR_BAUDRATE; >> } >> >> // timeout send >> if (TIMEOUT_SEND) { >> res = rt_dev_ioctl (bus->socket, RTCAN_RTIOC_SND_TIMEOUT, >> &TIMEOUT_SEND); >> if (res) { >> bus_shutdown (bus); >> return CAN_BUS_INIT_ERROR_TIMEOUT_SEND; >> } >> } >> >> // timeout recv >> if (TIMEOUT_RECV) { >> res = rt_dev_ioctl (bus->socket, RTCAN_RTIOC_RCV_TIMEOUT, >> &TIMEOUT_RECV); >> if (res) { >> bus_shutdown (bus); >> return CAN_BUS_INIT_ERROR_TIMEOUT_RECV; >> } >> } >> >> bus->ready = true; >> return set_bus_mode(bus, CAN_MODE_START); >> } >> >> >> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-11 15:12 ` Johannes Holtz @ 2019-02-11 16:46 ` Wolfgang Grandegger 2019-02-12 10:42 ` Johannes Holtz 0 siblings, 1 reply; 23+ messages in thread From: Wolfgang Grandegger @ 2019-02-11 16:46 UTC (permalink / raw) To: Johannes Holtz, xenomai Hello, Am 11.02.19 um 16:12 schrieb Johannes Holtz: > Am 11.02.19 um 16:07 schrieb Wolfgang Grandegger: >> Hello, >> >> at a first glance, your code looks good, but you are using the native >> api.. more inline... >> >> Am 11.02.19 um 14:13 schrieb Johannes Holtz: >>> Am 11.02.19 um 13:40 schrieb Wolfgang Grandegger: >>>> Hello, >>>> >>>> Am 11.02.19 um 12:55 schrieb Johannes Holtz: >>>>> Am 11.02.19 um 12:26 schrieb Wolfgang Grandegger: >>>>>> Hello, >>>>>> >>>>>> Am 11.02.19 um 10:16 schrieb Johannes Holtz via Xenomai: >>>>>>> Hi, >>>>>>> >>>>>>> In my application i set up a RTCAN socket and a pair of rt-threads. >>>>>>> One >>>>>>> to read and one to write. Writing works perfectly and I receive >>>>>>> answers >>>>>>> in the initial phase of the program. >>>>>>> >>>>>>> In particular I send CANopen NMT messages out and receive the >>>>>>> responses >>>>>>> from the other Nodes in the Network. >>>>>>> >>>>>>> 2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0: >>>>>>> CAN ID 0x000 FC 0x0 DLC 2 >>>>>>> 0 82 00 >>>>>>> 2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control >>>>>>> Node >>>>>>> 0:8: >>>>>>> CAN ID 0x708 FC 0xe DLC 1 >>>>>>> 0 00 >>>>>>> 2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control >>>>>>> Node >>>>>>> 0:9: >>>>>>> CAN ID 0x709 FC 0xe DLC 1 >>>>>>> 0 00 >>>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>>>> Node >>>>>>> 0:3: >>>>>>> CAN ID 0x703 FC 0xe DLC 1 >>>>>>> 0 00 >>>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>>>> Node >>>>>>> 0:4: >>>>>>> CAN ID 0x704 FC 0xe DLC 1 >>>>>>> 0 00 >>>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>>>> Node >>>>>>> 0:5: >>>>>>> CAN ID 0x705 FC 0xe DLC 7 >>>>>>> 0 00 06 07 00 >>>>>>> 4 00 01 01 >>>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0: >>>>>>> CAN ID 0x000 FC 0x0 DLC 3 >>>>>>> 0 07 00 00 >>>>>>> 2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1: >>>>>>> CAN ID 0x101 FC 0x2 DLC 0 >>>>>>> >>>>>>> As you can see, I capture 7 frames. However, the RX count from >>>>>>> /proc/rtcan/devices is 10. >>>>>>> >>>>>>> If I send specific SDO requests to one of the node which have >>>>>>> answered I >>>>>>> don't capture a response but the RX count increases and rtcanrecv >>>>>>> program captures the correct response. Only my application's read >>>>>>> doesn't return. >> What do you mean with "doesn't return". rt_can_recv(MSG_DONTWAIT) should >> not block. What does it return? > It only returns EAGAIN like there is nothing to read. UI suggest to write a simple test program to demonstrate the issue. It should just open the socket and trying to receive messages... just the necessary stuff. First with a blocking recv() and then non-blocking. What hardware and software are you using (arch, board, linux, xenomai)? Wolfgang. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-11 16:46 ` Wolfgang Grandegger @ 2019-02-12 10:42 ` Johannes Holtz 2019-02-12 11:24 ` Wolfgang Grandegger 0 siblings, 1 reply; 23+ messages in thread From: Johannes Holtz @ 2019-02-12 10:42 UTC (permalink / raw) To: Wolfgang Grandegger, xenomai Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: > Hello, > > Am 11.02.19 um 16:12 schrieb Johannes Holtz: >> Am 11.02.19 um 16:07 schrieb Wolfgang Grandegger: >>> Hello, >>> >>> at a first glance, your code looks good, but you are using the native >>> api.. more inline... >>> >>> Am 11.02.19 um 14:13 schrieb Johannes Holtz: >>>> Am 11.02.19 um 13:40 schrieb Wolfgang Grandegger: >>>>> Hello, >>>>> >>>>> Am 11.02.19 um 12:55 schrieb Johannes Holtz: >>>>>> Am 11.02.19 um 12:26 schrieb Wolfgang Grandegger: >>>>>>> Hello, >>>>>>> >>>>>>> Am 11.02.19 um 10:16 schrieb Johannes Holtz via Xenomai: >>>>>>>> Hi, >>>>>>>> >>>>>>>> In my application i set up a RTCAN socket and a pair of rt-threads. >>>>>>>> One >>>>>>>> to read and one to write. Writing works perfectly and I receive >>>>>>>> answers >>>>>>>> in the initial phase of the program. >>>>>>>> >>>>>>>> In particular I send CANopen NMT messages out and receive the >>>>>>>> responses >>>>>>>> from the other Nodes in the Network. >>>>>>>> >>>>>>>> 2019-02-11 09:52:13.309[ 500][ CAN TX] > NMT Node 0:0: >>>>>>>> CAN ID 0x000 FC 0x0 DLC 2 >>>>>>>> 0 82 00 >>>>>>>> 2019-02-11 09:52:13.310[ 503][ CAN RX] > NMT Error Control >>>>>>>> Node >>>>>>>> 0:8: >>>>>>>> CAN ID 0x708 FC 0xe DLC 1 >>>>>>>> 0 00 >>>>>>>> 2019-02-11 09:52:13.311[ 503][ CAN RX] > NMT Error Control >>>>>>>> Node >>>>>>>> 0:9: >>>>>>>> CAN ID 0x709 FC 0xe DLC 1 >>>>>>>> 0 00 >>>>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>>>>> Node >>>>>>>> 0:3: >>>>>>>> CAN ID 0x703 FC 0xe DLC 1 >>>>>>>> 0 00 >>>>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>>>>> Node >>>>>>>> 0:4: >>>>>>>> CAN ID 0x704 FC 0xe DLC 1 >>>>>>>> 0 00 >>>>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Error Control >>>>>>>> Node >>>>>>>> 0:5: >>>>>>>> CAN ID 0x705 FC 0xe DLC 7 >>>>>>>> 0 00 06 07 00 >>>>>>>> 4 00 01 01 >>>>>>>> 2019-02-11 09:52:13.317[ 509][ CAN RX] > NMT Node 0:0: >>>>>>>> CAN ID 0x000 FC 0x0 DLC 3 >>>>>>>> 0 07 00 00 >>>>>>>> 2019-02-11 09:52:13.326[ 519][ CAN RX] > TIME Node 0:1: >>>>>>>> CAN ID 0x101 FC 0x2 DLC 0 >>>>>>>> >>>>>>>> As you can see, I capture 7 frames. However, the RX count from >>>>>>>> /proc/rtcan/devices is 10. >>>>>>>> >>>>>>>> If I send specific SDO requests to one of the node which have >>>>>>>> answered I >>>>>>>> don't capture a response but the RX count increases and rtcanrecv >>>>>>>> program captures the correct response. Only my application's read >>>>>>>> doesn't return. >>> What do you mean with "doesn't return". rt_can_recv(MSG_DONTWAIT) should >>> not block. What does it return? >> It only returns EAGAIN like there is nothing to read. > UI suggest to write a simple test program to demonstrate the issue. It > should just open the socket and trying to receive messages... just the > necessary stuff. First with a blocking recv() and then non-blocking. > > What hardware and software are you using (arch, board, linux, xenomai)? > > Wolfgang. The source code is attached: compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt -lnative can frames sent by rtcansend Test 1: blocking: ID:0 DLC:2hex: 81 00 <-- NMT request ID:709 DLC:1hex: 00 <-- answer node #9 ID:708 DLC:1hex: 00 <-- answer node #8 ID:703 DLC:1hex: 00 <-- answer node #3 ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 ID:70400 DLC:1hex: 01 ID:70600 DLC:1hex: 01 ID:70100 DLC:1hex: 01 ID:70200 DLC:1hex: 01 ID:1010000 DLC:1hex: 08 ID:53220 DLC:124 out of bounds. abort. Test 2: non blocking: ID:0 DLC:2hex: 81 00 <-- NMT request ID:709 DLC:1hex: 00 <-- answer node #9 ID:708 DLC:1hex: 00 <-- answer node #8 ID:703 DLC:1hex: 00 <-- answer node #3 ID:705 DLC:0hex: <-- same issue DLC is 0 ID:70600 DLC:1hex: 01 ID:70400 DLC:1hex: 01 ID:70200 DLC:1hex: 01 ID:70100 DLC:1hex: 01 ID:1010000 DLC:1hex: 08 ID:53220 DLC:124 out of bounds. abort. Also, I found another possible error source and I don't know if this error picture would corresponds to this. However, While reviewing all settings, I noticed that I made a mistake with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have been asleep when writing this. I'm going to rebuild this module. -------------- next part -------------- A non-text attachment was scrubbed... Name: can_recv.c Type: text/x-csrc Size: 6516 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20190212/3a4ad2e4/attachment.c> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 10:42 ` Johannes Holtz @ 2019-02-12 11:24 ` Wolfgang Grandegger 2019-02-12 11:35 ` Johannes Holtz 2019-02-12 14:38 ` Johannes Holtz 0 siblings, 2 replies; 23+ messages in thread From: Wolfgang Grandegger @ 2019-02-12 11:24 UTC (permalink / raw) To: Johannes Holtz, xenomai Hello, Am 12.02.19 um 11:42 schrieb Johannes Holtz: > Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: ... snip ... >> UI suggest to write a simple test program to demonstrate the issue. It >> should just open the socket and trying to receive messages... just the >> necessary stuff. First with a blocking recv() and then non-blocking. >> >> What hardware and software are you using (arch, board, linux, xenomai)? ? >> >> Wolfgang. > > The source code is attached: > > compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT > -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt -lnative > > can frames sent by rtcansend > > Test 1: blocking: > > ID:0 DLC:2hex: 81 00 <-- NMT request > ID:709 DLC:1hex: 00 <-- answer node #9 > ID:708 DLC:1hex: 00 <-- answer node #8 > ID:703 DLC:1hex: 00 <-- answer node #3 > ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 > ID:70400 DLC:1hex: 01 > ID:70600 DLC:1hex: 01 > ID:70100 DLC:1hex: 01 > ID:70200 DLC:1hex: 01 > ID:1010000 DLC:1hex: 08 This means that you can receive messages from the CAN bus. > ID:53220 DLC:124 out of bounds. abort. But that's wired. > > Test 2: non blocking: > > ID:0 DLC:2hex: 81 00 <-- NMT request > ID:709 DLC:1hex: 00 <-- answer node #9 > ID:708 DLC:1hex: 00 <-- answer node #8 > ID:703 DLC:1hex: 00 <-- answer node #3 > ID:705 DLC:0hex: <-- same issue DLC is 0 > ID:70600 DLC:1hex: 01 > ID:70400 DLC:1hex: 01 > ID:70200 DLC:1hex: 01 > ID:70100 DLC:1hex: 01 > ID:1010000 DLC:1hex: 08 > ID:53220 DLC:124 out of bounds. abort. Looks identical. > Also, I found another possible error source and I don't know if this > error picture would corresponds to this. > > However, While reviewing all settings, I noticed that I made a mistake > with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have been > asleep when writing this. I'm going to rebuild this module. Let's try to understand why rt_dev_recv() does return bogus dlc. What hardware and software are you using (arch, board, can controlelr, linux, xenomai)? Wolfgang. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 11:24 ` Wolfgang Grandegger @ 2019-02-12 11:35 ` Johannes Holtz 2019-02-12 14:38 ` Johannes Holtz 1 sibling, 0 replies; 23+ messages in thread From: Johannes Holtz @ 2019-02-12 11:35 UTC (permalink / raw) To: Wolfgang Grandegger, xenomai Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: > Hello, > > Am 12.02.19 um 11:42 schrieb Johannes Holtz: >> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: > ... snip ... >>> UI suggest to write a simple test program to demonstrate the issue. It >>> should just open the socket and trying to receive messages... just the >>> necessary stuff. First with a blocking recv() and then non-blocking. >>> >>> What hardware and software are you using (arch, board, linux, xenomai)? > ? > >>> Wolfgang. >> The source code is attached: >> >> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt -lnative >> >> can frames sent by rtcansend >> >> Test 1: blocking: >> >> ID:0 DLC:2hex: 81 00 <-- NMT request >> ID:709 DLC:1hex: 00 <-- answer node #9 >> ID:708 DLC:1hex: 00 <-- answer node #8 >> ID:703 DLC:1hex: 00 <-- answer node #3 >> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >> ID:70400 DLC:1hex: 01 >> ID:70600 DLC:1hex: 01 >> ID:70100 DLC:1hex: 01 >> ID:70200 DLC:1hex: 01 >> ID:1010000 DLC:1hex: 08 > This means that you can receive messages from the CAN bus. > >> ID:53220 DLC:124 out of bounds. abort. > But that's wired. > >> Test 2: non blocking: >> >> ID:0 DLC:2hex: 81 00 <-- NMT request >> ID:709 DLC:1hex: 00 <-- answer node #9 >> ID:708 DLC:1hex: 00 <-- answer node #8 >> ID:703 DLC:1hex: 00 <-- answer node #3 >> ID:705 DLC:0hex: <-- same issue DLC is 0 >> ID:70600 DLC:1hex: 01 >> ID:70400 DLC:1hex: 01 >> ID:70200 DLC:1hex: 01 >> ID:70100 DLC:1hex: 01 >> ID:1010000 DLC:1hex: 08 >> ID:53220 DLC:124 out of bounds. abort. > Looks identical. > >> Also, I found another possible error source and I don't know if this >> error picture would corresponds to this. >> >> However, While reviewing all settings, I noticed that I made a mistake >> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have been >> asleep when writing this. I'm going to rebuild this module. > Let's try to understand why rt_dev_recv() does return bogus dlc. > > What hardware and software are you using (arch, board, can controlelr, > linux, xenomai)? > > Wolfgang. root@machinectrl:~# uname -a Linux machinectrl 3.8.13-intel-atom #3 SMP Wed Jan 2 11:56:35 CET 2019 i686 GNU/Linux root@machinectrl:~# xeno-config --version 2.6.4 root@machinectrl:~# cat /proc/rtcan/rtcan0/info Device rtcan0 Controller SJA1000 Board EMS-CPC-PCI Clock-Hz 8000000 Baudrate 1000000 Bit-time brp=1 prop_seg=2 phase_seg1=3 phase_seg2=2 sjw=1 sam=1 Ctrl-Mode State active TX-Counter 27 RX-Counter 167 Errors 0 Refcount 0 [ 3.171332] RT-Socket-CAN 0.90.2 - (C) 2006 RT-Socket-CAN Development Team [ 3.172383] RTCAN SJA1000 driver initialized [ 3.173287] rtcan: registered rtcan0 [ 3.173351] EMS-CPC-PCI-CAN 0000:07:02.0: Channel #1 at 0xf84fa400, irq 17 registered as rtcan0 [ 3.173450] rtcan: registered rtcan1 [ 3.173508] EMS-CPC-PCI-CAN 0000:07:02.0: Channel #2 at 0xf84fa600, irq 17 registered as rtcan1 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 11:24 ` Wolfgang Grandegger 2019-02-12 11:35 ` Johannes Holtz @ 2019-02-12 14:38 ` Johannes Holtz 2019-02-12 15:00 ` Wolfgang Grandegger 1 sibling, 1 reply; 23+ messages in thread From: Johannes Holtz @ 2019-02-12 14:38 UTC (permalink / raw) To: Wolfgang Grandegger, xenomai Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: > Hello, > > Am 12.02.19 um 11:42 schrieb Johannes Holtz: >> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: > ... snip ... >>> UI suggest to write a simple test program to demonstrate the issue. It >>> should just open the socket and trying to receive messages... just the >>> necessary stuff. First with a blocking recv() and then non-blocking. >>> >>> What hardware and software are you using (arch, board, linux, xenomai)? > ? > >>> Wolfgang. >> The source code is attached: >> >> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt -lnative >> >> can frames sent by rtcansend >> >> Test 1: blocking: >> >> ID:0 DLC:2hex: 81 00 <-- NMT request >> ID:709 DLC:1hex: 00 <-- answer node #9 >> ID:708 DLC:1hex: 00 <-- answer node #8 >> ID:703 DLC:1hex: 00 <-- answer node #3 >> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >> ID:70400 DLC:1hex: 01 >> ID:70600 DLC:1hex: 01 >> ID:70100 DLC:1hex: 01 >> ID:70200 DLC:1hex: 01 >> ID:1010000 DLC:1hex: 08 > This means that you can receive messages from the CAN bus. > >> ID:53220 DLC:124 out of bounds. abort. > But that's wired. > >> Test 2: non blocking: >> >> ID:0 DLC:2hex: 81 00 <-- NMT request >> ID:709 DLC:1hex: 00 <-- answer node #9 >> ID:708 DLC:1hex: 00 <-- answer node #8 >> ID:703 DLC:1hex: 00 <-- answer node #3 >> ID:705 DLC:0hex: <-- same issue DLC is 0 >> ID:70600 DLC:1hex: 01 >> ID:70400 DLC:1hex: 01 >> ID:70200 DLC:1hex: 01 >> ID:70100 DLC:1hex: 01 >> ID:1010000 DLC:1hex: 08 >> ID:53220 DLC:124 out of bounds. abort. > Looks identical. > >> Also, I found another possible error source and I don't know if this >> error picture would corresponds to this. >> >> However, While reviewing all settings, I noticed that I made a mistake >> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have been >> asleep when writing this. I'm going to rebuild this module. > Let's try to understand why rt_dev_recv() does return bogus dlc. > > What hardware and software are you using (arch, board, can controlelr, > linux, xenomai)? > > Wolfgang. I modified the program a little to send it's own requests via one single socket. The output look like this. send succeeded ID:708 DLC:1hex: 00 ID:709 DLC:1hex: 00 ID:703 DLC:1hex: 00 ID:706 DLC:1hex: 00 ID:705 DLC:7hex: 00 00 01 01 00 09 07 send succeeded send succeeded send succeeded send succeeded send succeeded And a parallel rtcanrecv output like this: root@machinectrl:~# rtcanrecv rtcan0 #0: (1) <0x000> [2] 81 00 #1: (1) <0x708> [1] 00 #2: (1) <0x709> [1] 00 #3: (1) <0x703> [1] 00 #4: (0) <0x706> [0] #5: (0) <0x500> [1] 01 #6: (0) <0x400> [1] 01 #7: (0) <0x100> [1] 01 #8: (0) <0x200> [1] 01 #9: (0) <0x000> [1] 08 #10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf 78 69 91 bf 80 0d 7c b7 ce 68 91 bf c0 68 91 bf 00 9b 04 08 60 69 91 bf 78 69 91 bf cf 8e 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 00 00 00 00 68 00 0f c1 e0 b8 7a b7 00 00 00 00 01 00 00 00 30 ae 10 f7 04 5e 60 b7 e0 68 91 bf b0 68 91 bf #11: (24) <0x220> [124] 00 00 05 07 00 00 01 07 01 00 00 00 f0 84 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf 78 69 91 bf 80 0d 7c b7 ce 68 91 bf c0 68 91 bf 00 9b 04 08 60 69 91 bf 78 69 91 bf cf 8e 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 00 00 00 00 68 00 0f c1 e0 b8 7a b7 00 00 00 00 01 00 00 00 30 ae 10 f7 04 5e 60 b7 e0 68 91 bf b0 68 91 bf #12: (32) <0x000> [50] 05 05 07 00 00 01 07 00 01 00 00 00 f0 84 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf 78 69 91 bf 80 0d 7c b7 ce 68 #13: (9) <0x100> [7] 05 07 00 00 01 07 00 #14: (0) <0x100> [0] #15: (1) <0x705> [7] 00 00 01 01 00 09 07 None of this makes sense to me. -------------- next part -------------- A non-text attachment was scrubbed... Name: can_recv.c Type: text/x-csrc Size: 7066 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20190212/e57ccd89/attachment.c> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 14:38 ` Johannes Holtz @ 2019-02-12 15:00 ` Wolfgang Grandegger 2019-02-12 15:19 ` Johannes Holtz 0 siblings, 1 reply; 23+ messages in thread From: Wolfgang Grandegger @ 2019-02-12 15:00 UTC (permalink / raw) To: Johannes Holtz, xenomai Hello Johannes, Am 12.02.19 um 15:38 schrieb Johannes Holtz: > Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: >> Hello, >> >> Am 12.02.19 um 11:42 schrieb Johannes Holtz: >>> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: >> ... snip ... >>>> UI suggest to write a simple test program to demonstrate the issue. It >>>> should just open the socket and trying to receive messages... just the >>>> necessary stuff. First with a blocking recv() and then non-blocking. >>>> >>>> What hardware and software are you using (arch, board, linux, xenomai)? >> ? >> >>>> Wolfgang. >>> The source code is attached: >>> >>> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >>> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt -lnative >>> >>> can frames sent by rtcansend >>> >>> Test 1: blocking: >>> >>> ID:0 DLC:2hex: 81 00 <-- NMT request >>> ID:709 DLC:1hex: 00 <-- answer node #9 >>> ID:708 DLC:1hex: 00 <-- answer node #8 >>> ID:703 DLC:1hex: 00 <-- answer node #3 >>> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >>> ID:70400 DLC:1hex: 01 >>> ID:70600 DLC:1hex: 01 >>> ID:70100 DLC:1hex: 01 >>> ID:70200 DLC:1hex: 01 >>> ID:1010000 DLC:1hex: 08 >> This means that you can receive messages from the CAN bus. >> >>> ID:53220 DLC:124 out of bounds. abort. >> But that's wired. >> >>> Test 2: non blocking: >>> >>> ID:0 DLC:2hex: 81 00 <-- NMT request >>> ID:709 DLC:1hex: 00 <-- answer node #9 >>> ID:708 DLC:1hex: 00 <-- answer node #8 >>> ID:703 DLC:1hex: 00 <-- answer node #3 >>> ID:705 DLC:0hex: <-- same issue DLC is 0 >>> ID:70600 DLC:1hex: 01 >>> ID:70400 DLC:1hex: 01 >>> ID:70200 DLC:1hex: 01 >>> ID:70100 DLC:1hex: 01 >>> ID:1010000 DLC:1hex: 08 >>> ID:53220 DLC:124 out of bounds. abort. >> Looks identical. >> >>> Also, I found another possible error source and I don't know if this >>> error picture would corresponds to this. >>> >>> However, While reviewing all settings, I noticed that I made a mistake >>> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have been >>> asleep when writing this. I'm going to rebuild this module. >> Let's try to understand why rt_dev_recv() does return bogus dlc. >> >> What hardware and software are you using (arch, board, can controlelr, >> linux, xenomai)? >> >> Wolfgang. > > I modified the program a little to send it's own requests via one single > socket. The output look like this. > > send succeeded > ID:708 DLC:1hex: 00 > ID:709 DLC:1hex: 00 > ID:703 DLC:1hex: 00 > ID:706 DLC:1hex: 00 > ID:705 DLC:7hex: 00 00 01 01 00 09 07 > send succeeded > send succeeded > send succeeded > send succeeded > send succeeded > > And a parallel rtcanrecv output like this: > > root@machinectrl:~# rtcanrecv rtcan0 > #0: (1) <0x000> [2] 81 00 > #1: (1) <0x708> [1] 00 > #2: (1) <0x709> [1] 00 > #3: (1) <0x703> [1] 00 > #4: (0) <0x706> [0] > #5: (0) <0x500> [1] 01 > #6: (0) <0x400> [1] 01 > #7: (0) <0x100> [1] 01 > #8: (0) <0x200> [1] 01 > #9: (0) <0x000> [1] 08 > #10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 04 08 Why is "addr.can_ifindex = 24"? Something is broken in you build. > 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf > 78 69 91 bf 80 0d 7c b7 ce 68 91 bf c0 68 91 bf 00 9b 04 08 60 69 91 bf > 78 69 91 bf cf 8e 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 > 00 00 00 00 68 00 0f c1 e0 b8 7a b7 00 00 00 00 01 00 00 00 30 ae 10 f7 > 04 5e 60 b7 e0 68 91 bf b0 68 91 bf > #11: (24) <0x220> [124] 00 00 05 07 00 00 01 07 01 00 00 00 f0 84 04 08 > 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf > 78 69 91 bf 80 0d 7c b7 ce 68 91 bf c0 68 91 bf 00 9b 04 08 60 69 91 bf > 78 69 91 bf cf 8e 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 > 00 00 00 00 68 00 0f c1 e0 b8 7a b7 00 00 00 00 01 00 00 00 30 ae 10 f7 > 04 5e 60 b7 e0 68 91 bf b0 68 91 bf > #12: (32) <0x000> [50] 05 05 07 00 00 01 07 00 01 00 00 00 f0 84 04 08 > 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf > 78 69 91 bf 80 0d 7c b7 ce 68 > #13: (9) <0x100> [7] 05 07 00 00 01 07 00 > #14: (0) <0x100> [0] > #15: (1) <0x705> [7] 00 00 01 01 00 09 07 > > None of this makes sense to me. I'm really puzzled what's going on. The CAN controller you use is well supported. Wolfgang. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 15:00 ` Wolfgang Grandegger @ 2019-02-12 15:19 ` Johannes Holtz 2019-02-12 17:05 ` Wolfgang Grandegger 0 siblings, 1 reply; 23+ messages in thread From: Johannes Holtz @ 2019-02-12 15:19 UTC (permalink / raw) To: Wolfgang Grandegger, xenomai Am 12.02.19 um 16:00 schrieb Wolfgang Grandegger: > Hello Johannes, > > Am 12.02.19 um 15:38 schrieb Johannes Holtz: >> Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: >>> Hello, >>> >>> Am 12.02.19 um 11:42 schrieb Johannes Holtz: >>>> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: >>> ... snip ... >>>>> UI suggest to write a simple test program to demonstrate the issue. It >>>>> should just open the socket and trying to receive messages... just the >>>>> necessary stuff. First with a blocking recv() and then non-blocking. >>>>> >>>>> What hardware and software are you using (arch, board, linux, xenomai)? >>> ? >>> >>>>> Wolfgang. >>>> The source code is attached: >>>> >>>> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >>>> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt -lnative >>>> >>>> can frames sent by rtcansend >>>> >>>> Test 1: blocking: >>>> >>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >>>> ID:70400 DLC:1hex: 01 >>>> ID:70600 DLC:1hex: 01 >>>> ID:70100 DLC:1hex: 01 >>>> ID:70200 DLC:1hex: 01 >>>> ID:1010000 DLC:1hex: 08 >>> This means that you can receive messages from the CAN bus. >>> >>>> ID:53220 DLC:124 out of bounds. abort. >>> But that's wired. >>> >>>> Test 2: non blocking: >>>> >>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>> ID:705 DLC:0hex: <-- same issue DLC is 0 >>>> ID:70600 DLC:1hex: 01 >>>> ID:70400 DLC:1hex: 01 >>>> ID:70200 DLC:1hex: 01 >>>> ID:70100 DLC:1hex: 01 >>>> ID:1010000 DLC:1hex: 08 >>>> ID:53220 DLC:124 out of bounds. abort. >>> Looks identical. >>> >>>> Also, I found another possible error source and I don't know if this >>>> error picture would corresponds to this. >>>> >>>> However, While reviewing all settings, I noticed that I made a mistake >>>> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have been >>>> asleep when writing this. I'm going to rebuild this module. >>> Let's try to understand why rt_dev_recv() does return bogus dlc. >>> >>> What hardware and software are you using (arch, board, can controlelr, >>> linux, xenomai)? >>> >>> Wolfgang. >> I modified the program a little to send it's own requests via one single >> socket. The output look like this. >> >> send succeeded >> ID:708 DLC:1hex: 00 >> ID:709 DLC:1hex: 00 >> ID:703 DLC:1hex: 00 >> ID:706 DLC:1hex: 00 >> ID:705 DLC:7hex: 00 00 01 01 00 09 07 >> send succeeded >> send succeeded >> send succeeded >> send succeeded >> send succeeded >> >> And a parallel rtcanrecv output like this: >> >> root@machinectrl:~# rtcanrecv rtcan0 >> #0: (1) <0x000> [2] 81 00 >> #1: (1) <0x708> [1] 00 >> #2: (1) <0x709> [1] 00 >> #3: (1) <0x703> [1] 00 >> #4: (0) <0x706> [0] >> #5: (0) <0x500> [1] 01 >> #6: (0) <0x400> [1] 01 >> #7: (0) <0x100> [1] 01 >> #8: (0) <0x200> [1] 01 >> #9: (0) <0x000> [1] 08 >> #10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 04 08 > Why is "addr.can_ifindex = 24"? Something is broken in you build. In the xenomai build? how do I find out what? it all compiled well. I patched the driver before building tkernel with 0001-rtcan-ems_pci-driver-update-to-support-more-devices.patch.gz I used the ipipe patch from the stable release, and then build it normally. Might the RX buf size that I changed a problem? > >> 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf >> 78 69 91 bf 80 0d 7c b7 ce 68 91 bf c0 68 91 bf 00 9b 04 08 60 69 91 bf >> 78 69 91 bf cf 8e 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 >> 00 00 00 00 68 00 0f c1 e0 b8 7a b7 00 00 00 00 01 00 00 00 30 ae 10 f7 >> 04 5e 60 b7 e0 68 91 bf b0 68 91 bf >> #11: (24) <0x220> [124] 00 00 05 07 00 00 01 07 01 00 00 00 f0 84 04 08 >> 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf >> 78 69 91 bf 80 0d 7c b7 ce 68 91 bf c0 68 91 bf 00 9b 04 08 60 69 91 bf >> 78 69 91 bf cf 8e 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 >> 00 00 00 00 68 00 0f c1 e0 b8 7a b7 00 00 00 00 01 00 00 00 30 ae 10 f7 >> 04 5e 60 b7 e0 68 91 bf b0 68 91 bf >> #12: (32) <0x000> [50] 05 05 07 00 00 01 07 00 01 00 00 00 f0 84 04 08 >> 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf >> 78 69 91 bf 80 0d 7c b7 ce 68 >> #13: (9) <0x100> [7] 05 07 00 00 01 07 00 >> #14: (0) <0x100> [0] >> #15: (1) <0x705> [7] 00 00 01 01 00 09 07 >> >> None of this makes sense to me. > I'm really puzzled what's going on. The CAN controller you use is well > supported. That is not a good sign. > Wolfgang. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 15:19 ` Johannes Holtz @ 2019-02-12 17:05 ` Wolfgang Grandegger 2019-02-12 17:24 ` Johannes Holtz 0 siblings, 1 reply; 23+ messages in thread From: Wolfgang Grandegger @ 2019-02-12 17:05 UTC (permalink / raw) To: Johannes Holtz, xenomai Am 12.02.19 um 16:19 schrieb Johannes Holtz: > Am 12.02.19 um 16:00 schrieb Wolfgang Grandegger: >> Hello Johannes, >> >> Am 12.02.19 um 15:38 schrieb Johannes Holtz: >>> Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: >>>> Hello, >>>> >>>> Am 12.02.19 um 11:42 schrieb Johannes Holtz: >>>>> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: >>>> ... snip ... >>>>>> UI suggest to write a simple test program to demonstrate the >>>>>> issue. It >>>>>> should just open the socket and trying to receive messages... just >>>>>> the >>>>>> necessary stuff. First with a blocking recv() and then non-blocking. >>>>>> >>>>>> What hardware and software are you using (arch, board, linux, >>>>>> xenomai)? >>>> ? >>>> >>>>>> Wolfgang. >>>>> The source code is attached: >>>>> >>>>> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >>>>> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt -lnative >>>>> >>>>> can frames sent by rtcansend >>>>> >>>>> Test 1: blocking: >>>>> >>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >>>>> ID:70400 DLC:1hex: 01 >>>>> ID:70600 DLC:1hex: 01 >>>>> ID:70100 DLC:1hex: 01 >>>>> ID:70200 DLC:1hex: 01 >>>>> ID:1010000 DLC:1hex: 08 >>>> This means that you can receive messages from the CAN bus. >>>> >>>>> ID:53220 DLC:124 out of bounds. abort. >>>> But that's wired. >>>> >>>>> Test 2: non blocking: >>>>> >>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>> ID:705 DLC:0hex: <-- same issue DLC is 0 >>>>> ID:70600 DLC:1hex: 01 >>>>> ID:70400 DLC:1hex: 01 >>>>> ID:70200 DLC:1hex: 01 >>>>> ID:70100 DLC:1hex: 01 >>>>> ID:1010000 DLC:1hex: 08 >>>>> ID:53220 DLC:124 out of bounds. abort. >>>> Looks identical. >>>> >>>>> Also, I found another possible error source and I don't know if this >>>>> error picture would corresponds to this. >>>>> >>>>> However, While reviewing all settings, I noticed that I made a >>>>> mistake >>>>> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have >>>>> been >>>>> asleep when writing this. I'm going to rebuild this module. >>>> Let's try to understand why rt_dev_recv() does return bogus dlc. >>>> >>>> What hardware and software are you using (arch, board, can controlelr, >>>> linux, xenomai)? >>>> >>>> Wolfgang. >>> I modified the program a little to send it's own requests via one single >>> socket. The output look like this. >>> >>> send succeeded >>> ID:708 DLC:1hex: 00 >>> ID:709 DLC:1hex: 00 >>> ID:703 DLC:1hex: 00 >>> ID:706 DLC:1hex: 00 >>> ID:705 DLC:7hex: 00 00 01 01 00 09 07 >>> send succeeded >>> send succeeded >>> send succeeded >>> send succeeded >>> send succeeded >>> >>> And a parallel rtcanrecv output like this: >>> >>> root@machinectrl:~# rtcanrecv rtcan0 >>> #0: (1) <0x000> [2] 81 00 >>> #1: (1) <0x708> [1] 00 >>> #2: (1) <0x709> [1] 00 >>> #3: (1) <0x703> [1] 00 >>> #4: (0) <0x706> [0] >>> #5: (0) <0x500> [1] 01 >>> #6: (0) <0x400> [1] 01 >>> #7: (0) <0x100> [1] 01 >>> #8: (0) <0x200> [1] 01 >>> #9: (0) <0x000> [1] 08 >>> #10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 04 08 >> Why is "addr.can_ifindex = 24"? Something is broken in you build. > > In the xenomai build? how do I find out what? it all compiled well. > > I patched the driver before building tkernel with > 0001-rtcan-ems_pci-driver-update-to-support-more-devices.patch.gz Can you show me that patch. > > I used the ipipe patch from the stable release, > > and then build it normally. > > Might the RX buf size that I changed a problem? What exactly did you change? I think "rtcanrecv" does not use it. Wolfgang ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 17:05 ` Wolfgang Grandegger @ 2019-02-12 17:24 ` Johannes Holtz 2019-02-12 17:53 ` Wolfgang Grandegger 0 siblings, 1 reply; 23+ messages in thread From: Johannes Holtz @ 2019-02-12 17:24 UTC (permalink / raw) To: Wolfgang Grandegger, xenomai Am 12.02.19 um 18:05 schrieb Wolfgang Grandegger: > Am 12.02.19 um 16:19 schrieb Johannes Holtz: >> Am 12.02.19 um 16:00 schrieb Wolfgang Grandegger: >>> Hello Johannes, >>> >>> Am 12.02.19 um 15:38 schrieb Johannes Holtz: >>>> Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: >>>>> Hello, >>>>> >>>>> Am 12.02.19 um 11:42 schrieb Johannes Holtz: >>>>>> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: >>>>> ... snip ... >>>>>>> UI suggest to write a simple test program to demonstrate the >>>>>>> issue. It >>>>>>> should just open the socket and trying to receive messages... just >>>>>>> the >>>>>>> necessary stuff. First with a blocking recv() and then non-blocking. >>>>>>> >>>>>>> What hardware and software are you using (arch, board, linux, >>>>>>> xenomai)? >>>>> ? >>>>> >>>>>>> Wolfgang. >>>>>> The source code is attached: >>>>>> >>>>>> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >>>>>> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt -lnative >>>>>> >>>>>> can frames sent by rtcansend >>>>>> >>>>>> Test 1: blocking: >>>>>> >>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >>>>>> ID:70400 DLC:1hex: 01 >>>>>> ID:70600 DLC:1hex: 01 >>>>>> ID:70100 DLC:1hex: 01 >>>>>> ID:70200 DLC:1hex: 01 >>>>>> ID:1010000 DLC:1hex: 08 >>>>> This means that you can receive messages from the CAN bus. >>>>> >>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>> But that's wired. >>>>> >>>>>> Test 2: non blocking: >>>>>> >>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>> ID:705 DLC:0hex: <-- same issue DLC is 0 >>>>>> ID:70600 DLC:1hex: 01 >>>>>> ID:70400 DLC:1hex: 01 >>>>>> ID:70200 DLC:1hex: 01 >>>>>> ID:70100 DLC:1hex: 01 >>>>>> ID:1010000 DLC:1hex: 08 >>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>> Looks identical. >>>>> >>>>>> Also, I found another possible error source and I don't know if this >>>>>> error picture would corresponds to this. >>>>>> >>>>>> However, While reviewing all settings, I noticed that I made a >>>>>> mistake >>>>>> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have >>>>>> been >>>>>> asleep when writing this. I'm going to rebuild this module. >>>>> Let's try to understand why rt_dev_recv() does return bogus dlc. >>>>> >>>>> What hardware and software are you using (arch, board, can controlelr, >>>>> linux, xenomai)? >>>>> >>>>> Wolfgang. >>>> I modified the program a little to send it's own requests via one single >>>> socket. The output look like this. >>>> >>>> send succeeded >>>> ID:708 DLC:1hex: 00 >>>> ID:709 DLC:1hex: 00 >>>> ID:703 DLC:1hex: 00 >>>> ID:706 DLC:1hex: 00 >>>> ID:705 DLC:7hex: 00 00 01 01 00 09 07 >>>> send succeeded >>>> send succeeded >>>> send succeeded >>>> send succeeded >>>> send succeeded >>>> >>>> And a parallel rtcanrecv output like this: >>>> >>>> root@machinectrl:~# rtcanrecv rtcan0 >>>> #0: (1) <0x000> [2] 81 00 >>>> #1: (1) <0x708> [1] 00 >>>> #2: (1) <0x709> [1] 00 >>>> #3: (1) <0x703> [1] 00 >>>> #4: (0) <0x706> [0] >>>> #5: (0) <0x500> [1] 01 >>>> #6: (0) <0x400> [1] 01 >>>> #7: (0) <0x100> [1] 01 >>>> #8: (0) <0x200> [1] 01 >>>> #9: (0) <0x000> [1] 08 >>>> #10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 04 08 >>> Why is "addr.can_ifindex = 24"? Something is broken in you build. >> In the xenomai build? how do I find out what? it all compiled well. >> >> I patched the driver before building tkernel with >> 0001-rtcan-ems_pci-driver-update-to-support-more-devices.patch.gz > Can you show me that patch. See attachment. > >> I used the ipipe patch from the stable release, >> >> and then build it normally. >> >> Might the RX buf size that I changed a problem? > What exactly did you change? I think "rtcanrecv" does not use it. > > Wolfgang The kernel option CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE I at first I set it to a wrong value 8096 but eve after I changed it to 8192 it didnt change anythingand now i set it back to 1024 with no improvement either. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-rtcan-ems_pci-driver-update-to-support-more-devices.patch.gz Type: application/gzip Size: 6003 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20190212/7deb045a/attachment.bin> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 17:24 ` Johannes Holtz @ 2019-02-12 17:53 ` Wolfgang Grandegger 2019-02-12 18:14 ` Steve Freyder 2019-02-13 9:37 ` Johannes Holtz 0 siblings, 2 replies; 23+ messages in thread From: Wolfgang Grandegger @ 2019-02-12 17:53 UTC (permalink / raw) To: Johannes Holtz, xenomai Am 12.02.19 um 18:24 schrieb Johannes Holtz: > Am 12.02.19 um 18:05 schrieb Wolfgang Grandegger: >> Am 12.02.19 um 16:19 schrieb Johannes Holtz: >>> Am 12.02.19 um 16:00 schrieb Wolfgang Grandegger: >>>> Hello Johannes, >>>> >>>> Am 12.02.19 um 15:38 schrieb Johannes Holtz: >>>>> Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: >>>>>> Hello, >>>>>> >>>>>> Am 12.02.19 um 11:42 schrieb Johannes Holtz: >>>>>>> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: >>>>>> ... snip ... >>>>>>>> UI suggest to write a simple test program to demonstrate the >>>>>>>> issue. It >>>>>>>> should just open the socket and trying to receive messages... just >>>>>>>> the >>>>>>>> necessary stuff. First with a blocking recv() and then >>>>>>>> non-blocking. >>>>>>>> >>>>>>>> What hardware and software are you using (arch, board, linux, >>>>>>>> xenomai)? >>>>>> ? >>>>>> >>>>>>>> Wolfgang. >>>>>>> The source code is attached: >>>>>>> >>>>>>> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >>>>>>> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt >>>>>>> -lnative >>>>>>> >>>>>>> can frames sent by rtcansend >>>>>>> >>>>>>> Test 1: blocking: >>>>>>> >>>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>>> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >>>>>>> ID:70400 DLC:1hex: 01 >>>>>>> ID:70600 DLC:1hex: 01 >>>>>>> ID:70100 DLC:1hex: 01 >>>>>>> ID:70200 DLC:1hex: 01 >>>>>>> ID:1010000 DLC:1hex: 08 >>>>>> This means that you can receive messages from the CAN bus. >>>>>> >>>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>>> But that's wired. >>>>>> >>>>>>> Test 2: non blocking: >>>>>>> >>>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>>> ID:705 DLC:0hex: <-- same issue DLC is 0 >>>>>>> ID:70600 DLC:1hex: 01 >>>>>>> ID:70400 DLC:1hex: 01 >>>>>>> ID:70200 DLC:1hex: 01 >>>>>>> ID:70100 DLC:1hex: 01 >>>>>>> ID:1010000 DLC:1hex: 08 >>>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>>> Looks identical. >>>>>> >>>>>>> Also, I found another possible error source and I don't know if this >>>>>>> error picture would corresponds to this. >>>>>>> >>>>>>> However, While reviewing all settings, I noticed that I made a >>>>>>> mistake >>>>>>> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have >>>>>>> been >>>>>>> asleep when writing this. I'm going to rebuild this module. >>>>>> Let's try to understand why rt_dev_recv() does return bogus dlc. >>>>>> >>>>>> What hardware and software are you using (arch, board, can >>>>>> controlelr, >>>>>> linux, xenomai)? >>>>>> >>>>>> Wolfgang. >>>>> I modified the program a little to send it's own requests via one >>>>> single >>>>> socket. The output look like this. >>>>> >>>>> send succeeded >>>>> ID:708 DLC:1hex: 00 >>>>> ID:709 DLC:1hex: 00 >>>>> ID:703 DLC:1hex: 00 >>>>> ID:706 DLC:1hex: 00 >>>>> ID:705 DLC:7hex: 00 00 01 01 00 09 07 >>>>> send succeeded >>>>> send succeeded >>>>> send succeeded >>>>> send succeeded >>>>> send succeeded >>>>> >>>>> And a parallel rtcanrecv output like this: >>>>> >>>>> root@machinectrl:~# rtcanrecv rtcan0 >>>>> #0: (1) <0x000> [2] 81 00 >>>>> #1: (1) <0x708> [1] 00 >>>>> #2: (1) <0x709> [1] 00 >>>>> #3: (1) <0x703> [1] 00 >>>>> #4: (0) <0x706> [0] >>>>> #5: (0) <0x500> [1] 01 >>>>> #6: (0) <0x400> [1] 01 >>>>> #7: (0) <0x100> [1] 01 >>>>> #8: (0) <0x200> [1] 01 >>>>> #9: (0) <0x000> [1] 08 >>>>> #10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 >>>>> 04 08 >>>> Why is "addr.can_ifindex = 24"? Something is broken in you build. >>> In the xenomai build? how do I find out what? it all compiled well. >>> >>> I patched the driver before building tkernel with >>> 0001-rtcan-ems_pci-driver-update-to-support-more-devices.patch.gz >> Can you show me that patch. > See attachment. >> >>> I used the ipipe patch from the stable release, >>> >>> and then build it normally. >>> >>> Might the RX buf size that I changed a problem? >> What exactly did you change? I think "rtcanrecv" does not use it. >> >> Wolfgang > > The kernel option CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE I at first I set it > to a wrong value 8096 but eve after I changed it to 8192 it didnt > change anythingand now i set it back to 1024 with no improvement either. Ah, a value of 8096 does make trouble, e.g. with expression like the following: sock->recv_tail = (sock->recv_tail + cpy_size) & (RTCAN_RXBUF_SIZE - 1); Could you please make a *clean* rebuild from scratch with a value 2^N, either 8192 or 1024. Wolfgang. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 17:53 ` Wolfgang Grandegger @ 2019-02-12 18:14 ` Steve Freyder 2019-02-12 18:20 ` Wolfgang Grandegger 2019-02-13 9:37 ` Johannes Holtz 1 sibling, 1 reply; 23+ messages in thread From: Steve Freyder @ 2019-02-12 18:14 UTC (permalink / raw) To: xenomai On 2/12/2019 11:53 AM, Wolfgang Grandegger via Xenomai wrote: > > Am 12.02.19 um 18:24 schrieb Johannes Holtz: >> Am 12.02.19 um 18:05 schrieb Wolfgang Grandegger: >>> Am 12.02.19 um 16:19 schrieb Johannes Holtz: >>>> Am 12.02.19 um 16:00 schrieb Wolfgang Grandegger: >>>>> Hello Johannes, >>>>> >>>>> Am 12.02.19 um 15:38 schrieb Johannes Holtz: >>>>>> Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: >>>>>>> Hello, >>>>>>> >>>>>>> Am 12.02.19 um 11:42 schrieb Johannes Holtz: >>>>>>>> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: >>>>>>> ... snip ... >>>>>>>>> UI suggest to write a simple test program to demonstrate the >>>>>>>>> issue. It >>>>>>>>> should just open the socket and trying to receive messages... just >>>>>>>>> the >>>>>>>>> necessary stuff. First with a blocking recv() and then >>>>>>>>> non-blocking. >>>>>>>>> >>>>>>>>> What hardware and software are you using (arch, board, linux, >>>>>>>>> xenomai)? >>>>>>> ? >>>>>>> >>>>>>>>> Wolfgang. >>>>>>>> The source code is attached: >>>>>>>> >>>>>>>> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >>>>>>>> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt >>>>>>>> -lnative >>>>>>>> >>>>>>>> can frames sent by rtcansend >>>>>>>> >>>>>>>> Test 1: blocking: >>>>>>>> >>>>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>>>> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >>>>>>>> ID:70400 DLC:1hex: 01 >>>>>>>> ID:70600 DLC:1hex: 01 >>>>>>>> ID:70100 DLC:1hex: 01 >>>>>>>> ID:70200 DLC:1hex: 01 >>>>>>>> ID:1010000 DLC:1hex: 08 >>>>>>> This means that you can receive messages from the CAN bus. >>>>>>> >>>>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>>>> But that's wired. >>>>>>> >>>>>>>> Test 2: non blocking: >>>>>>>> >>>>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>>>> ID:705 DLC:0hex: <-- same issue DLC is 0 >>>>>>>> ID:70600 DLC:1hex: 01 >>>>>>>> ID:70400 DLC:1hex: 01 >>>>>>>> ID:70200 DLC:1hex: 01 >>>>>>>> ID:70100 DLC:1hex: 01 >>>>>>>> ID:1010000 DLC:1hex: 08 >>>>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>>>> Looks identical. >>>>>>> >>>>>>>> Also, I found another possible error source and I don't know if this >>>>>>>> error picture would corresponds to this. >>>>>>>> >>>>>>>> However, While reviewing all settings, I noticed that I made a >>>>>>>> mistake >>>>>>>> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have >>>>>>>> been >>>>>>>> asleep when writing this. I'm going to rebuild this module. >>>>>>> Let's try to understand why rt_dev_recv() does return bogus dlc. >>>>>>> >>>>>>> What hardware and software are you using (arch, board, can >>>>>>> controlelr, >>>>>>> linux, xenomai)? >>>>>>> >>>>>>> Wolfgang. >>>>>> I modified the program a little to send it's own requests via one >>>>>> single >>>>>> socket. The output look like this. >>>>>> >>>>>> send succeeded >>>>>> ID:708 DLC:1hex: 00 >>>>>> ID:709 DLC:1hex: 00 >>>>>> ID:703 DLC:1hex: 00 >>>>>> ID:706 DLC:1hex: 00 >>>>>> ID:705 DLC:7hex: 00 00 01 01 00 09 07 >>>>>> send succeeded >>>>>> send succeeded >>>>>> send succeeded >>>>>> send succeeded >>>>>> send succeeded >>>>>> >>>>>> And a parallel rtcanrecv output like this: >>>>>> >>>>>> root@machinectrl:~# rtcanrecv rtcan0 >>>>>> #0: (1) <0x000> [2] 81 00 >>>>>> #1: (1) <0x708> [1] 00 >>>>>> #2: (1) <0x709> [1] 00 >>>>>> #3: (1) <0x703> [1] 00 >>>>>> #4: (0) <0x706> [0] >>>>>> #5: (0) <0x500> [1] 01 >>>>>> #6: (0) <0x400> [1] 01 >>>>>> #7: (0) <0x100> [1] 01 >>>>>> #8: (0) <0x200> [1] 01 >>>>>> #9: (0) <0x000> [1] 08 >>>>>> #10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 >>>>>> 04 08 >>>>> Why is "addr.can_ifindex = 24"? Something is broken in you build. >>>> In the xenomai build? how do I find out what? it all compiled well. >>>> >>>> I patched the driver before building tkernel with >>>> 0001-rtcan-ems_pci-driver-update-to-support-more-devices.patch.gz >>> Can you show me that patch. >> See attachment. >>>> I used the ipipe patch from the stable release, >>>> >>>> and then build it normally. >>>> >>>> Might the RX buf size that I changed a problem? >>> What exactly did you change? I think "rtcanrecv" does not use it. >>> >>> Wolfgang >> The kernel option CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE I at first I set it >> to a wrong value 8096 but eve after I changed it to 8192 it didnt >> change anythingand now i set it back to 1024 with no improvement either. > Ah, a value of 8096 does make trouble, e.g. with expression like the > following: > > sock->recv_tail = (sock->recv_tail + cpy_size) & > (RTCAN_RXBUF_SIZE - 1); > > Could you please make a *clean* rebuild from scratch with a value 2^N, > either 8192 or 1024. > > Wolfgang. > #if (RTCAN_RXBUF_SIZE)&((RTCAN_RXBUF_SIZE)-1) #error RTCAN_RXBUF_SIZE is not a power of 2! #endif ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 18:14 ` Steve Freyder @ 2019-02-12 18:20 ` Wolfgang Grandegger 0 siblings, 0 replies; 23+ messages in thread From: Wolfgang Grandegger @ 2019-02-12 18:20 UTC (permalink / raw) To: xenomai Am 12.02.19 um 19:14 schrieb Steve Freyder via Xenomai: > > On 2/12/2019 11:53 AM, Wolfgang Grandegger via Xenomai wrote: >> >> Am 12.02.19 um 18:24 schrieb Johannes Holtz: >>> Am 12.02.19 um 18:05 schrieb Wolfgang Grandegger: >>>> Am 12.02.19 um 16:19 schrieb Johannes Holtz: >>>>> Am 12.02.19 um 16:00 schrieb Wolfgang Grandegger: >>>>>> Hello Johannes, >>>>>> >>>>>> Am 12.02.19 um 15:38 schrieb Johannes Holtz: >>>>>>> Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Am 12.02.19 um 11:42 schrieb Johannes Holtz: >>>>>>>>> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: >>>>>>>> ... snip ... >>>>>>>>>> UI suggest to write a simple test program to demonstrate the >>>>>>>>>> issue. It >>>>>>>>>> should just open the socket and trying to receive messages... >>>>>>>>>> just >>>>>>>>>> the >>>>>>>>>> necessary stuff. First with a blocking recv() and then >>>>>>>>>> non-blocking. >>>>>>>>>> >>>>>>>>>> What hardware and software are you using (arch, board, linux, >>>>>>>>>> xenomai)? >>>>>>>> ? >>>>>>>> >>>>>>>>>> Wolfgang. >>>>>>>>> The source code is attached: >>>>>>>>> >>>>>>>>> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >>>>>>>>> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt >>>>>>>>> -lnative >>>>>>>>> >>>>>>>>> can frames sent by rtcansend >>>>>>>>> >>>>>>>>> Test 1: blocking: >>>>>>>>> >>>>>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>>>>> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >>>>>>>>> ID:70400 DLC:1hex: 01 >>>>>>>>> ID:70600 DLC:1hex: 01 >>>>>>>>> ID:70100 DLC:1hex: 01 >>>>>>>>> ID:70200 DLC:1hex: 01 >>>>>>>>> ID:1010000 DLC:1hex: 08 >>>>>>>> This means that you can receive messages from the CAN bus. >>>>>>>> >>>>>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>>>>> But that's wired. >>>>>>>> >>>>>>>>> Test 2: non blocking: >>>>>>>>> >>>>>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>>>>> ID:705 DLC:0hex: <-- same issue DLC is 0 >>>>>>>>> ID:70600 DLC:1hex: 01 >>>>>>>>> ID:70400 DLC:1hex: 01 >>>>>>>>> ID:70200 DLC:1hex: 01 >>>>>>>>> ID:70100 DLC:1hex: 01 >>>>>>>>> ID:1010000 DLC:1hex: 08 >>>>>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>>>>> Looks identical. >>>>>>>> >>>>>>>>> Also, I found another possible error source and I don't know if >>>>>>>>> this >>>>>>>>> error picture would corresponds to this. >>>>>>>>> >>>>>>>>> However, While reviewing all settings, I noticed that I made a >>>>>>>>> mistake >>>>>>>>> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must >>>>>>>>> have >>>>>>>>> been >>>>>>>>> asleep when writing this. I'm going to rebuild this module. >>>>>>>> Let's try to understand why rt_dev_recv() does return bogus dlc. >>>>>>>> >>>>>>>> What hardware and software are you using (arch, board, can >>>>>>>> controlelr, >>>>>>>> linux, xenomai)? >>>>>>>> >>>>>>>> Wolfgang. >>>>>>> I modified the program a little to send it's own requests via one >>>>>>> single >>>>>>> socket. The output look like this. >>>>>>> >>>>>>> send succeeded >>>>>>> ID:708 DLC:1hex: 00 >>>>>>> ID:709 DLC:1hex: 00 >>>>>>> ID:703 DLC:1hex: 00 >>>>>>> ID:706 DLC:1hex: 00 >>>>>>> ID:705 DLC:7hex: 00 00 01 01 00 09 07 >>>>>>> send succeeded >>>>>>> send succeeded >>>>>>> send succeeded >>>>>>> send succeeded >>>>>>> send succeeded >>>>>>> >>>>>>> And a parallel rtcanrecv output like this: >>>>>>> >>>>>>> root@machinectrl:~# rtcanrecv rtcan0 >>>>>>> #0: (1) <0x000> [2] 81 00 >>>>>>> #1: (1) <0x708> [1] 00 >>>>>>> #2: (1) <0x709> [1] 00 >>>>>>> #3: (1) <0x703> [1] 00 >>>>>>> #4: (0) <0x706> [0] >>>>>>> #5: (0) <0x500> [1] 01 >>>>>>> #6: (0) <0x400> [1] 01 >>>>>>> #7: (0) <0x100> [1] 01 >>>>>>> #8: (0) <0x200> [1] 01 >>>>>>> #9: (0) <0x000> [1] 08 >>>>>>> #10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 >>>>>>> 04 08 >>>>>> Why is "addr.can_ifindex = 24"? Something is broken in you build. >>>>> In the xenomai build? how do I find out what? it all compiled well. >>>>> >>>>> I patched the driver before building tkernel with >>>>> 0001-rtcan-ems_pci-driver-update-to-support-more-devices.patch.gz >>>> Can you show me that patch. >>> See attachment. >>>>> I used the ipipe patch from the stable release, >>>>> >>>>> and then build it normally. >>>>> >>>>> Might the RX buf size that I changed a problem? >>>> What exactly did you change? I think "rtcanrecv" does not use it. >>>> >>>> Wolfgang >>> The kernel option CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE I at first I set it >>> to a wrong value 8096 but eve after I changed it to 8192 it didnt >>> change anythingand now i set it back to 1024 with no improvement either. >> Ah, a value of 8096 does make trouble, e.g. with expression like the >> following: >> >> sock->recv_tail = (sock->recv_tail + cpy_size) & >> (RTCAN_RXBUF_SIZE - 1); >> >> Could you please make a *clean* rebuild from scratch with a value 2^N, >> either 8192 or 1024. >> >> Wolfgang. >> > > #if (RTCAN_RXBUF_SIZE)&((RTCAN_RXBUF_SIZE)-1) > #error RTCAN_RXBUF_SIZE is not a power of 2! > #endif Of course! I'm going to prepare a patch. Wolfgang. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-12 17:53 ` Wolfgang Grandegger 2019-02-12 18:14 ` Steve Freyder @ 2019-02-13 9:37 ` Johannes Holtz 2019-02-13 10:20 ` Wolfgang Grandegger 1 sibling, 1 reply; 23+ messages in thread From: Johannes Holtz @ 2019-02-13 9:37 UTC (permalink / raw) To: Wolfgang Grandegger, xenomai Am 12.02.19 um 18:53 schrieb Wolfgang Grandegger: > Am 12.02.19 um 18:24 schrieb Johannes Holtz: >> Am 12.02.19 um 18:05 schrieb Wolfgang Grandegger: >>> Am 12.02.19 um 16:19 schrieb Johannes Holtz: >>>> Am 12.02.19 um 16:00 schrieb Wolfgang Grandegger: >>>>> Hello Johannes, >>>>> >>>>> Am 12.02.19 um 15:38 schrieb Johannes Holtz: >>>>>> Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: >>>>>>> Hello, >>>>>>> >>>>>>> Am 12.02.19 um 11:42 schrieb Johannes Holtz: >>>>>>>> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: >>>>>>> ... snip ... >>>>>>>>> UI suggest to write a simple test program to demonstrate the >>>>>>>>> issue. It >>>>>>>>> should just open the socket and trying to receive messages... just >>>>>>>>> the >>>>>>>>> necessary stuff. First with a blocking recv() and then >>>>>>>>> non-blocking. >>>>>>>>> >>>>>>>>> What hardware and software are you using (arch, board, linux, >>>>>>>>> xenomai)? >>>>>>> ? >>>>>>> >>>>>>>>> Wolfgang. >>>>>>>> The source code is attached: >>>>>>>> >>>>>>>> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >>>>>>>> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt >>>>>>>> -lnative >>>>>>>> >>>>>>>> can frames sent by rtcansend >>>>>>>> >>>>>>>> Test 1: blocking: >>>>>>>> >>>>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>>>> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >>>>>>>> ID:70400 DLC:1hex: 01 >>>>>>>> ID:70600 DLC:1hex: 01 >>>>>>>> ID:70100 DLC:1hex: 01 >>>>>>>> ID:70200 DLC:1hex: 01 >>>>>>>> ID:1010000 DLC:1hex: 08 >>>>>>> This means that you can receive messages from the CAN bus. >>>>>>> >>>>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>>>> But that's wired. >>>>>>> >>>>>>>> Test 2: non blocking: >>>>>>>> >>>>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>>>> ID:705 DLC:0hex: <-- same issue DLC is 0 >>>>>>>> ID:70600 DLC:1hex: 01 >>>>>>>> ID:70400 DLC:1hex: 01 >>>>>>>> ID:70200 DLC:1hex: 01 >>>>>>>> ID:70100 DLC:1hex: 01 >>>>>>>> ID:1010000 DLC:1hex: 08 >>>>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>>>> Looks identical. >>>>>>> >>>>>>>> Also, I found another possible error source and I don't know if this >>>>>>>> error picture would corresponds to this. >>>>>>>> >>>>>>>> However, While reviewing all settings, I noticed that I made a >>>>>>>> mistake >>>>>>>> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have >>>>>>>> been >>>>>>>> asleep when writing this. I'm going to rebuild this module. >>>>>>> Let's try to understand why rt_dev_recv() does return bogus dlc. >>>>>>> >>>>>>> What hardware and software are you using (arch, board, can >>>>>>> controlelr, >>>>>>> linux, xenomai)? >>>>>>> >>>>>>> Wolfgang. >>>>>> I modified the program a little to send it's own requests via one >>>>>> single >>>>>> socket. The output look like this. >>>>>> >>>>>> send succeeded >>>>>> ID:708 DLC:1hex: 00 >>>>>> ID:709 DLC:1hex: 00 >>>>>> ID:703 DLC:1hex: 00 >>>>>> ID:706 DLC:1hex: 00 >>>>>> ID:705 DLC:7hex: 00 00 01 01 00 09 07 >>>>>> send succeeded >>>>>> send succeeded >>>>>> send succeeded >>>>>> send succeeded >>>>>> send succeeded >>>>>> >>>>>> And a parallel rtcanrecv output like this: >>>>>> >>>>>> root@machinectrl:~# rtcanrecv rtcan0 >>>>>> #0: (1) <0x000> [2] 81 00 >>>>>> #1: (1) <0x708> [1] 00 >>>>>> #2: (1) <0x709> [1] 00 >>>>>> #3: (1) <0x703> [1] 00 >>>>>> #4: (0) <0x706> [0] >>>>>> #5: (0) <0x500> [1] 01 >>>>>> #6: (0) <0x400> [1] 01 >>>>>> #7: (0) <0x100> [1] 01 >>>>>> #8: (0) <0x200> [1] 01 >>>>>> #9: (0) <0x000> [1] 08 >>>>>> #10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 >>>>>> 04 08 >>>>> Why is "addr.can_ifindex = 24"? Something is broken in you build. >>>> In the xenomai build? how do I find out what? it all compiled well. >>>> >>>> I patched the driver before building tkernel with >>>> 0001-rtcan-ems_pci-driver-update-to-support-more-devices.patch.gz >>> Can you show me that patch. >> See attachment. >>>> I used the ipipe patch from the stable release, >>>> >>>> and then build it normally. >>>> >>>> Might the RX buf size that I changed a problem? >>> What exactly did you change? I think "rtcanrecv" does not use it. >>> >>> Wolfgang >> The kernel option CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE I at first I set it >> to a wrong value 8096 but eve after I changed it to 8192 it didnt >> change anythingand now i set it back to 1024 with no improvement either. > Ah, a value of 8096 does make trouble, e.g. with expression like the > following: > > sock->recv_tail = (sock->recv_tail + cpy_size) & > (RTCAN_RXBUF_SIZE - 1); > > Could you please make a *clean* rebuild from scratch with a value 2^N, > either 8192 or 1024. > > Wolfgang. Building the complete Kernel anew did the trick. Don't really understand why re-building (and installing) just the module didn't work. Anyway, I'm happy that it works now. So, as a takeaway: Don't mess with the CAN_RXBUF_SIZE. Cheers and thank you Wolfgang. Schoenen Tag noch. Johannes ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: RTCan missing frames 2019-02-13 9:37 ` Johannes Holtz @ 2019-02-13 10:20 ` Wolfgang Grandegger 0 siblings, 0 replies; 23+ messages in thread From: Wolfgang Grandegger @ 2019-02-13 10:20 UTC (permalink / raw) To: Johannes Holtz, xenomai Am 13.02.19 um 10:37 schrieb Johannes Holtz: > Am 12.02.19 um 18:53 schrieb Wolfgang Grandegger: >> Am 12.02.19 um 18:24 schrieb Johannes Holtz: >>> Am 12.02.19 um 18:05 schrieb Wolfgang Grandegger: >>>> Am 12.02.19 um 16:19 schrieb Johannes Holtz: >>>>> Am 12.02.19 um 16:00 schrieb Wolfgang Grandegger: >>>>>> Hello Johannes, >>>>>> >>>>>> Am 12.02.19 um 15:38 schrieb Johannes Holtz: >>>>>>> Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Am 12.02.19 um 11:42 schrieb Johannes Holtz: >>>>>>>>> Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger: >>>>>>>> ... snip ... >>>>>>>>>> UI suggest to write a simple test program to demonstrate the >>>>>>>>>> issue. It >>>>>>>>>> should just open the socket and trying to receive messages... >>>>>>>>>> just >>>>>>>>>> the >>>>>>>>>> necessary stuff. First with a blocking recv() and then >>>>>>>>>> non-blocking. >>>>>>>>>> >>>>>>>>>> What hardware and software are you using (arch, board, linux, >>>>>>>>>> xenomai)? >>>>>>>> ? >>>>>>>> >>>>>>>>>> Wolfgang. >>>>>>>>> The source code is attached: >>>>>>>>> >>>>>>>>> compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT >>>>>>>>> -D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt >>>>>>>>> -lnative >>>>>>>>> >>>>>>>>> can frames sent by rtcansend >>>>>>>>> >>>>>>>>> Test 1: blocking: >>>>>>>>> >>>>>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>>>>> ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0 >>>>>>>>> ID:70400 DLC:1hex: 01 >>>>>>>>> ID:70600 DLC:1hex: 01 >>>>>>>>> ID:70100 DLC:1hex: 01 >>>>>>>>> ID:70200 DLC:1hex: 01 >>>>>>>>> ID:1010000 DLC:1hex: 08 >>>>>>>> This means that you can receive messages from the CAN bus. >>>>>>>> >>>>>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>>>>> But that's wired. >>>>>>>> >>>>>>>>> Test 2: non blocking: >>>>>>>>> >>>>>>>>> ID:0 DLC:2hex: 81 00 <-- NMT request >>>>>>>>> ID:709 DLC:1hex: 00 <-- answer node #9 >>>>>>>>> ID:708 DLC:1hex: 00 <-- answer node #8 >>>>>>>>> ID:703 DLC:1hex: 00 <-- answer node #3 >>>>>>>>> ID:705 DLC:0hex: <-- same issue DLC is 0 >>>>>>>>> ID:70600 DLC:1hex: 01 >>>>>>>>> ID:70400 DLC:1hex: 01 >>>>>>>>> ID:70200 DLC:1hex: 01 >>>>>>>>> ID:70100 DLC:1hex: 01 >>>>>>>>> ID:1010000 DLC:1hex: 08 >>>>>>>>> ID:53220 DLC:124 out of bounds. abort. >>>>>>>> Looks identical. >>>>>>>> >>>>>>>>> Also, I found another possible error source and I don't know if >>>>>>>>> this >>>>>>>>> error picture would corresponds to this. >>>>>>>>> >>>>>>>>> However, While reviewing all settings, I noticed that I made a >>>>>>>>> mistake >>>>>>>>> with the RXBUF_SIZE which is set to 8096 instead of 8192. Must >>>>>>>>> have >>>>>>>>> been >>>>>>>>> asleep when writing this. I'm going to rebuild this module. >>>>>>>> Let's try to understand why rt_dev_recv() does return bogus dlc. >>>>>>>> >>>>>>>> What hardware and software are you using (arch, board, can >>>>>>>> controlelr, >>>>>>>> linux, xenomai)? >>>>>>>> >>>>>>>> Wolfgang. >>>>>>> I modified the program a little to send it's own requests via one >>>>>>> single >>>>>>> socket. The output look like this. >>>>>>> >>>>>>> send succeeded >>>>>>> ID:708 DLC:1hex: 00 >>>>>>> ID:709 DLC:1hex: 00 >>>>>>> ID:703 DLC:1hex: 00 >>>>>>> ID:706 DLC:1hex: 00 >>>>>>> ID:705 DLC:7hex: 00 00 01 01 00 09 07 >>>>>>> send succeeded >>>>>>> send succeeded >>>>>>> send succeeded >>>>>>> send succeeded >>>>>>> send succeeded >>>>>>> >>>>>>> And a parallel rtcanrecv output like this: >>>>>>> >>>>>>> root@machinectrl:~# rtcanrecv rtcan0 >>>>>>> #0: (1) <0x000> [2] 81 00 >>>>>>> #1: (1) <0x708> [1] 00 >>>>>>> #2: (1) <0x709> [1] 00 >>>>>>> #3: (1) <0x703> [1] 00 >>>>>>> #4: (0) <0x706> [0] >>>>>>> #5: (0) <0x500> [1] 01 >>>>>>> #6: (0) <0x400> [1] 01 >>>>>>> #7: (0) <0x100> [1] 01 >>>>>>> #8: (0) <0x200> [1] 01 >>>>>>> #9: (0) <0x000> [1] 08 >>>>>>> #10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 >>>>>>> 04 08 >>>>>> Why is "addr.can_ifindex = 24"? Something is broken in you build. >>>>> In the xenomai build? how do I find out what? it all compiled well. >>>>> >>>>> I patched the driver before building tkernel with >>>>> 0001-rtcan-ems_pci-driver-update-to-support-more-devices.patch.gz >>>> Can you show me that patch. >>> See attachment. >>>>> I used the ipipe patch from the stable release, >>>>> >>>>> and then build it normally. >>>>> >>>>> Might the RX buf size that I changed a problem? >>>> What exactly did you change? I think "rtcanrecv" does not use it. >>>> >>>> Wolfgang >>> The kernel option CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE I at first I set it >>> to a wrong value 8096 but eve after I changed it to 8192 it didnt >>> change anythingand now i set it back to 1024 with no improvement either. >> Ah, a value of 8096 does make trouble, e.g. with expression like the >> following: >> >> sock->recv_tail = (sock->recv_tail + cpy_size) & >> (RTCAN_RXBUF_SIZE - 1); >> >> Could you please make a *clean* rebuild from scratch with a value 2^N, >> either 8192 or 1024. >> >> Wolfgang. > > Building the complete Kernel anew did the trick. Don't really understand > why re-building (and installing) just the module didn't work. > > Anyway, I'm happy that it works now. So, as a takeaway: Don't mess with > the CAN_RXBUF_SIZE. Yes, but also the code should check as much as possible... it's normal that the human being makes mistakes. Wolfgang ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2019-02-13 10:20 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-11 9:16 RTCan missing frames Johannes Holtz
2019-02-11 11:14 ` Philippe Gerum
2019-02-11 11:53 ` Johannes Holtz
2019-02-11 14:18 ` Johannes Holtz
[not found] ` <5f653b5a-e82f-ce42-c8c6-3fa05ccce53d@grandegger.com>
2019-02-11 11:55 ` Johannes Holtz
2019-02-11 12:40 ` Wolfgang Grandegger
2019-02-11 13:13 ` Johannes Holtz
2019-02-11 15:06 ` Wolfgang Grandegger
2019-02-11 15:12 ` Johannes Holtz
2019-02-11 16:46 ` Wolfgang Grandegger
2019-02-12 10:42 ` Johannes Holtz
2019-02-12 11:24 ` Wolfgang Grandegger
2019-02-12 11:35 ` Johannes Holtz
2019-02-12 14:38 ` Johannes Holtz
2019-02-12 15:00 ` Wolfgang Grandegger
2019-02-12 15:19 ` Johannes Holtz
2019-02-12 17:05 ` Wolfgang Grandegger
2019-02-12 17:24 ` Johannes Holtz
2019-02-12 17:53 ` Wolfgang Grandegger
2019-02-12 18:14 ` Steve Freyder
2019-02-12 18:20 ` Wolfgang Grandegger
2019-02-13 9:37 ` Johannes Holtz
2019-02-13 10:20 ` Wolfgang Grandegger
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.