candle-usb / candleLight_fw

gs_usb compatible firmware for candleLight, cantact and canable
Other
659 stars 290 forks source link

[Question] Does it support listen only mode? #13

Open asbachb opened 6 years ago

asbachb commented 6 years ago

Hi,

I wonder if the firmware supports putting the can device into listen only mode?

Thanks Benjamin

fenugrec commented 4 years ago

Hi, currently no, but the stm32F0xx hardware does have a "silent mode" that does exactly that :

In Silent mode, the bxCAN is able to receive valid data frames and valid remote frames, but it sends only recessive bits on the CAN bus and it cannot start a transmission. [...] Silent mode can be used to analyze the traffic on a CAN bus without affecting it by the transmission of dominant bits (Acknowledge Bits, Error Frames).

And there is a "listen-only" flag at the kernel level :

$ ip link set can0 help
Usage: ip link set DEVICE type can
    [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
....
    [ loopback { on | off } ]
    [ listen-only { on | off } ]
    [ triple-sampling { on | off } ]
    [ one-shot { on | off } ]
    [ berr-reporting { on | off } ]
    [ fd { on | off } ]
    [ fd-non-iso { on | off } ]
    [ presume-ack { on | off } ]
...

So :

fenugrec commented 3 years ago

Actually I think I was partly wrong, firmware definitely should already support silent mode :

usbd_gs_can.c:393

        case GS_USB_BREQ_MODE:
                ..........
                    can_enable(ch,
                        (mode->flags & GS_CAN_MODE_LOOP_BACK) != 0,
                        (mode->flags & GS_CAN_MODE_LISTEN_ONLY) != 0,
                        (mode->flags & GS_CAN_MODE_ONE_SHOT) != 0

So I guess one would have to enable listen-only just before bringing interface up . Has anyone tried ?

brian-brt commented 3 years ago

I happen to have a test setup handy to try this. Seems like it's working to me FWIW.

I'm using a candleLight on one Linux machine attached to another CAN interface on another Linux machine. The bus just has those 2 devices and a terminator, nothing else.

My test sequence:

  1. Other CAN interface is sending things happily: candump any,0:0,#FFFFFFFF shows frames and no ERRORFRAMEs
  2. Bring the candleLight device down: sudo ip link set brtcan2 down
  3. Now the other device shows lots of ERRORFRAMEs in candump any,0:0,#FFFFFFFF
  4. Put the candleLight device up in listen-only mode: sudo ip link set brtcan2 type can listen-only on && sudo ip link set brtcan2 up
  5. Still lots of ERRORFRAMEs on the other device
  6. Take the candleLight device out of listen-only mode: sudo ip link set brtcan2 down && sudo ip link set brtcan2 type can listen-only off && sudo ip link set brtcan2 up
  7. No more ERRORFRAMEs on the other device
fenugrec commented 3 years ago

@brian-brt awesome, thanks for testing! Do I understand correctly that with brtcan2 (candleLight) in listen-only mode, it receives the error frames ? (I'm not sure if both ends are seeing the ERRORFRAMEs or just the sender)

brian-brt commented 3 years ago

No, I didn't actually try reading frames from the candleLight device originally. Testing again, the candleLight device does not see any ERRORFRAMEs. When it's not in listen-only mode, it sees all the frames (as expected). In listen-only mode, it sees a single frame being sent repeatedly.

Receiving the non-ACKed frames is what I mentioned in https://github.com/candle-usb/candleLight_fw/issues/55#issuecomment-732543598 about listen-only implying presume-ack. I think on a "correct" listen-only device those would all be no-ACK ERRORFRAMEs.