nRF9160: MCP2515 SPI bus not ready

RE: nRF9160: MCP2515 SPI bus not ready

Midhunjac — Tue, 14 Mar 2023 12:10:31 GMT

Thanks for replying. I hope they will attend this thread once again.

RE: nRF9160: MCP2515 SPI bus not ready

yavordobrev — Tue, 14 Mar 2023 12:07:32 GMT

I gave up on trying to get it to work and used a small microcontroller for interfacing SPI to CAN instead. I have not contacted Zephyr support as was suggested.

RE: nRF9160: MCP2515 SPI bus not ready

Midhunjac — Tue, 14 Mar 2023 11:55:59 GMT

Is this issue solved ? I have the same problem now with nrf52840. I am using a custom board with mcp2518FD. I have modified the dts and added bindings and the build is successful. If I do not have can bus definition in dts, I have no problem in initializing the SPI bus. (have not checked the communication though). As soon as I bring in the CAN transciever, SPI bus will not be initialized. Any ideas of what might be going wrong ?

RE: nRF9160: MCP2515 SPI bus not ready

Albrecht Markus Schellenberger — Thu, 09 Jun 2022 08:37:42 GMT

Hello Yavor,

I’m honestly running out of ideas here. At this stage, I would recommend you get in touch with the Zephyr support. They have an own #can-bus channel on Discord.

I suggest we leave this ticket open for possible follow-up questions, but I expect that Zephyr can provide you with more detailed input as they are owning the functionality.

Regards,

Markus

RE: nRF9160: MCP2515 SPI bus not ready

yavordobrev — Wed, 08 Jun 2022 07:21:25 GMT

The hard fault occurs with the non-secure target.

With the secure target I get the stack overflow, which was described earlier.

I tried physically attaching a CAN bus, but it makes no difference.

RE: nRF9160: MCP2515 SPI bus not ready

Albrecht Markus Schellenberger — Wed, 08 Jun 2022 07:10:10 GMT

Hello Yavor,

[quote user="yavordobrev"]Do you have any suggestions what I could try?[/quote]

Are you currently using the secure or none-secure target?

Regards,

Markus

RE: nRF9160: MCP2515 SPI bus not ready

yavordobrev — Tue, 07 Jun 2022 11:54:27 GMT

Hi Markus,

I tested a little more but I couldn't find the reason for the hard fault.

Stepping through the program leads me to line 124 in mutex.c, where the hard fault occurs.

Do you have any suggestions what I could try?

Regards
Yavor

RE: nRF9160: MCP2515 SPI bus not ready

Albrecht Markus Schellenberger — Fri, 03 Jun 2022 11:09:18 GMT

[quote user="yavordobrev"]

I managed to get a little further. First of all I resolved the "SPI bus not ready"-error in the ns-build by adding

CONFIG_SPI_INIT_PRIORITY=20

[/quote]

Thanks for the feedback, Yavor! I tested the other way round, lowering CONFIG_CAN_INIT_PRIORITY to 80, but ended up in a hard fault as well.

[quote user="yavordobrev"]Why this is different in the secure build I can't say.[/quote]

I’m not expecting this to happen neither, since the none-secure part actually should be initialised first.

Regards,

Markus

RE: nRF9160: MCP2515 SPI bus not ready

yavordobrev — Fri, 03 Jun 2022 08:32:57 GMT

Hi Markus,

I managed to get a little further. First of all I resolved the "SPI bus not ready"-error in the ns-build by adding

CONFIG_SPI_INIT_PRIORITY=20

to the prj.conf. This way the SPI is initialized before the MCP2515. Why this is different in the secure build I can't say.

Then I had to apply the patches from this thread, but all I get in the end is a Hard Fault.

I will continue testing on Tuesday...

RE: nRF9160: MCP2515 SPI bus not ready

Albrecht Markus Schellenberger — Fri, 03 Jun 2022 06:39:44 GMT

The faulting instruction address is 0xaaaaaaaa, which is outside of memory. I’m not sure if this is due to missing CAN bus, or that non-secure domain actually is required to run network socket operations on the nRF9160.

If you physically connect a CAN bus, would that make any difference?

