This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

sample net_sockets_can does not start correctly

Hi I try to build the sample 

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.7.1/zephyr/samples/net/sockets/can/README.html

but i get this this error.

*** Booting Zephyr OS build v2.6.99-ncs1-1 ***
Flash regions Domain Permissions
00 01 0x00000 0x10000 Secure rwxl
02 31 0x10000 0x100000 Non-Secure rwxl

Non-secure callable region 0 placed in flash region 1 with size 32.

SRAM region Domain Permissions
00 07 0x00000 0x10000 Secure rwxl
08 31 0x10000 0x40000 Non-Secure rwxl

Peripheral Domain Status
00 NRF_P0 Non-Secure OK
01 NRF_CLOCK Non-Secure OK
02 NRF_RTC0 Non-Secure OK
03 NRF_RTC1 Non-Secure OK
04 NRF_NVMC Non-Secure OK
05 NRF_UARTE1 Non-Secure OK
06 NRF_UARTE2 Secure SKIP
07 NRF_TWIM2 Non-Secure OK
08 NRF_SPIM3 Non-Secure OK
09 NRF_TIMER0 Non-Secure OK
10 NRF_TIMER1 Non-Secure OK
11 NRF_TIMER2 Non-Secure OK
12 NRF_SAADC Non-Secure OK
13 NRF_PWM0 Non-Secure OK
14 NRF_PWM1 Non-Secure OK
15 NRF_PWM2 Non-Secure OK
16 NRF_PWM3 Non-Secure OK
17 NRF_WDT Non-Secure OK
18 NRF_IPC Non-Secure OK
19 NRF_VMC Non-Secure OK
20 NRF_FPU Non-Secure OK
21 NRF_EGU1 Non-Secure OK
22 NRF_EGU2 Non-Secure OK
23 NRF_DPPIC Non-Secure OK
24 NRF_REGULATORS Non-Secure OK
25 NRF_PDM Non-Secure OK
26 NRF_I2S Non-Secure OK
27 NRF_GPIOTE1 Non-Secure OK

SPM: NS image at 0x10000
SPM: NS MSP at 0x200182b8
SPM: NS reset vector at 0x17071
SPM: prepare to jump to Non-Secure image.


[00:00:00.201,782] <dbg> mcp2515_can.socket_can_init: Init socket CAN device 0x2 a680 (SOCKET_CAN_1) for dev 0x2a6b0 (CAN_1)
[00:00:00.217,376] <dbg> net_core.net_init: (main): Priority 90
[00:00:00.225,982] <dbg> net_core.l3_init: (main): Network L3 init done
[00:00:00.235,290] <dbg> mcp2515_can.socket_can_iface_init: Init CAN interface 0 x200149f8 dev 0x2a680
uart:~$ *** Booting Zephyr OS build v2.6.99-ncs1-1 ***
[00:00:00.252,014] <inf> net_socket_can_sample: sleeping for 2 seconds
[00:00:02.261,352] <err> net_socket_can_sample: Cannot create 1st CAN socket (-106)
[00:00:02.271,972] <err> net_socket_can_sample: Cannot start CAN application (-106)
uart:~$

Parents
  • Hi Tomas

    The CAN library doesn't work unless you have a board that supports it. 

    The library uses the MCP2515 CAN driver, which is not available on the nRF9160DK. 

    The Requirements section in the sample readme lists the supported boards. 

    Best regards
    Torbjørn

  • Hi and thank you for the answer. 
    I have added a MCP2515 can module to my board.

    My installed shield

    In the text bellow i belive the four first line  the candrive are started. (CAN_1)

    what could be the reason for the errors on the two last lines ?

      

  • net_sockets_can.zip

    Hi Torbjörn, Please see enclosed file as a copy of my folder.
    Hopefully you can reproduce the error .
    Please note that i have made the modification as sugested by your college as in the pic bellow.

  • Any feedback on this topic?
    I m currently integrating MCP2515 on the nrf9160 and dealing with the same issue. 

    However, I did not get the compiler error. Just stayed with the same -106 error after making the suggested changes on nrf91_socket.c and sockets CMakeList.txt

  • Hi 

    Neither the developer nor myself was able to reproduce the build error you got earlier. 

    rfc said:
    However, I did not get the compiler error. Just stayed with the same -106 error after making the suggested changes on nrf91_socket.c and sockets CMakeList.txt

    Maybe there is something I missed, but what was the difference between this test, and the test where you got the build error?

    Best regards
    Torbjørn

  • Hi Torbjörn 
    The last comment was not from me . It was form someone else (with user name rfc) that also is following this topic with intrest as he has the same issue. :-)  / Tomas

  • I hereby confirm, I am not T.B-D but I am having a similar issue. 
    I was able to compile the code and use the CAN socket, but am still having issues with the CAN transmission. I wanted to do some checks to our HW before posting any conclusion to discard any HW problem. 

    On the meanwhile and since you replied, I was able to partially solve the issue by directly rejecting the AF_CAN socket family in the nrf91_socket_is_supported() so that other registered socket handlers can be checked. Note that for this to happen you have to apply the fix above mentioned to the zephyr\subsys\net\lib\sockets\CMakeLists.txt.

    I attached my nrf91_socket_is_supported(). Not the best solution and I wouldn't keep it as definitive fix, but it was enough for my current needs. I would appreciate if you could post a definitive fix for this issue for the next SDK version. 

    Also had to make the CMakesList.txt update you suggested before. 


    static bool nrf91_socket_is_supported(int family, int type, int proto)
    {
    	if (offload_disabled) {
    		return false;
    	}
    
    	if (tls_offload_disabled && proto_is_secure(proto)) {
    		return false;
    	}
    
        if (family == AF_CAN) { //TBD fix for general case instead of CAN only
            return false;
        }
    
    	return true;
    }


