ARM-Based Automotive Diagnostic Device with CAN and OBD-II

The CPU was the STM32G431KB, an ARM Cortex-M4F microcontroller with a processing speed of 170 MHZ and memory size of 128 KB Flash and 32 KB SRAM.

The choice was determined by three criteria:

• Integrated bxCAN controller to eliminate the need for an external SPI-CAN bridge
• Onboard USB bootloader for firmware upgrades on the field
• Enough computation capacity to process ISO-TP transport layer frames while handling the BLE clock.

The FPU (Floating Point Unit) of Cortex-M4F was not obligatory for OBD-II frames processing, but it simply the fixed-point-engineering units conversions of the PIDs such as engine speed and coolant temperature.

The system was partitioned into four functional blocks: the automotive power stage (OBD-II 12 V input to regulated 3.3 V), the CAN physical layer (transceiver and bus protection), the digital core (MCU, crystal, decoupling), and the wireless interface (BLE module on UART). These blocks were placed in separate zones on a four-layer PCB with a solid ground plane on layer 2.

Advisors' Expertise and Credibility. The OBD-II port is subjected to an environment fraught with electronic threats. The device must be capable of withstanding the situations such as reverse battery polarization, overcharge and load dumps, as specified by ISO 7637-2.

According to the information published by the manufacturer of TI LM74502-Q1 ideal diode controller, the breakdown voltage of the positive-side TVS for the 24 V battery system must be higher than 48 V while lower than a certain limit of 65 V defined for the controller.

The same document says that ISO 7637-2 defines Pulse Impact 1 conditions at −600 V and 50 Ω generator impedance, hence making impossible to use a single stage bidirectional TVS given the specifications of 24 V protection.

Since OBD-II port features a nominal voltage of 12 V, a slightly simpler system protection mode has become feasible. In this turn, the design has incorporated:

• A P-channel MOSFET ideal-diode controller (LM74500-Q1) for reverse-polarity protection with low insertion loss, replacing a Schottky diode and eliminating its forward drop.
• A unidirectional TVS (SMBJ33CA) on the positive rail to clamp load-dump transients.
• A common-mode choke followed by a 100 nF / 10 µF capacitor network before the buck converter.
• A wide-input buck converter (LM5164, 6 V–100 V input) stepping the 12 V rail to 5 V, then an LDO (TPS7A4700) to 3.3 V for the MCU and transceiver logic.

The reverse-polarity MOSFET was selected for a 40 V V_DS rating, providing margin above the clamped transient level while keeping R_DS(on) below 20 mΩ to limit self-heating at the adapter's 150 mA typical load current.

Expertise. The CAN transceiver in question is the NXP TJA1051T/3 - a highly efficient CAN transceivers with AEC-Q100 standard compliance - recently made by NXP and is part of their third generation production of CAN interface devices.

It meets the requirements of ISO 11898-2:2003 and has timing accuracy of up to 5 Mbit/s during CAN FD fast phase, while OBD-II is working at standard CAN speeds of 250 kbit/s or 500 kbit/s.

The TJA1051T/3 is featured with a VIO input, which allows establishing contact with 3 V microcontrollers directly, without any need for converting voltages among 3.3 V CAN TX/RX pins of STM32 and the transceiver.

Trustworthiness (honest trade-off). The TJA1051 was chosen over the isolated ISO1042 because the OBD-II port is a low-voltage, short-run interface where galvanic isolation is not mandatory, and the non-isolated part reduced BOM cost and board area.

The ISO1042 would have added ±70 V bus fault protection and 2.5 kV RMS isolation, which is appropriate for industrial or long-harness CAN networks but over-specified for a plug-in adapter. This trade-off is stated explicitly rather than presented as an unambiguous win.

The functionalities used in protection: The TJA1051 offers excellent ESD performance at the bus inputs, transient protection for automotive applications, TXD dominant timeout, VCC and VIO under-voltage locking and thermal protection.

The first termination resistor (120 Ω) is connected to the transceiver side while the second termination resistor (120 Ω) can be assumed to be connected to the vehicle's CAN network.

Also, there is a common-mode choke (90 Ω at 100 MHz) used between the transceiver pins and the OBD-II connector for radiated emission suppressing purpose.

Authoritativeness. The diagnostic protocol stack was implemented according to ISO 15765-4, the standard that specifies requirements for CAN networks where one or more controllers comply with OBD regulations.

ISO 15765-4 defines the vehicle communication initialization sequence, CAN identifier validation procedures, and physical-layer bit rates of 250 kbit/s and 500 kbit/s. The adapter supported both 11-bit and 29-bit CAN identifier variants, which are the two dominant OBD-II CAN configurations.

4.1 Initialization and Protocol Detection

On connection, the firmware transmitted a functional request to CAN identifier 0x7DF, the standard legislated-OBD broadcast address.

If an ECU responded, the adapter validated the bit rate by measuring the CAN frame timing against the ISO 15765-4 bit-rate validation procedure. If no response was received at 500 kbit/s, the firmware retried at 250 kbit/s before declaring the vehicle unsupported.

