To address this question directly, no the interrupt is not used in this design. The simulator program polls the MCP2515 for available messages.
Here’s another avenue to validate the hardware before diving deeper into the Linux OS.
Connect a Particle Photon or a 3.3V Arduino to the CAN simulator board directly and see if the board responds to a SPI request.
Here’s the pinout
Photon → Pi GPIO
CS: A2 → 24
SCK: A3 → 23
MISO: A4 → 21
MOSI: A5 → 19
3.3V: 3V3 → 1
Ground: GND → 39
Flash this program to the Photon.
#define WRITE_COMMAND 0x02
#define READ_COMMAND 0x03
#define REGISTER_CNF2 0x29
#define INITIAL_CNF2 ((1 << 7) | (2 << 3))
void setup() {
Serial.begin();
Serial.printlnf("Write %02x to MCP2515 register CNF2 and reading back", INITIAL_CNF2);
SPI.begin(SS);
digitalWrite(SS, LOW);
SPI.transfer(WRITE_COMMAND);
SPI.transfer(REGISTER_CNF2);
SPI.transfer(INITIAL_CNF2);
digitalWrite(SS, HIGH);
delay(1);
digitalWrite(SS, LOW);
SPI.transfer(READ_COMMAND);
SPI.transfer(REGISTER_CNF2);
uint8_t result = SPI.transfer(0);
digitalWrite(SS, HIGH);
if (result == INITIAL_CNF2) {
Serial.println("MCP2515 responded with expected result.");
} else {
Serial.println("MCP2515 did not respond. Check wiring.");
}
}
I see this output with the setup pictured above:
Write 90 to MCP2515 register CNF2 and reading back
MCP2515 responded with expected result
I’ll try that tomorrow. I’ll let you know the results.
@jvanier - Awesome information here!!
I didn’t have any free time this weekend to tackle this. This is on my things to get done this week. Hopefully adding the ground will fix my issues.
But I’ll run through your tests above with my multi-meter to verify what you see.
On your assembled board, how did you end up grounding Pin8 on IC2? I see the large glob of solder/flux. Did you drill a hole through, or carve out a little path to ground?
I scraped the solder mask of the ground plane and shorted the pin to it.
To be clear I don’t think this is the issue. Pin 8 should be connected to ground on the PCBs you printed (I updated the Eagle files after I found the mistake). Besides the result of this missing ground would be no signal exchange with the outside CAN and would not affect SPI communications with the MCP2515 CAN controller.
When I checked my PCB and Pin8 on IC2 with all the grounds, it never had continuity. It definitely was not grounded. Did you update the Eagle, but somehow OshPark is using the previous one?
That must be it. 
Well the fix is simple.
I’ll be let sure to update OSH park later.
That means that the PCB design in github (v1) is fixed ? So, can I take as the proper one ?
Thanks for all the support.
Yes, I can confirm that the link Order a simulator v1 PCB from OSH Park from GitHub - carloop/simulator: CAN bus simulator on the Rasperry Pi linked to the old version of the PCB without the CAN tranceiver TJA1049 pin 8 shorted to ground.
The PCB design on GitHub is fixed. I’ll go ahead tonight and upload it to OSH Park and update the README.
However I still don’t expect a missing ground on the TJA1049 CAN transceiver to lead to the CAN controller MCP2515 not responding to the SPI communications from the Raspberry Pi. There might be something else going on.
The readme on the CAN simulator GitHub repository is now updated with links to the latest PCB on OSH Park. I updated the version printed on the PCB to v1.1 to avoid confusion in the future when someone prints this PCB.
Ill try that version to discard a soldering issue as well.
Greetings,
Sorry to revive an old thread. Did this work for the folks who were trying to get their simulators running?
I ordered the board direct from OSH Park, and the TJA1049 seems to be properly grounded, but I am also getting the “Error occured: CAN chip not responding” message. I tried the test with the Particle Photon and I get “MCP2515 did not respond. Check wiring.”
Would be grateful for any insight.
I tried a couple of PCB versions of the ECU sim with no success, so I done my own : My own ECU simulator - Car Hacking - Carloop Community .
Hope it helps.