Regards,

Markus

RE: nRF9160: MCP2515 SPI bus not ready

yavordobrev — Thu, 02 Jun 2022 13:45:42 GMT

I can confirm that building as a secure target does not cause the "SPI not ready" problem.

However I end up getting a stack overflow. It happens in the recvfrom function (line 208 in main.c).

There is no real CAN bus currently attached, only the MCP2515.

RE: nRF9160: MCP2515 SPI bus not ready

Albrecht Markus Schellenberger — Thu, 02 Jun 2022 12:24:20 GMT

[quote user="yavordobrev"]Could it be that the mcp2515 driver is trying to use spi before it is actually initialized? [/quote]

Yes, that appears to be the case. If I run the sample as a secure target (nrf9160dk_nrf9160), the output looks a little bit different.

*** Booting Zephyr OS build v2.7.99-ncs1-1  *** 

[00:00:02.288,177] <dbg> net_sock_can.can_register_filters: (main): Registering 1 filters 
[00:00:02.298,980] <dbg> net_sock_can.can_register_receiver: (main): Max 1 receivers 
[00:00:02.309,448] <dbg> net_socket_can_sample.setup_socket: Started socket CAN TX thread 
[00:00:02.320,220] <inf> net_socket_can_sample: 1st RX fd 0 
[00:00:02.328,430] <dbg> net_socket_can_sample.rx: [0] Waiting CAN data... 
[00:00:03.309,509] <dbg> net_socket_can_sample.tx: Sending CAN data... 
[00:00:06.420,379] <dbg> mcp2515_can.socket_can_send: Cannot send socket CAN msg (-11)

Can you test this as well and confirm that it works?

In that case: I assume this is a timing issue with the Secure Partition Manager.

Regards,

Markus

RE: nRF9160: MCP2515 SPI bus not ready

yavordobrev — Thu, 02 Jun 2022 09:35:10 GMT

I just tried what you proposed and the board just hangs in the spi_nrfx_transceive function. The logic analyzer shows there is also no activity on the pins.

Could it be that the mcp2515 driver is trying to use spi before it is actually initialized?

RE: nRF9160: MCP2515 SPI bus not ready

Albrecht Markus Schellenberger — Thu, 02 Jun 2022 09:12:55 GMT

[quote user="yavordobrev"]

I am using NCS v1.9.1. The build errors have been resolved in this thread.

It is suggested to edit zephyr/drivers/can/can_mcp2515.c, line 970, and replace the 1 with a 0.

[/quote]

Ok, thanks Yavor! That being said, I should have read through the whole thread first ;-)

The sample is failing at this point. When I debug into the function, the line below gives me the reason why it is failing.

I’m not sure why 'initialised' would be false here, as the devicetree should be configured correctly. But I do not have a MCP2515 available which I can connect to my DK, so possibly this might be required.

Otherwise, just for fault tracing, if you toggle the following lines:

// if (!spi_is_ready(&dev_cfg->bus)) { 
// LOG_ERR("SPI bus %s not ready", dev_cfg->bus.bus->name); 
// return -ENODEV; 
// }

Does that make communication work, or do you end up in another fault?

Regards,

Markus

RE: nRF9160: MCP2515 SPI bus not ready

yavordobrev — Thu, 02 Jun 2022 08:18:07 GMT

Hello Markus,

I am using NCS v1.9.1. The build errors have been resolved in this thread.

It is suggested to edit zephyr/drivers/can/can_mcp2515.c, line 970, and replace the 1 with a 0.

RE: nRF9160: MCP2515 SPI bus not ready

Albrecht Markus Schellenberger — Thu, 02 Jun 2022 07:57:23 GMT

Hello Yavor,

which NCS version are you currently operating with? I’m asking because the Socket CAN sample with your overlay file won't even build for me in NCS v1.9.1.

In file included from /home/user/ncs/zephyr/include/toolchain/gcc.h:72,
                 from /home/user/ncs/zephyr/include/toolchain.h:50,
                 from /home/user/ncs/zephyr/include/kernel_includes.h:19,
                 from /home/user/ncs/zephyr/include/kernel.h:17,
                 from /home/user/ncs/zephyr/drivers/can/can_mcp2515.c:9:
/home/user/ncs/zephyr/drivers/can/can_mcp2515.c: In function 'socket_can_init':
/home/user/ncs/zephyr/include/device.h:96:39: error: '__device_dts_ord_DT_N_INST_1_microchip_mcp2515_ORD' undeclared (first use in this function)
   96 | #define DEVICE_NAME_GET(name) _CONCAT(__device_, name)
      |                                       ^~~~~~~~~
/home/user/ncs/zephyr/include/toolchain/common.h:132:26: note: in definition of macro '_DO_CONCAT'
  132 | #define _DO_CONCAT(x, y) x ## y
      |                          ^
/home/user/ncs/zephyr/include/device.h:96:31: note: in expansion of macro '_CONCAT'
   96 | #define DEVICE_NAME_GET(name) _CONCAT(__device_, name)
      |                               ^~~~~~~
/home/user/ncs/zephyr/include/device.h:291:37: note: in expansion of macro 'DEVICE_NAME_GET'
  291 | #define DEVICE_DT_NAME_GET(node_id) DEVICE_NAME_GET(Z_DEVICE_DT_DEV_NAME(node_id))
      |                                     ^~~~~~~~~~~~~~~
/home/user/ncs/zephyr/include/device.h:311:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
  311 | #define DEVICE_DT_GET(node_id) (&DEVICE_DT_NAME_GET(node_id))
      |                                  ^~~~~~~~~~~~~~~~~~
/home/user/ncs/zephyr/include/device.h:323:34: note: in expansion of macro 'DEVICE_DT_GET'
  323 | #define DEVICE_DT_INST_GET(inst) DEVICE_DT_GET(DT_DRV_INST(inst))
      |                                  ^~~~~~~~~~~~~
/home/user/ncs/zephyr/drivers/can/can_mcp2515.c:945:33: note: in expansion of macro 'DEVICE_DT_INST_GET'
  945 |  const struct device *can_dev = DEVICE_DT_INST_GET(1);
      |                                 ^~~~~~~~~~~~~~~~~~
/home/user/ncs/zephyr/include/device.h:96:39: note: each undeclared identifier is reported only once for each function it appears in
   96 | #define DEVICE_NAME_GET(name) _CONCAT(__device_, name)
      |                                       ^~~~~~~~~
/home/user/ncs/zephyr/include/toolchain/common.h:132:26: note: in definition of macro '_DO_CONCAT'
  132 | #define _DO_CONCAT(x, y) x ## y
      |                          ^
/home/user/ncs/zephyr/include/device.h:96:31: note: in expansion of macro '_CONCAT'
   96 | #define DEVICE_NAME_GET(name) _CONCAT(__device_, name)
      |                               ^~~~~~~
/home/user/ncs/zephyr/include/device.h:291:37: note: in expansion of macro 'DEVICE_NAME_GET'
  291 | #define DEVICE_DT_NAME_GET(node_id) DEVICE_NAME_GET(Z_DEVICE_DT_DEV_NAME(node_id))
      |                                     ^~~~~~~~~~~~~~~
/home/user/ncs/zephyr/include/device.h:311:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
  311 | #define DEVICE_DT_GET(node_id) (&DEVICE_DT_NAME_GET(node_id))
      |                                  ^~~~~~~~~~~~~~~~~~
/home/user/ncs/zephyr/include/device.h:323:34: note: in expansion of macro 'DEVICE_DT_GET'
  323 | #define DEVICE_DT_INST_GET(inst) DEVICE_DT_GET(DT_DRV_INST(inst))
      |                                  ^~~~~~~~~~~~~
/home/user/ncs/zephyr/drivers/can/can_mcp2515.c:945:33: note: in expansion of macro 'DEVICE_DT_INST_GET'
  945 |  const struct device *can_dev = DEVICE_DT_INST_GET(1);
      |                                 ^~~~~~~~~~~~~~~~~~
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/user/work/VSCode/can_app/build
The terminal process terminated with exit code:

I’m not sure why the compiler throws this error, because the overlay file you are using appears to be correct to me.

Regards,

Markus