veggiebenz:
Yes, your loopback code sent a message and successfully received the message.I am confident with crystal frequency and baud rate -- with Raspberry Pi and the same MCP2515 adapter I am receiving data.
Okay, that is all good to know.
veggiebenz:
I have played around with some values in the mcp_can_dfs file:// from https://www.kvaser.com/support/calculators/bit-timing-calculator/
#define MCP_CNF3 0x03 //0x00 //0x85 // was 0x28
#define MCP_CNF2 0x88 //0xb5 //0xF1 // was 0x29
#define MCP_CNF1 0x00 //0x01 // 0x40 // was 0x2A
This seems to have some effect -- the default settings do not work (crashes) -- but to be honest I don't know what I'm doing...
Well, that section of the dfs file is defining register names to addresses, that section should not need any changes. You want the section that has the below.
#define MCP_8MHz_500kBPS_CFG1 (0x00)
#define MCP_8MHz_500kBPS_CFG2 (0x90)
#define MCP_8MHz_500kBPS_CFG3 (0x82)
I will admit, I have not scrutinized the 8MHz values as much as I have the 16MHz and 20MHz. From a timing perspective, those values above are correct for 500k with 8MHz. I, however, would change it from the above to this:
#define MCP_8MHz_500kBPS_CFG1 (0x00)
#define MCP_8MHz_500kBPS_CFG2 (0xD1)
#define MCP_8MHz_500kBPS_CFG3 (0x81)
These values move the sample point to 75% of the bit time and enable 3 samples instead of a single sample. All of this should help...
veggiebenz:
There's no lookup for the "135" error code?
The 135 is your Receive Error Counter. The error code is the binary number "1000". The third bit of the EFLG register being set means the Receiver Error Counter is greater than 128. Which all tells me there is an issue with the baud rate.