I finally got around to doing some work on the board (Looks like I'm in for a second revision...)
I changed the crystal to 16Mhz (and also changed the caps to two x 18pF). When I now do "sudo ip link set can0 up type can bitrate 1000000", I don't get an error and the board current increases by 100-150mA. Something just got enabled, right ?
The bad news is that the compute module now crashes when I try to bring up the CAN interface. It crashes _hard_. No trace in any of the log files.
Sooo,... I turned to my old friend - ChatGPT.
Which after a brief chat (where I let it slip that I hadn't connected the MCP2515 interrupt pin to _anything_), kindly informed me that the kernel wouldn't be very happy bringing up can0 if that particular pin was left floating. Being interrupt driven and all...
The natural next thing to do in such scenarios is to apply a bodge wire from the MCP int pin (#13) to any available GPIO pin on the controller. Of course I hadn't expose any additional GPIO on the board (or test pads for that matter).
After having reviewed the schematic and layout, it also dawned on me that I had a single node net in there on one of the other ICs (I have to admit that I am somewhat disappointed in KiCad for not informing me about this when I ran ERC)
But,...
That also meant that I could remove the chip with the single node net (which also had to more pins that was connected to the compute module). TXB0106 b'Gone ! I now had exposed two pads and could repurpose one of the DXL_RX/TX signals.

I chose the DXL_RX signal (pin 3 on U7) was routed to GPIO5 and then updated the boot overlay to:
dtoverlay=mcp2515-can0,oscillator=16000000,cs_pin=8,sclk_pin=11,miso_pin=9,mosi_pin=8,interrupt=5
After a reboot I then tried bringing up can0 with the following command (full bitrate and all :))
sudo ip link set can0 up type can bitrate 1000000
I got no errors and it didn't crash this time either. When checking ifconfig, i got this:
can0: flags=193<UP,RUNNING,NOARP> mtu 16
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Happy days :)
I can now test the next thing, which is to send actual CAN frames to the CyberGear motor. If that works ok, I'll test out the IMU. If everything is ok up to that point, I'll spin a new revision with a fix for the missing INT and DXL_DIR signals. I can then proceed to also test the Dynamixel interface.
Hans Jørgen Grimstad
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.