OBD-II and ELM327 (9), MITM Failure Analysis 3, the CAN Bus Requires At Least Two Devices

A House to The Development kit

I have to say, keep the things neat is profession. I seek expert (my wife) to improve my equipment
  • The pins of the development board are inserted into the foam as the base, and the base is attached to the box with hot melt glue
    • Expert: Hot melt glue is your friend
  • The DuPont wire is fixed to the edge of the box with strap
    • Expert: With strap, I can adjust wires if desired
  • Dig a hole in the box to fix the OBD-II head (fixed with hot melt glue), 
  • Dig another hold to route USB cable
    • USB1: Powering MCU board, and programming it
    • USB2: Get 5V power source, and a 5v-to-12v DC-to-DC coverter to power devices (HUD)
    • USB3: Powering Raspberry Pi







Datasheet is good friend to play with MCU

The advantage of changing to STM32 is that environment is simple. Reading datasheet about CAN bus makes me understand more. The text below is some note for me as reading the datasheet
  • STM32 by default doesn't enable CAN re-transmission
    • As the packet from HUD forwards to CAR, it might be dropped because the CAN bus is busy. So we need to turn-on re-transmission
    • If the packet is dropped, HUD will be unhappy (it thinks car doesn't respond)
    • STM register naming is quite bad: NART, No Auto ReTransmission
      • The good naming style is positive-list
        • 0: disable
        • 1: enable
        • Match human intuition
      • ENART(Enable Auto ReTransmission) is much better, really
  • STM32 CAN-TX is quite strong, it had 3x mailbox allowing queues up to 3 messages
    • So I can send the packet directly (assume the buffer never full)
  • STM32 CAN-RX is also strong, which had two FIFO, and each FIFO can store up to 3 messages
    • Don't need to worry buffer overflow
  • STM32 CAN1/CAN2 shares resource
    • I shall configure CAN2::filter by CAN1
    • That's the way STM32 designs their HW, read book !!

    Inspiration

    I think the real problem is: what's the difference between car and desktop. Why it's OK on the desktop but failure on the car. HUD expects to attach to live network, which includes a lot of devices; But my desktop is very quiet. As the MITM working, there's two CAN networks
    • CAN1
      • CAR or Pi-CAR
      • RPi-MITM
    • CAN2
      • HUD
      • RPi-MITM
    As connecting RPi-MITM to the car, the packets forward from CAN1 to CAN2. If HUD is NOT powered, there would be single devices on CAN2. 

    In CAN network, there's an *ack* field which all nodes shall respond. If there's only one node in CAN bus transmitting packet (but no ack), the TEC (Transmit Error Count) in CAN controller will keep rising. As reaching 255, the CAN controller mutes itself and entering bus-off status

    In the car, CAN1 keeps receiving packets and forward to CAN2. Before the HUD connecting to the network, RPi-MITM::CAN2 is in bus-off state (TEC reachs 255), and no longer response. Now as HUD powers up, nobody would ack to HUD's packet. Finally HUD also thinks the network is DEAD. This is why HUD doesn't work

    So the correct solution is: there's at least two devices in the CAN-bus
    • CAN1
      • CAR or Pi-CAR
      • STM32-CAN1 (package forwarding)
      • RPi-CAN0 (dummy client/ sniffer)
    • CAN2
      • HUD or VIDA-DICE
      • STM32-CAN2 (package forwarding)
      • SRPi-CAN1 (dummy client/ sniffer)
    In my final configuration, STM32 is in charged of packet-forwarding while RPi acks as dummy devices or sniffer. Before HUD powering up, both CAN bus contains at least two devices and we can send/receive packets without trouble (no entering bus-off state now)

    Use STM32 to forward CAN bus, it's the fastest way to forward packets within MCU; RPi can sniffer data and store them to SD cards. We can use WiFi to send command and retrieve data from RPi


    With the configuration above, I can finally light up HUD in the car with MITM. A long long way to struggle...


    STM32 Development Environemnt

    Since this is engineer's note, here's the tools I used, and why I picked them
    最後我想聊一下開發環境，底下是我用的工具和挑選的理由
    • STM32 CUBEMX
      • STM provided boot code generator. Easy to use, and quite handy
      • It also includes USB example
    • Atollic True Studio
      • Well develop GCC development environment, I can compile code easily
        • Avoid to use Keil ARM (the license is quite expensive)
    • Sublime text 3
      • The text editor I used in recent years, cross platform in Windows/Linux
    • Convert ST-Link on-board into a J-Link
      • Thanks to SEGGER, it converts ST-Link on Nucleo board to J-Link
      • I love J-Link

    • Segger OZone Debugger
      • Professional, free, and cross-platform (Windows/ Mac/ Linux) debugger
        • I didn't use Keil ARM, which had very handy debugger as well
        • Attolic True Studio also had gdb-based debugger, but not easy to use
    • Amazon FreeRTOS

    Comments

    Post a Comment

    Popular posts from this blog

    OBD-II and ELM327 (1)

    Image
    I bought a Volvo XC60 2017, and the car had an OBD-II port. I always feel the port is inviting me to do some hacking. I had power supply, oscilloscope, soldering equipment, multi-meter. I can read English, and had some embedded system development experience, but no hacking car ever. Maybe with some study, I can learn to do that My adventure starts with ELM327, the equipment is quite cheap. I want to talk pro/con of the cheap China ELM327 unit, and when you will feel disappointed to it ELM327 is basically a Microchip PIC18F2480 with customized FW, which supports various OBD protocol. Picture below is from its datasheet Left-upper corner, MCP2551 is the CAN transceiver It communicates to car by CANL/CANH signals It outputs CAN signal to PIC18F2480 (ELM327) (PIN1/4) PIC18F2480 (ELM327) It accepts the output signal from CAN transceiver The internal CAN controller send/receive from CAN bus It had UART interface in PIN17/18 Option1: FTDI UART to USB interface Conne
    Read more

    OBD-II and ELM327 (3), try to decode CAN package recorded by ELM327

    Image
    Volvo XC60 2017 doesn't offer the capability of closing tailgate by remote control. I have to press the button in the tailgate (see below) to hand. That's probably because of security reason, but I feel so stupid. M assumption is, the button sends some message to CAN bus. If I can sniffer the signal, I can close the tailgate remotely Challenge Accept !! I connect the ELM327 with my XC60, and successfully read VIN code . Then I tried ATMA (Monitor All) command to sniffer CAN bus... Then... nothing happened !! What the fuck ?! So now I can tell you when the cheap ELM327 makes you disappointed In complete AT command Because Torque App doesn't use ATMA command, so the cloned ELM327 don't offer such capability Poor bluetooth connectivity As sending ATRV command, sometimes I got incomplete response. I guess that's because bluetooth module doesn't work well Even the cheap ELM327 dongle offers ATMA capability, the data rate is far exceeding the blue
    Read more

    OBD-II and ELM327 (2), the underlying interface of ELM327

    Image
    Go to Google play and search keyword of "ELM327 Terminal", all of them were similar, you can just pick arbitrary of one. If you really had some difficult of selection, this one  looks beautiful and just updated recently After connecting the tool with ELM327 and car, type "0902" in the tool to read the VIN code . These PIDs (0902) were industrial standard , and all cars shall implement it. Here's some useful PIDs. That's why HUD (head up display) can connect to all brands of cars with OBD2 connector 01 0D: car speed 01 0C: engine RPM Here's the 0902 query response of my car in the APP. If interested, decode it :-) 7E8 08 01 14 49 02 01 59 56 41 7E8 08 21 44 5A 41 38 42 44 48 7E8 08 22 32 30 37 36 36 38 32 A lot of people read CAN bus by Torque, but only few people read the ELM327's capability document. Check out ELM327 website and download their AT command list , that's all the capability it had. It had different capability
    Read more