Reply
  • I hereby confirm, I am not T.B-D but I am having a similar issue. 
    I was able to compile the code and use the CAN socket, but am still having issues with the CAN transmission. I wanted to do some checks to our HW before posting any conclusion to discard any HW problem. 

    On the meanwhile and since you replied, I was able to partially solve the issue by directly rejecting the AF_CAN socket family in the nrf91_socket_is_supported() so that other registered socket handlers can be checked. Note that for this to happen you have to apply the fix above mentioned to the zephyr\subsys\net\lib\sockets\CMakeLists.txt.

    I attached my nrf91_socket_is_supported(). Not the best solution and I wouldn't keep it as definitive fix, but it was enough for my current needs. I would appreciate if you could post a definitive fix for this issue for the next SDK version. 

    Also had to make the CMakesList.txt update you suggested before. 


    static bool nrf91_socket_is_supported(int family, int type, int proto)
    {
    	if (offload_disabled) {
    		return false;
    	}
    
    	if (tls_offload_disabled && proto_is_secure(proto)) {
    		return false;
    	}
    
        if (family == AF_CAN) { //TBD fix for general case instead of CAN only
            return false;
        }
    
    	return true;
    }


Children
  • Hi rfc

    Did you try to apply the pull request I linked to earlier? 

    It is a slightly different version of the fix you shared, and this one should be integrated in a future SDK update. 

    Back to you Tomas (sorry for the confusion), are you still struggling to build the example? 

    Could you try a pristine build and see if that fixes the problem?

    Best regards
    Torbjørn

  • Hi Torborn.
    With the above sugestion from rfc im able to compile and have the canbus starting now.
    I have a machine sending data  (CAN 2.0) with a speed of 250.000 
    But as you see it seems that i´m not reciving data.
    Any sugestion what to cange ?

    Owerlay:

    /*
     * Copyright (c) 2020, Nordic Semiconductor ASA
     *
     * SPDX-License-Identifier: Apache-2.0
     */
    
    /* Example configuration of a MCP2515 cancontrol device */
    
    
    &spi3 {
        status = "okay";
        sck-pin = <10>;
        mosi-pin = <11>;
        miso-pin = <12>;
        cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
      
        can1: mcp2515@0 {
          compatible = "microchip,mcp2515";
    		spi-max-frequency = <1000000>;
    		/*int-gpios = <31>; /* D2 */
            int-gpios = <&gpio0 31 GPIO_ACTIVE_LOW>; /* D2 */
    		status = "okay";
    		label = "CAN_1";
    		reg = <0x0>;
    		osc-freq = <16000000>;
    		bus-speed = <250000>;
    		sjw = <1>;
    		prop-seg = <2>;
    		phase-seg1 = <7>;
    		phase-seg2 = <6>;
    		#address-cells = <1>;
    		#size-cells = <0>;
        };
      };
     
    
    / {
    	aliases {
    		can-primary = &can1;
    	};
    };

    From terminal:

    [00:00:00.201,599] <dbg> mcp2515_can.socket_can_init: Init socket CAN device 0x2                                                                                                                                                             a668 (SOCKET_CAN_1) for dev 0x2a698 (CAN_1)
    [00:00:00.217,041] <dbg> net_core.net_init: (main): Priority 90
    [00:00:00.225,677] <dbg> net_core.l3_init: (main): Network L3 init done
    [00:00:00.234,985] <dbg> mcp2515_can.socket_can_iface_init: Init CAN interface 0                                                                                                                                                             x20014a08 dev 0x2a668
    uart:~$ *** Booting Zephyr OS build v2.7.0-ncs1  ***
    [00:00:00.251,434] <inf> net_socket_can_sample: sleeping for 3 seconds
    [00:00:03.260,833] <dbg> net_ctx.net_context_bind: (main): Context 0x200154d8 binding to 1 iface[2] 0x20014a08
    [00:00:03.273,620] <dbg> net_conn.conn_register_debug: (main): [0x20015974/1/4/0x05] remote -/0
    [00:00:03.285,125] <dbg> net_conn.conn_register_debug: (main):   local ?/0 cb 0x17901 ud (nil)
    [00:00:03.296,508] <dbg> net_sock_can.can_register_filters: (main): Registering 1 filters
    [00:00:03.307,403] <dbg> net_sock_can.can_register_receiver: (main): Max 1 receivers
    [00:00:03.317,962] <dbg> net_socket_can_sample.setup_socket: Started socket CAN TX thread
    [00:00:03.328,857] <inf> net_socket_can_sample: 1st RX fd 0
    [00:00:03.337,127] <dbg> net_socket_can_sample.rx: [0] Waiting CAN data...
    [00:00:04.317,993] <dbg> net_socket_can_sample.tx: Sending CAN data...
    uart:~$
    

  • Hi rfc
    Thank you for your support 

    Regards Tomas

  • Hi 

    Have you been able to send data successfully?

    Have you checked if there is any communication happening over the SPI bus after the CAN data is starting to arrive?

    As a general note you might want to open a new ticket for this different problem, since the devzone is not well optimized for long running threads covering multiple different topics. 

    Best regards
    Torbjørn

Related