Skip to content

mbed-OS STM32 CAN_API.c doesn't respect ISO11898 bit timing definition #14690

Closed
@haarkon

Description

@haarkon

Description of defect

CAN Standard request a sample point between 66.7% and 75% closest to 75%.
Sample point calculation is done by formul : Sample = (1+SEG1)/(1+SEG1+SEG2)

Actual value in can_api.c (from line 808, in 6.10.0) are not properly calculated and worth, many sample point are far beyond 75% :

static const int timing_pts[23][2] = {
    {0x0, 0x0},      // 2,  50% -> Real sample point = 67% (good)
    {0x1, 0x0},      // 3,  67% -> Real sample point = 75% (good)
    {0x2, 0x0},      // 4,  75% -> Real sample point = 80% (bad, but no other solution)
    **{0x3, 0x0},      // 5,  80% -> Real sample point = 83% (bad)
    {0x3, 0x1},      // 6,  67% -> Real sample point = 71% (good)
    {0x4, 0x1},      // 7,  71% -> Real sample point = 75% (good)
    **{0x5, 0x1},      // 8,  75% -> Real sample point = 78% (bad)
    **{0x6, 0x1},      // 9,  78% -> Real sample point = 80% (bad)
    {0x6, 0x2},      // 10, 70% -> Real sample point = 73% (good)
    {0x7, 0x2},      // 11, 73% -> Real sample point = 75% (good)
    **{0x8, 0x2},      // 12, 75% -> Real sample point = 77% (bad)
    **{0x9, 0x2},      // 13, 77% -> Real sample point = 79% (bad)
    {0x9, 0x3},      // 14, 71% -> Real sample point = 73% (good)
    {0xA, 0x3},      // 15, 73% -> Real sample point = 75% (good)
    **{0xB, 0x3},      // 16, 75% -> Real sample point = 76% (bad)
    **{0xC, 0x3},      // 17, 76% -> Real sample point = 78% (bad)
    **{0xD, 0x3},      // 18, 78% -> Real sample point = 79% (bad)
    {0xD, 0x4},      // 19, 74% -> Real sample point = 75% (good)
    **{0xE, 0x4},      // 20, 75% -> Real sample point = 76% (bad)
    **{0xF, 0x4},      // 21, 76% -> Real sample point = 77% (bad)
    {0xF, 0x5},      // 22, 73% -> Real sample point = 74% (good)
    {0xF, 0x6},      // 23, 70% -> Real sample point = 71% (good)
    {0xF, 0x7},      // 24, 67% -> Real sample point = 68% (good)
};

This won't be a problem as long as you are not too close to the edge of your can bus (high frequencies with long distances).
There are a better choices :

static const int timing_pts[23][2] = {
    {0x0, 0x0},      // 2,  67%
    {0x1, 0x0},      // 3,  75%
    {0x2, 0x0},      // 4,  80%
    {0x2, 0x1},      // 5,  67%
    {0x3, 0x1},      // 6,  71%
    {0x4, 0x1},      // 7,  75%
    {0x4, 0x2},      // 8,  67%
    {0x5, 0x2},      // 9,  70%
    {0x6, 0x2},      // 10, 73%
    {0x7, 0x2},      // 11, 75%
    {0x7, 0x3},      // 12, 69%
    {0x8, 0x3},      // 13, 71%
    {0x9, 0x3},      // 14, 73%
    {0xA, 0x3},      // 15, 75%
    {0xA, 0x4},      // 16, 71%
    {0xB, 0x4},      // 17, 72%
    {0xC, 0x4},      // 18, 74%
    {0xD, 0x4},      // 19, 75%
    {0xD, 0x5},      // 20, 71%
    {0xE, 0x5},      // 21, 73%
    {0xF, 0x5},      // 22, 74%
    {0xF, 0x6},      // 23, 71%
    {0xF, 0x7},      // 24, 68%
};

Target(s) affected by this defect ?

STM32 familly

Toolchain(s) (name and version) displaying this defect ?

All

What version of Mbed-os are you using (tag or sha) ?

Mbed-Os 6.3.0 (and maybe before) to Mbed-Os 6.10.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

All

How is this defect reproduced ?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions