MCP2518 SPI-CAN integration with nrf52840

[Midhunjac]

Hi,

I am using nrf52840 on a custom board. I have a MCP2518 to which I wish to communicate through the SPI interface. I changed the dts file accordingly and added the bindings and finally got it to build. The problem is I cannot access the SPI bus. My custom driver is based on the mc2518 driver that is part of NRF Connectv2.2.0 . I have modified it and removed everything except the initialization part where it checks if the devices and bus is ready. I have not started using that however. I cannot get an instance of the MCP2518 because the initialization fails. The failure point is where it checks whether the SPI bus is ready. Exactly this same position as described in this post. It seems like that question is inactive now. So I though I would raise this question here. I hope it is alright.

There are a few additional observations too. If i do device_is_ready() on the SPI bus instance from main() of my application, it returns success. However, if I do the same check in my custom driver module, right before the above failure point, I get failure. I dont know if this bit of info helps and I dont know why it behaves differently.

I would very much appreciate it if anyone could help.

device ; nrf52840

NCS v2.2.0

trying to interface mcp2518fd

[Midhunjac]

Okay. Did a little digging and found something.

By default CONFIG_CAN_INIT_PRIORITY is set to 50 and CONFIG_SPI_INIT_PRIORITY is set to 70.

Using these default values, CAN maybe initializing before SPI and thus, cannot find SPI bus during its initialization phase, buT later SPI becomes active and hence can be accessed from main().

In counter CAN example that I used as reference (included in NRF connect 2.2.0), CONFIG_CAN_INIT_PRIORITY is explicitly set to 80. Using the same logic as before, this time CAN initialized after SPI. So no problems were observed in the example.

The solution is obvious. Use CONFIG_CAN_INIT_PRIORITY numerically greater than CONFIG_SPI_INIT_PRIOIRTY so that SPI initializes first. But the problem is, whenever I attempt that I run into this error.

So effectively, I do not have any solutions even though I have a lot of findings.

Can someone help me with the issue ? I do not know if my observations are relevant to the issue, but I would really appreciate any help.

Thank you

[Håkon Alseth]

Hi,

 

The mcp2515 driver sets up a gpio callback, and can be the culprit of the assert.

What is the state of the GPIO driver at this point?

 

Have you tried entering debug mode, and placing a breakpoint at this assert line to see where it came from?

 

Kind regards,

Håkon

[Håkon Alseth]

Hi,

 

The zephyr,canbus device is not chosen. Could you try adding this to your "chosen" list?

zephyr,canbus = &mcp2518;

 

Kind regards,

Håkon

[Midhunjac]

Hi,

I tried that. But i didnt see any change in the behavior. I did not really expect to see much change in the behavior eithe since I am accessing the node like this in main.c

As far as I can tell, this is fine. right ? Or is there any other module looking for the zzephy_canbus as chosen ?

Also, can you confirm if I need CONFIG_SPI and CONFIG_CAN enabled in my prj.conf ? Since I am using a custom written kernel module, I am not sure if I should include them. But if I dont include both of them, I run into the previous linking error, even if I add the zephyr,canbus line in dts and make corresponding changes in the main.c

Thanks

[Håkon Alseth]

Hi,

 

Midhunjac said:

Also, can you confirm if I need CONFIG_SPI and CONFIG_CAN enabled in my prj.conf ?

Yes, those are needed.

Midhunjac said:

Since I am using a custom written kernel module, I am not sure if I should include them.

What do you mean by this? Do you mean a custom written application?

 

Does any of the can-samples in zephyr work as expected with your .overlay?

Remember to also include your INIT priority configuration to ensure that the ordering on boot is correct.

 

Kind regards,

Håkon

[Midhunjac]

Håkon Alseth said:

What do you mean by this? Do you mean a custom written application?

yes. The nordic samples implement MCP2515 driver. But I am working with MCP2518 and so, I am trying to get my kernel drivers ready for that.

Håkon Alseth said:

Does any of the can-samples in zephyr work as expected with your .overlay?

yes, I confirmed the working with dfrobot CAN shield. The counter example which works on loopback was implemented alright. Later I connected PCAN View too in CAN normal mode and verified the working.

Håkon Alseth said:

Remember to also include your INIT priority configuration to ensure that the ordering on boot is correct

that is done. I no longer have the problem with initialization it seems. For some reason however, my 2518 does not seem to be responding at all. I try writing and the whole application reboots. I try reading and all I get is 0xFF.

[Håkon Alseth]

Hi,

 

Midhunjac said:

yes, I confirmed the working with dfrobot CAN shield. The counter example which works on loopback was implemented alright. Later I connected PCAN View too in CAN normal mode and verified the working.

If the overlay, and SPI connection towards your sensor is verified to work, then it sounds like the MCP25xx integration isn't working for your specific device. Have you tried asking the zephyr community about this?

 

Kind regards,

Håkon

[Midhunjac]

Hi,

Sorry for the late reply. I have not asked the zephyr community about the issue. Before I do that, is there any way I can verify that my SPI bus is active ? When I read from an address of the MCP2518FD on my custom board, all I get is the value 255. I just wanted to know if it is because my SPI bus is not active or because there is something faulty with my device

Thanks.

[Håkon Alseth]

Hi,

 

Midhunjac said:

When I read from an address of the MCP2518FD on my custom board, all I get is the value 255

This indicates that you have a connection problem. Scope your SPI pins using a logic analyzer and have a look at the signals. You previously mentioned having working setups:

Midhunjac said:

yes, I confirmed the working with dfrobot CAN shield. The counter example which works on loopback was implemented alright. Later I connected PCAN View too in CAN normal mode and verified the working.

Try to scope both a working scenario and a non-working scenario (ie. with your MCP2518) and compare the results.

 

Kind regards,

Håkon

[Midhunjac]

Thanks for your inputs. I will take a look at these and come back.

Thanks again.

[Midhunjac]

Hi,

I wanted to get your expert opinion about something. Recently, for the sake of debugging, I though of using nrf 52DK with mcp2518 breakout board. I made necessary changes in the dts for the 52dk.

Except for the flash paritions, the dts file contents of the nrf52dk look similar to the the 52840 board I am using. But when I try to build the application for the DK, the build fails with this error 'undefined reference to '__device_dts_ord_94''.in the the mcp2518 driver. And the build log showed a warning that it could not find any SPI driver. The error was solved only after I used menuconfig to add SPI driver and enabled support for PAN 58 (I dont know what this is) . But none of these steps were necessary for the 52840 build.

Do you think that the build for 52840 somehow skipped the SPI driver things without a warning or a message and maybe that is why the communication fails ? What is your opinion about these errors showing up only for the nrf52832 DK ?

Thanks

[Håkon Alseth]

Hi,

 

Midhunjac said:

What is your opinion about these errors showing up only for the nrf52832 DK ?

For the nRF52832, there is an errata on the SPIM peripheral:

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev3/ERR/nRF52832/Rev3/latest/anomaly_832_58.html?cp=5_2_1_0_1_8

 

workaround specifically for nRF52832 is to use the "nrf-spi" module instead, as shown earlier in this thread:

 RE: MCP2518 SPI-CAN integration with nrf52840 

 

Kind regards,

Håkon