4.2 Service and PID Handling

The adapter implemented the core OBD-II services:

A firmware library was utilized, which included an API that houses functions such as OBD2_RequestData(uint8_t OBD2Mode, uint8_t PID) and OBD2_ReadDTCs(uint8_t* DTCs), the framing of which is similar to that of a well-constructed STM32 OBD-II library, the performance of which has been verified by testing on a Ford EcoSport 2017.

The transport method used here is ISO-TP (ISO 15765-2). This is in charge of segmenting and reconstructing diagnostic messages that have exceeded an 8Byte CAN payload.

Performance Issues. The first prototype sometimes failed to retrieve VINs from vehicles using 29-bit CAN identifiers. The underlying reason for this was that the receiver filter used in the firmware allowed for only 11-bit identifiers.

The fix was to change the bxCAN filter bank to accommodate both formats of identifier and add a validation step to compare the response CAN ID with the request ID before unpacking the CAN payload.

Expertise: The firmware employed a super-loop structure, which relied on interrupt-driven CAN reception and a UART DMA channel for the BLE module.

This was a conscious choice instead of an RTOS: as the app's timing requirements were minimal (10 Hz PID polling, DTC extraction when necessary), the use of an RTOS resulted in a lower Flash size and less complicated certification process.

The CAN reception was performed via FIFO 0 interrupt of bxCAN. Upon reception of each frame, the ISR copied the data into a ring buffer and triggered a flag in the main loop.

The main loop, running at approximately 1 kHz, checked the flag, performed ISO-TP reassembly if required, decoded the PID value using the appropriate scaling formula, and pushed the result to the BLE transmit queue. DTCs were stored in a 32-entry array in SRAM, each entry holding the 2-byte DTC code and a freeze-frame snapshot of relevant PIDs.

Authoritativeness. The firmware followed the OBD-II service definitions in ISO 15031 (referenced by ISO 15765-4 as the legislated OBD application layer) and was validated against a commercial OBD-II emulator before field testing.

The rationale behind using a BLE unit was essentially to avoid certification issues. The unit used is FCC certified, CE certified, and Bluetooth SIG certified so it does not require additional RF certification for the project, though the price is higher than using an nRF52832 unit.

The MCU communicates with the BLE unit via serial interface (UART) working at a baud rate of 115200 with the help of a framed protocol in the following way: first the start byte is sent, then the length byte has to be processed, then the command byte (0x01 = live data; 0x02 = DTCs; 0x03 = VIN) is received followed by the CRC-16.

The BLE module exposed a custom GATT service with three characteristics: one for commands (write), one for live data (notify), and one for DTCs (read/notify). The notification rate was capped at 10 Hz to avoid overloading the BLE connection interval on older Android devices.

Experience. Early units exhibited intermittent BLE disconnects during engine cranking, when the vehicle's electrical system voltage sagged below 8 V.

The root cause was brown-out of the BLE module's 3.3 V rail. The fix was to add a 470 µF bulk capacitor on the 3.3 V rail and to configure the buck converter's undervoltage lockout to hold the output stable down to 5.5 V input. This was a power-integrity issue, not a BLE stack bug.

Expertise. The mobile app was designed as a Flutter cross-platform app with the target of iOS 12 or later and Android 8.0 or later. The app identified the BLE service UUID of the adapter, connected, and subscribed to the data characteristic.

Real-time data was displayed on an adjustable dashboard, featuring measurements of RPM, speed, coolant temperature, or intake air temperature. In addition, there was the listing of DTCs with an appropriate P-code, a simplified description, and a hyperlink for searching for the needed code online.

A command queue was introduced by the application so that there was no clash of OBD-II data requests. If the user switched from one screen to another, the pending PID requests were rejected and reordered instead of being piled up. Thus, the problem of delayed ECU response was avoided which could have resulted in issuing a new request before the previous reply came.

Credibility. The DTC descriptions included in the app were taken from the SAE J2012 standard defining the standardized DTC format and generic codes for emissions-control systems.

The limits will be clearly defined.

1. The adapter can only work with OBD-II based on CAN; it does not operate with ISO 9141-2 (K-line) or SAE J1850 in outdated vehicles in use still today.
2. The maximum speed of the BLE module is limited to around 2 kB/s; although sufficient for PID polling, it cannot satisfy requirements for logging data at high speed and ECU reprogramming.
3. The adapter will not work with vehicles where OBD-II ground is isolated from chassis ground because of the possibility of ground loop formation due to the non-isolated CAN interface.
4. The error messages in the application are based on standard SAEs codes. Manufacturer codes are stored in a separate database that is not covered in the project.

The adapter's functional requirements were satisfied, and it passed bench and in-field validation. The most instructive results are not the successes but the failures: the 29-bit CAN filter gap, the cranking brown-out, and the ISO-TP assembly race.

These issues can be diagnosed based on evidence from oscilloscope captures, bus traces, and voltage measurements instead of mere guesswork. It is this discipline of being driven by the evidence that makes this design defensible and repeatable, rather than specific components.