• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 1244 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Beaglebone and CAN bus cape

Håkan Engblom
Prodigy 210 points

Hi,

Greetings everyone, since I'm new here.

I recently tried to make a CAN bus cape work with my Beaglebone, and I did, sort of, but ran in to a few strange things that I need to ask about.

I'm running the latest SDK (as far as I know) for Beaglebone downloaded from this website, version v05.05.01

The MLO, u-boot, kernel (uImage) and root-fs are built with buildroot.

Anyway my problem is that I have to explicitly in the code (attached file) force the CAN bus interface to be initialized. If I don't, no "can0" device will be seen when doing "ifconfig -a"

So I discovered that I get a timeout when the EEPROM on the CAN bus cape is about to be read (-110 is -ETIMEDOUT, from extra debug "hejdu5, ret:"):

[    0.840362] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
[    0.905303] No daughter card found
[    0.908874] hejdu5, ret: -110
[    0.911895] at24 1-0050: 32768 byte 24c256 EEPROM, writable, 64 bytes/write
[    0.927368] Board name: A335BONE
[    0.930786] Board version: 00A3

So I looked at this code a bit more (in board-am335xevm.c) and to me it seems, even if the "product infomration" of the cape was succesfully read, it would not be used to trigger an intialization of the CAN bus interface, it will just be discarded (see the code snippet below):

if (!strncmp("A335BONE", config.name, 8))
        {   daughter_brd_detected = false;

Further, it is evidently possible to read the "product information" from the base board, "A335BONE" and revision, is seen above, so the i2c communication seem to work, and my guess is that it is the same i2c bus going to the daughter board.

Now, I don't think I'm the first one in the world to put a CAN bus cape, or any other cape for that matter, on the Beaglebone, so what am I missing here ?
So my questions are:

  • Is reading of "product information" from EEPROM's on cape's supposed to work ?
  • Is the purpose to use this "product information" to initialize what ever things needs to be initialized if a cape is detected, like the call to am33xx_d_can_init() that has to be done for a CAN bus cape ?

Another person had a very similar problem in this post (Jun 27):
https://groups.google.com/forum/?fromgroups#!topic/beagleboard/ZP8IxIUqEUI

 br Håkan

 

  • 0
    Prodigy 210 points

    Hi,

    I investigated this further, and my guess is that dynamic detection of a CANbus cape is not implemented as of now in the linux SDK. In the current implementation, daughter boards are detected on the same i2c bus as the baseboard, on beaglebone this would be identifier "1" in 1-0051 below:

    [    0.840362] at24 1-0051: 32768 byte 24c256 EEPROM, writable, 64 bytes/write

    but the cape's on a Beaglebone is actually on bus 3, so they will not be detected. i2c bus 3 is initialized on a Beaglebone, but it is not used to detect cape's. Further the cape's on a beaglebone are on addresses 0x54 to 0x57. So I made a hack to detect a CANbus cape dynamically. This is not a nice solution and it is probably not in line with how the maintainers on the linux SDK has planned. Maybe a device-tree would solve this in a better way ?

    Anyway, the patch is attached. With this patch a CANbus cape is dynamically detected and CAN interface initialized. But there are more things not covered in this patch. It has do to with jumpers on the CANbus cape, and there is a note about it in the patch.

    Further there is a HW-problem on the cape. U27 shoule be removed, and a wire put from pin 2 to pin 4 (see. http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_CANBus)

    /Håkan