Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fault callback is never invoked #279

Open
zolnierczyk opened this issue Apr 13, 2018 · 2 comments
Open

Fault callback is never invoked #279

zolnierczyk opened this issue Apr 13, 2018 · 2 comments

Comments

@zolnierczyk
Copy link

zolnierczyk commented Apr 13, 2018

Hi PolySync,

I think that I found bug with fault handling mechanism.

Expected behavior

OSCC C api fault_report_callback should be invoked where CAN error frame is received.

Actual behavior

All error frames are ignored.

Steps to reproduce

For example brake module:

  1. Disconnect module from car system but keep CAN connection to oscc part
  2. Power it up
  3. Send enable command
  4. Module send CAN error frames (CAN sniffer show frames)
  5. OSCC C api don't receive any faults

Version info

Source from v1.2.1-niro

Analyze

SocketCAN is initialized by this code:

    struct sigaction sig;
    memset( &sig, 0, sizeof(sig) );
    sigemptyset( &sig.sa_mask );
    sig.sa_flags = SA_RESTART;
    sig.sa_handler = oscc_update_status;
    sigaction( SIGIO, &sig, NULL );

    int sock = socket( PF_CAN, SOCK_RAW, CAN_RAW );

    if ( sock < 0 )
    {
        printf( "Opening CAN socket failed: %s\n", strerror(errno) );
    }
    else
    {
        result = OSCC_OK;
    }

But from kernel documentation we can read kernel doc

Using CAN_RAW sockets is extensively comparable to the commonly
known access to CAN character devices. To meet the new possibilities
provided by the multi user SocketCAN approach, some reasonable
defaults are set at RAW socket binding time:

  • The filters are set to exactly one filter receiving everything
  • The socket only receives valid data frames (=> no error message frames)
  • The loopback of sent CAN frames is enabled (see chapter 3.2)
  • The socket does not receive its own sent frames (in loopback mode)

So current behavior that api don't get any error frames is valid one from kernel driver point of view. I modify code by adding new header include:

#include <linux/can/raw.h>
#include <linux/can/error.h>

And also after creating socket new option:

can_err_mask_t err_mask = ( CAN_ERR_MASK );
setsockopt(sock, SOL_CAN_RAW, CAN_RAW_ERR_FILTER, &err_mask, sizeof(err_mask));

And after this modification I can receive fault code and callback is invoked.

@rebpdx
Copy link
Contributor

rebpdx commented Apr 14, 2018

Thank you for the information. We're working on reproducing it.

What vehicle are you running?

In the firmware we are not deliberately sending error frames for those fault reports which suggests that the CAN bus is having some difficulty sending messages. Are the error frames the only CAN frames you are seeing?

@zolnierczyk
Copy link
Author

I am working on Kia Niro vehicle but currently I reproduce this bug just by connecting all modules together with power and CAN just on the table without car connected to any board. I am receiving report frames correctly and I can send enable message to boards on which they react. But as you mention those errors came from bus itself.
[Testing without my modification] With one module powered up I got callback called properly. With two modules powered up I got error frames sometimes without callback called and with three module problem was bigger. The root case of issue I think is sending fault report frame:

g_control_can.sendMsgBuf(
        OSCC_FAULT_REPORT_CAN_ID,
        CAN_STANDARD,
        OSCC_FAULT_REPORT_CAN_DLC,
(uint8_t *) &fault_report );

All three modules was trying to send fault report frame with the same ID and at the same time which give bus error message. Of course boards are not perfectly synchronized so I am still getting some valid fault frames.

This setup is not representing real life scenario. There is small probability that all boards start to send fault frames so this is not big issue but nevertheless I think it is good idea to create fault frames ID per module not common for every one.

@ghost ghost self-assigned this Jan 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants