MCP2518 SPI-CAN integration with nrf52840

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

Parents
  • 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

  • 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

  • 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

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

    Thanks again.

  • 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

  • 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

  • Hi,

    Thank you for your advice. It worked. I forgot about the errata. sorry about that!!

    Thanks again.

Reply Children
Related