BeagleBone Green: Enable CAN on Startup

Three steps:

  1. Enable CAN overlay by configuring cape manager
  2. Configure network interface
  3. Install startup program

1. Enable CAN overlay

Add following line in /etc/default/capemgr

2. Configure network interface

Add following lines in /etc/network/interfaces

3. Install startup program

Setting the CAN interface to /etc/network/interface does not enable the CAN interface on startup for some reason. In order to workaround this problem, I installed a startup program as follows.

Following link was helpful:

Running a script on Beaglebone Black boot/ startup

The startup script to run on startup is as follows. This script also turns off wi-fi power management, thus I removed a cron entry I added before to disable the power management.

Following are the steps to create and enable a service that runs on startup.

  • Create the service
  • Edit the above file as necessary to invoke the different functionalities like network. Enable these only if the code needs that particular service. Disable unwanted ones to decrease boot time.
  • Create a symbolic link to let the device know the location of the service.
  • Make systemd reload the configuration file, start the service immediately (helps to see if the service is functioning properly) and enable the unit files specified in the command line.
  • Restart BBB immediately to see if it runs as intended.


BeagleBoneGreen: Disabling Wi-Fi Power Management Permanently

The operating system is Debian. This is a dirty solution but it does work anyway.

Test CAN connection between BeagleBone and MIDI/CAN converter

1. Enabled CAN at 1Mbps on BeagleBone:

Following operations seem to be necessary every BeagleBone boot. TBD to setup auto configuration on startup.

2. Wired CAN ports

Used MCP2551 for CAN transceiver.

3. Connected with MIDI/CAN converter via CAN bus

See the picture above.

4. Monitor MIDI/CAN converter via serial interface

5. Monitor packets on BeagleBone and play

Serial port monitor:

Enable CAN on the BeagleBone Green

I’ve tried to enable CAN on my BeagleBone Green board. I had to stop the work before verification, because my logic analyzer is unavailable now. I record what I did in this article to make things reproducible when the logic analyzer is back.

There are several helpful links:!category-topic/beagleboard/can/SjWwVngIPh8

Readings to understand device tree overlay:

Device Tree for Dummies:

Device Tree Overlays (in adafruit)

Here are what I did:

Then I have to stop here.

BeagleBone notes

How to login from MacOS:

  1. Connect to the BeagleBone by a USB cable.
  2. MacOS restart is necessary for some reason.
  3. SSH to

WiFi setup:

Use connmanctl as described in /etc/network/interfaces.

… and so on

Following links give useful information: (in Japanese)

The wlan0 device power management can be turned off by

TBD how to turn this off permanently.

Take SD backup

  1. Insert the SD into the MacBook
  2. “diskutil list” to know the path to the device.
  3. run “sudo dd if=<device_name> conv=sync,noerror | gzip -c > archive.img.gz

Following link is helpful to know how to backup disks in several styles:

Connecting to the host via serial port

Useful when the SSH access has a problem:

Use USB-UART Bridge on PSoC CY8CKIT-049-42xx Kit

You need miniprog3 to program this, despite typical programming to this kit is via boot loader.

1. Put a SCB UART component. Change baud rate to 9600.

2. Assign pins as follows:

UART RX : P4[0]
UART TX : P4[1]


3. And then, here is the main.c source code

4. Build it, program it, and connect the CY8CKIT-049-42xx to the PC.

That’s it.

Generating MCP2515 SPI ‘READ’ Operation Request Using PSoC 42xx

PSoC 42xx provides SPI component that supports up to 4MHz clock speed. Communicating with MCP2515 via this component, however, is not straightforward when you try the highest clock speed.

The problem is concept of ‘operation’ of MCP2515. An operation consists of multiple SPI bytes bundled by ‘enable’ signal on the CS pin. Lowering the CS pin initiates an operation and it must stay low during the data transmission. See following timing chart quoted from the MCP2515 datasheet.


The PSoC SPI component lacks direct control on the CS pin signal. The component automatically lowers the CS level when the write API puts a byte to Tx FIFO and the component’s internal logic raises the CS level when all FIFO values are consumed. But auto-generated API functions are not fast enough due to overhead to make the functions generic. Then, the CS signal may split during an operation when Tx FIFO becomes empty due to the API failing to catch up with the desired speed.

I wrote a function that generates a valid READ operation frame and retrieves returned bytes. The strategy is:

  • Use lower-level component interfaces to avoid overhead.
  • The function pushes sending bytes to Tx FIFO as fast as possible to keep it non-empty during the operation.
  • Concurrently read data from Rx FIFO as fast as possible to avoid FIFO overflow.

There are limitations to use this functions:

  • Both Rx and Tx buffer sizes of the SPI component must be 4. PSoC Creator generates software buffer when the sizes are larger than 4. That makes source code management too complicated.
  • The first two bytes in output array are dummy that do not mean anything. Actual retrieve data starts from the third element.
  • The function may need to disable interrupts during the operation, though it is still missing in the implementation.

Here is the source code. In this example code, the SPI component name is ‘SPIM_CAN’ which is a master SPI component (non SCB).

Tried reading 16 bytes from MCP2515 using this read function from a 4MHz-clock SPI of a PSoC Pionner Kit. The CS (Enable) signal stays low during the operation, as expected.



Module Descriptor and Compiled Parameter Table

I tried Google Protocol Buffers to describe and transfer modules’ schema before. This approach, however, did not work well because it required large amount of resources both in program and in RAM spaces of a PSoC processor. It limited available resources for module functionality. I finally gave up the approach.

I am trying another approach to describe a module using JSON and to compile it into a parameter table implemented using C macros. The module program does not have to include the schema. Sharing the JSON schema file by Analog 3 modules is good enough. It is nice if the module has the schema internally though. Google Protocol Buffer may help compressing the data in the case.

Here is an example of schema and generated table for MIDI Gateway module: