USB-CAN does not receive data

[Ciusss89]

I've v7.10 of the USB-CAN Analyer:

1. CAN adapter : QinHeng Electronics HL-340 USB-Serial adapter
2. CAN Identifier : 1a86:7523

I compiled your code, and I'm running it to foreground

sudo ./usbcan -p -s 500000 -d /dev/ttyUSB4 -t -F
[7] Running in foreground process
>>> aa 55 12 03 01 00 00 00 00 00 00 00 00 00 01 00 00 00 00 17 
[7] Serial adapter to vcan handler running...
<<< 
dlc = 3, data = 786999
>>> aa c3 00 00 78 69 99 55 

at the same time, I started can traffic generator.

cangen slcan0 -v  -I 0x000 -g 100
  slcan0  000#06.8C.D3.21.F3.1C.DE.63
  slcan0  000#11.6F.3D.0E.5C.D1.53
  slcan0  000#19.08.F0.79.C2.26.AB.15
  slcan0  000#34.69.91.3D
  slcan0  000#E9.3A.1A.2E.EE.AA.4F.7A
  slcan0  000#53.C9.A2.53
  slcan0  000#2D.71.A6.30.56
  slcan0  000#6F.28.6E.2A.94.FD.02.07
  slcan0  000#FD.69.E5.4F.4D.D1.FC.11
  slcan0  000#E4.8F.5D.07.B1.6C
  slcan0  000#3D.2D.89.23.B7.F8.DB.12
  slcan0  000#C4.B1.30.5B.C8.67.19.21
  slcan0  000#B4.64.84.1F.E2.6F.09.1B
  slcan0  000#C8.D0.61.73.16.D9.9A.58
  slcan0  000#C7.71
  slcan0  000#0B

I've two microcontrollers with RIOT-OS running, they are connected to the same CAN bus, they can communicate with each other but doesn't receive any data from the USB adapter, (the CAN MCU to MCU connectivity works fine)

Note:

1. the tx's led doesn't blink
2. the TTY's serial traffic seems not to follow the cangen..
3. ifconfig slcan0 has the (traffic) stats update.
4. It's like if something doesn't work

[alexmohr]

Please check if the baudrate you've set is correct and the bus is properly terminated. Also sending data does not work properly at the moment as incomming messages are duplicated see #5

[Ciusss89]

Please check if the baudrate you've set is correct and the bus is properly terminated. Also sending data does not work properly at the moment as incomming messages are duplicated see #5

1. Bus termination is ok because I tested that the MCU (with RIOT-OS) shows the incoming frame when the USB-CAN is handled by windows app.
2. I tested various speed.

Before to test your code I did a run with slcand, and IMHO i've the same problem.

If you start the cangen when you are using usbcan with -t option I'm aspect to have visual feedback (-t spams on stdout the incoming message from cangen)?

It's like if the MCU's USB-CAN adapter doesn't route the incoming traffic toward to CAN peripheral

[alexmohr]

If you start the cangen when you are using usbcan with -t option I'm aspect to have visual feedback (-t spams on stdout the incoming message from cangen)?

Thats right it is be possible that I've broken the transmission of data in a commit or two before. You can try out the feature branch I've added today. I'm currently not at home so I cannot reproduce your issue.

Does receiving data work?

[Ciusss89]

I don't know if the problem is your tool, slcand has the same behaviour. I don't how I can debug it. Do you remember the version of your USB-CAN adapter?

[alexmohr]

slcan is not compatible with the serial protocol this adapter uses the whole reason for this project is to bridge this device to the standard can utils. I don't remember what version my device has. To debug it might be best to checkout the feature branch of this project. If you don't need to be compatible with the can utils you can also try out the original project. I will take a closer look at it in the next couple of weeks.

[Ciusss89]

thanks, I'll update you.

[Ciusss89]

I did some tests and your last commit 0ea89399d brokes all:

1. you can send/receive only one frame
2. signal is ignored

I'm using the app before 0ea89399d and all is working fine.

[alexmohr]

Thanks for the update! I've reverted the commit and will provide a proper fix for the data receiving in the next week or so.

[Ciusss89]

I did some fix but the code need refactoring. I'm working with CAN2A (dlc max 8):

Issue 1. When dlc of frame is equal to 8, it crash.

~/mcu/gtip-riotos/test_04/tools/_usbcan ((e2ecc24f1dcd...)) $ sudo ./build/usbcan -p -s 500000 -d /dev/ttyUSB0 -t -F
>>> aa 55 12 03 01 00 00 00 00 00 00 00 00 00 01 00 00 00 00 17 
<<< aa c7 23 00 01 02 03 04 05 06 07 55 
frame_len12 4
91350.332824 Frame ID: 23, Data: 01020304050607
DEBUG can:>>>>>> cansend slcan0 023#01020304050607
dlc = 7, data = 01020304050607
>>> aa c7 23 00 01 02 03 04 05 06 07 55 
<<< aa c7 23 00 01 02 03 04 05 06 07 55 
frame_len12 4
91352.483882 Frame ID: 23, Data: 01020304050607
DEBUG can:>>>>>> cansend slcan0 023#01020304050607
dlc = 7, data = 01020304050607
>>> aa c7 23 00 01 02 03 04 05 06 07 55 
<<< aa c5 23 00 01 02 03 04 05 55 
frame_len10 4
91359.448430 Frame ID: 23, Data: 0102030405
DEBUG can:>>>>>> cansend slcan0 023#0102030405
dlc = 5, data = 0102030405
>>> aa c5 23 00 01 02 03 04 05 55 
<<< aa c7 23 00 01 02 03 04 05 06 07 55 
frame_len12 4
91361.010117 Frame ID: 23, Data: 01020304050607
DEBUG can:>>>>>> cansend slcan0 023#01020304050607
dlc = 7, data = 01020304050607
>>> aa c7 23 00 01 02 03 04 05 06 07 55 
<<< aa c8 23 00 01 02 03 04 05 06 07 08 55 
frame_len13 4
91364.528782 Frame ID: 23, Data: 0102030405060708
DEBUG can:>>>>>> cansend slcan0 023#0102030405060708cansend slcan0 023#
Usage: cansend <device> <can_frame>.
[3] failed to send data via can:>>>>>> cansend slcan0 023#0102030405060708cansend slcan0 023#

