ISO-TP driver: implementation and tests for CAN

Practical Breakdown of the ISO-TP Driver from Raccoon Developers for CAN Networks

ISO-TP (ISO 15765-2) solves the CAN classic limitation of 8 bytes per frame by fragmenting large data arrays. The driver from Raccoon Developers implements the protocol through four key functions: initialization, sending, enqueueing incoming frames, and processing. It supports packets up to 4094 bytes using FIFO queues for frame assembly.

API drayvera:

n_rslt iso15765_init(iso15765_t* instance);
n_rslt iso15765_send(iso15765_t* instance, n_req_t* frame);
n_rslt iso15765_enqueue(iso15765_t* instance, canbus_frame_t* frame);
n_rslt iso15765_process(iso15765_t* instance);

Initialization requires callbacks for uptime, frame sending, error handling, and reception indication. Configurable BS (block size), STmin (separation time), addressing type, and maximum packet size.

Dependencies and Internal Architecture

The driver depends on the universal iqueue queue for storing incoming CAN frames. The I15765_QUEUE_ELMS constant defines the buffer depth.

i_status iqueue_init(iqueue_t* _queue, uint32_t _max_elements, 
                     size_t _element_size, void* _storage);
i_status iqueue_enqueue(iqueue_t* _queue, void* _element);
i_status iqueue_dequeue(iqueue_t* _queue, void* _element);

Reception reassembles data from FirstFrame and ConsecutiveFrame into a complete payload. Upon completion, the indn() callback is called with the full payload. Data is cleared after processing in the callback.

Sending via iso15765_send() supports up to 4094 bytes (12-bit length field). Single frame up to 8 bytes, multi-frame uses sequential blocks with acknowledgments.

Testing without Hardware

Modular tests simulate exchange between three ISO-TP instances in one program. The send callback is redirected to the receiver's enqueue. CRC32 of the sent and received payload is compared.

Example log from a 24-byte send test:

• TxSize:24 Byte, TxCrc32:0x8295A696
• RxFirstFrame: MesgSize:24 Byte
• ConsecutiveFrame: SN=1, Payload:000102...17181920212223
• DataMatch! Size:24 Byte

The test confirms correct assembly and verification. Duration: ~863 ms.

Hardware Validation on USB-CAN

For real traffic, the USB2CANFD_V1 adapter is used. CANcat is a console utility like netcat for ISO-TP.

Successful examples:

• Transmission of 0x3344556656565656565656 between processes.
• Jumbo-frame 0x11223344556677889900aabbccddeeff from 0xd to 0xc.
• Single frame in both directions.

Logs show correct handling of FirstFrame (FS=0, BS=3), ConsecutiveFrame, and flow control.

Key Advantages and Limitations

Advantages:

• Multiple instances with independent configuration (CAN, UART).
• Pure C, ~1000 lines of core code.
• Bidirectional mode without recompilation.

Limitations:

• Does not compile with -Werror=strict-prototypes.
• No simultaneous Tx/Rx — sending interrupts reception.
• Infinite wait for ConsecutiveFrame if master is lost.
• Single frame in CAN classic interprets 8-15 bytes literally, without checking.

What’s Important

• The driver is suitable for embedded projects with CAN where UDS over ISO-TP is required.
• Processing in superloop: enqueue on Rx, process at high frequency, send on request.
• Payload is cleared after indn() — copy data inside the callback.
• Test modularly before hardware to verify the algorithm.
• Maximum 4094 bytes per session due to 12-bit length field.

— Editorial Team