Closed bong1991 closed 7 years ago
(Technically this is a Linux kernel issue. It won't be linked to the Pi GPU firmware)
There's nothing unique in the Pi version of the mcp2515 driver, so this sounds like it is either an upstream bug, or a fundamental issue with the MCP2515 / MCP2551 combo. It seems highly unlikely that the SPI bus is clearing just that one bit (is it one bit or the whole nibble?), particularly as you've confirmed that loopback mode works correctly which pretty much puts it as an issue with the Pican2 / MCP2515.
Have you tried contacting the manufacturer of the Pican2 for comment?
(sorry for posting it on the wrong repo). Thanks for your answer.
If the highest bit of the second nibble is set, the whole most significant nibble is decreased by one. So, 0x180 turns to 0x080, 0x280 to 0x180, and so on.
I will make some more tests including analysing the SPI signal by using an oscilloscope.
No, i have not contacted them yet, will do this soon when my approaches fail.
Sounds very strange as you say the MCP2515 loopback works.
Looking at the datasheet (http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf), page 19, registers 3-3 / 3-4 are the Standard ID, with bits 10:3 being in TXBnSIDH, and 2:0 in the MSBs of TXBnSIDL. So you're saying that effectively SID8 is being missed (I suspect it is shift right 1, not subtract 1 with borrow), but only if actually transmitting the data. Software isn't going to manage that. Dodgy clock synchronisation might (see section 5 of the datasheet for details of what CAN gets up to). Can you test with another Pican2 board, or check the oscillator frequency on your board?
There have been several posts regarding CAN and the MCP2515 on the forums - https://www.raspberrypi.org/forums/viewforum.php?f=44 You'll probably get more visibility there than hiding on here.
I think it's actually not shifting right, cause this would be dividing by 2 and e.g. 0x480 is transformed to 0x380. I don't have another Pican2 board, but I will keep testing.
Big thanks for you effort, i think this can be closed. I will try my luck at the raspberry forum.
I am trying to send can Messages with the pican2 Module. Mostly working fine but sending IDs ending on hex80 or higher lowers the leading number. E.g. 0x180 as ID actually sends an 0x080.
receiving canbus messages with id 0x180 for instance does not alter it to 0x080. In loopback mode I received the correct sent ID. However, if i send a canbus message with the second nibble higher than 7, the first nibble is decremented.
My /boot/config.txt looks like this: dtparam=spi=on dtoverlay=mcp2515-can:oscillator=16000000,interrupt=25 dtoverlay=spi-bcm2835
I changed the last overlay several times, cause i saw that spi-bcm2835 does not exist anymore. I changed it to dtoverlay=spi0-hw-cs or erased that line entirely. But each configuration produced the same erroneous behaviour.