INT pin not working in LoopBackDemo example

[wavejaco]

Hi Pierre

I am trying to use your library for an MCP2515 connected to a Raspberry Pi Pico. Using your LoopBackDemo sketch (among others), it seems that the configuration of the MCP2515 runs fine.

However, when it comes to transmitting and receiving frames, it only prints "Sent: 1" up to "Sent: 17". As you explain in the sketch's comments, this indicates to be a problem with the interrupt. I have checked the INT pin on the MCP2515 with an oscilloscope while running the sketch, and it doesn't generate an interrupt on that pin. Could there perhaps be something that is not configured correctly when the MCP2515 is initialised?

I see that in the function internalBeginOperation() you write the value 0x1F to register CANINTE, which enables the TX and RX interrupts, so I would expect the interrupt to work when the frames are sent. However, this doesn't happen.

My test is performed using a 12 MHz crystal and the Raspberry Pi Pico. The same test performed with an Arduino Due has the same result.

What could be the cause of this?

Thank you in advance.

[pierremolinaro]

Hi,

Is the MCP2515 is alone on the CAN Bus ?

Pierre

Le 28 oct. 2022 à 16:06, wavejaco @.***> a écrit :

Hi Pierre

I am trying to use your library for an MCP2515 connected to a Raspberry Pi Pico. Using your LoopBackDemo sketch (among others), it seems that the configuration of the MCP2515 runs fine.

However, when it comes to transmitting and receiving frames, it only prints "Sent: 1" up to "Sent: 17". As you explain in the sketch's comments, this indicates to be a problem with the interrupt. I have checked the INT pin on the MCP2515 with an oscilloscope while running the sketch, and it doesn't generate an interrupt on that pin. Could there perhaps be something that is not configured correctly when the MCP2515 is initialised?

I see that in the function internalBeginOperation() you write the value 0x1F to register CANINTE, which enables the TX and RX interrupts, so I would expect the interrupt to work when the frames are sent. However, this doesn't happen.

My test is performed using a 12 MHz crystal and the Raspberry Pi Pico. The same test performed with an Arduino Due has the same result.

What could be the cause of this?

Thank you in advance.

— Reply to this email directly, view it on GitHub https://github.com/pierremolinaro/acan2515/issues/37, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEWKZVGXZS3RDOAGPTXXTILWFPMWBANCNFSM6AAAAAARRDMPEY. You are receiving this because you are subscribed to this thread.

[wavejaco]

Yes, I only have the one MCP2515 at this moment.

[pierremolinaro]

Ok, so it is a normal behaviour.

When a CAN controller sends a frame, it except an ACK from a receiver. No receiver, no ACK. So the CAN controller sends again the same frame. And so on. This is described in https://en.wikipedia.org/wiki/CAN_bus#ACK_slot https://en.wikipedia.org/wiki/CAN_bus#ACK_slot.

The first submitted frame is sent repeatly, the MCP2515 send buffer is never freed. The tryToSend method returns ok until the driver buffer is full. So 17 messages are stored : 1 in the MCP2515 send buffer, 16 in the ACAN_2515 send buffer.

In loopback demo, the MCP2515 is configured in loopback mode, send frames are auto acked.

Best Regards,

Pierre

Le 28 oct. 2022 à 16:13, wavejaco @.***> a écrit :

Yes, I only have the one MCP2515 at this moment.

— Reply to this email directly, view it on GitHub https://github.com/pierremolinaro/acan2515/issues/37#issuecomment-1295052628, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEWKZVCIKN7TWZQ5VFV5G33WFPNQVANCNFSM6AAAAAARRDMPEY. You are receiving this because you commented.

[wavejaco]

In loopback demo, the MCP2515 is configured in loopback mode, send frames are auto acked.

Does this still require at least 2x MCP2515 on the bus? I would think that it only requires 1x in loopback mode.

[pierremolinaro]

Yes, in general at least 2 CAN controllers must be present on the bus.

In loopback mode, the MCP2515 ignores the bus activity, sent frames are internally routed to be received with implicit auto ack.

Some CAN controllers have a setting for auto acking, but MCP2515 does not.

Pierre

Le 28 oct. 2022 à 16:39, wavejaco @.***> a écrit :

In loopback demo, the MCP2515 is configured in loopback mode, send frames are auto acked.

Does this still require at least 2x MCP2515 on the bus? I would think that it only requires 1x in loopback mode.

— Reply to this email directly, view it on GitHub https://github.com/pierremolinaro/acan2515/issues/37#issuecomment-1295082689, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEWKZVEQ3C2JIG7A6H5OIGTWFPQRPANCNFSM6AAAAAARRDMPEY. You are receiving this because you commented.

[wavejaco]

Hello Pierre

I have tested my setup with another microcontroller for which I wrote the code in the past to interface with the MCP2515. As I expected, the setup works perfectly fine with only 1x MCP2515 in the system when loopback mode is used. I am able to successfully send and receive a message using this setup with my own code.

The MCP2515 datasheet specifically mentions the following in section 10.4 (Loopback Mode):

In this mode, the ACK bit is ignored and the device will allow incoming messages from itself, just as if they were coming from another node. The Loopback mode is a silent mode, meaning no messages will be transmitted while in this state (including error flags or Acknowledge signals).

Thus, to conclude, it is 100% possible to use a single MCP2515 on the CAN bus in loopback mode.

Although the setup with my own code works, I am still at the original problem with using the ACAN2515 library with the Pi Pico.

A quick thought on my side was that the 12 MHz crystal that I am using is not supported by the library. But I have even tested my own setup, deliberately specifying the wrong crystal frequency , and it still worked perfectly.

Any ideas where I could start looking for the problem with the Pi Pico use case?