Issue 2: sometime this happens.

~/mcu/gtip-riotos/test_04/tools/_usbcan (TEST) $ sudo ./build/usbcan -p -s 500000 -d /dev/ttyUSB0 -t -F
[sudo] password for giuseppe: 
>>> aa 55 12 03 01 00 00 00 00 00 00 00 00 00 01 00 00 00 00 17 
<<< aa c8 23 00 01 02 03 04 05 06 07 08 55 
97409.622957 Frame ID: 23, Data: 0102030405060708
[7] Not sending message which has been received.
<<< aa c8 23 00 01 02 03 04 05 06 07 08 55 
97412.439707 Frame ID: 23, Data: 0102030405060708
[7] Not sending message which has been received.
<<< aa c8 23 00 01 02 03 04 05 06 07 08 55 
97413.556065 Frame ID: 23, Data: 0102030405060708
[7] Not sending message which has been received.
<<< aa c8 23 00 01 02 03 04 05 06 07 08 55 
97414.737728 Frame ID: 23, Data: 0102030405060708
[7] Not sending message which has been received.
<<< aa c8 23 00 01 02 03 04 05 06 07 08 55 
97416.121374 Frame ID: 23, Data: 0102030405060708
[7] Not sending message which has been received.

I came back to 8753527cee62, and I'm using this patch to fix 1:

~/mcu/gtip-riotos/test_04/tools/_usbcan (TEST) $ git diff
diff --git a/src/canusb.c b/src/canusb.c
index ddea8ff1bf1c..36b1747a1a42 100644
--- a/src/canusb.c
+++ b/src/canusb.c
@@ -1,3 +1,4 @@
+#define _GNU_SOURCE
 #include <stdlib.h>
 #include <string.h>
 #include <stdio.h>
@@ -288,7 +289,7 @@ unsigned int get_frame_id(const unsigned char *frame, const CANUSB_FRAME_TYPE ty
 void serial_adapter_to_can(CANUSB_FRAME_TYPE type, char *adapter_name) {
     int i, c = 0, frame_len = 0;
     unsigned char frame[32];
-    char buf[256];
+    char *cmd;
     char dbuf[16];

     int offset = 2;
@@ -333,11 +334,14 @@ void serial_adapter_to_can(CANUSB_FRAME_TYPE type, char *adapter_name) {
                 }

                 // send data via can
-                snprintf(buf, sizeof buf, "%s %s %02x#%s", "cansend", adapter_name, frame_id, dbuf);
-                c = system(buf);
+                asprintf(&cmd, "%s %s %03x#%s", "cansend", adapter_name, frame_id, dbuf);
+                if(c < 0)
+                    sys_logger(LOG_ERR, "asprintf has failed");
+                c = system(cmd);
                 if (c != 0) {
-                    sys_logger(LOG_ERR, "failed to send data via can");
+                    sys_logger(LOG_ERR, "cansend failure: input=[%s]", cmd);
                 }
+                free(cmd);
             }
         }
     }
~/mcu/gtip-rio

[alexmohr]

Looks good at a quick glance. Unfortunately I'm still not in reach of my device to test. But please open a pull request if this works for you. The second issue is on purpose but I suppose it is not working as intended. The way this is implemented we cannot distinguish between messages this application wrote to the virtual can interface because it has been received and a message which has been written by a user to send a frame. The application prints this message when it detected a message which has been received and there should not be send again via the serial interface. The logic in the version you currently use is broken and I've added a new branch to probably fix the behaviour it is just not tested yet.

[alexmohr]

It would be great if you could create a PR with the patch you've send to the rework branch.

[Ciusss89]

Yeah, I'll do. I can help you with fix and test. DO you know when you will able to work on it?

IMHO you have to create the stable branch and dev cleaning also the commit history, There are a lot of revert, and commit are too big.

[alexmohr]

I've changed my mind about this project a bit to be honest. The way this is implemented will always be a dirty hack that will never work properly. I started working on a rewrite with a proper kernel module based on serial can. I believe it mostly will be necessary to change the protocol which is used on the serial line.

I'm currently on it but it will take me a day or so to get it running again.

[alexmohr]

@Ciusss89 I finished porting the slcan utils to this adapter. I'll probably be able to test it with my device in 1-2 weeks. If you are interesseted you can try it out but use with caution as the kernel driver is not properly tested yet it could lock up your system.

[Ciusss89]

I was busy, I can test it. Do u have a new code into a github repo?

[alexmohr]

There is no new repo just checkout the feature/kernel-driver branch. The updated readme should describe everything :)

[Ciusss89]

Insmod fails with: insmod: ERROR: could not insert module hlcan.ko: Invalid parameters

We can switch toward a chat system to improve the speed of replays, I sent to you an email..