ANCIT | UDS Secure Bootloader

Features

Key Features

Dual-Stage Bootloader

Primary and Secondary Stage boot loading for robust and reliable ECU startup sequences.

Primary stage validation
Secondary stage execution
Fail-safe boot mechanism

Multi-Core Application Flashing

Supports flashing across multicores for IPCF-enabled architecture with synchronized updates.

IPCF architecture support
Synchronized multi-core updates
Core-specific validation

AES 128 Encryption

Comes with AES 128 encrypted security service for secure firmware updates.

Secure key exchange
Encrypted data transfer
Authentication protocols

Flexible & Efficient Flashing

Supports quick portability for new ECU hardware series and dual bank flashing.

Dual bank flashing support
Quick hardware portability
Optimized memory utilization

USB2CAN Hardware Agnostic

Compatible with major CAN hardware vendors for seamless integration.

Peak TOSUN Vector Kvaser

Customizable Architecture

Define your own Boot Manager, NVM, and CANIF layers for flexible ECU programming.

Custom Boot Manager
NVM layer configuration
MATLAB block set available

Platforms

Supported Microcontrollers

NXP Microcontrollers

Ready-to-use bootloader for NXP automotive MCU families:

S32K1 Series S32K3 Series S32G2 Series

Texas Instruments (TI)

Ready-to-use bootloader for TI C2000 MCU families:

F280049 F28379X Series F28P65X Series

Tools

Flashing Tool Variants

TSMaster Utility

Tailored for TOSUN CAN hardware users with full feature support.

Full TSMaster integration
GUI-based flashing interface
Automated flashing sequences

Python-Based Lite Utility

Designed for PEAK/Vector/Kvaser CAN hardware users.

Cross-platform Python script
Command-line interface
Scriptable automation support

Compare Variants

Bootloader Comparison

Choose the right bootloader variant based on your project requirements

Feature	Single Stage [PBL]	Dual Stage [SBL]	Popular Secure Bootloader
Boot Stages	Primary Boot Loader (PBL) only	PBL + Secondary Boot Loader (SBL)	PBL + SBL with secure chain of trust
AES 128 Encryption
Secure Boot Authentication
Multi-Core Flashing (IPCF)
Dual Bank Flashing
UDS (ISO 14229) Compliant
USB2CAN Hardware Agnostic
Customizable Architecture	Basic	Advanced	Advanced
Flashing Tool Support	TSMaster / Python Lite	TSMaster / Python Lite	TSMaster / Python Lite
Best Suited For	Basic ECU flashing & development	Production-grade multi-core ECUs	Safety-critical & security-sensitive ECUs

Boot Architecture

PBL vs SBL — How Each Boot Scenario Works

Two architectures, two trust models. The right choice depends on your security requirements and memory constraints.

Scenario A

PBL + Application firmware only

No SBL present · PBL handles flashing directly

PBL owns
all flash ops

Programmer / host PC connects

ECU power-on / reset

PBL executes from ROM

PBL detects flash trigger

Boot pin / magic key / JTAG/SWD

PBL enters flash mode

Exposes UART / CAN / USB protocol

Erase application flash region

PBL erases sectors directly

Write new application image

Chunked writes via flash protocol

CRC / checksum verify

PBL verifies written image

Pass?

Error / retry

Yes

Reset — PBL boots application

Scenario B

PBL + SBL + Application firmware

Three-stage boot · SBL owns all reprogramming logic

PBL
ROM —
trust
anchor

SBL
flash —
owns all
reflash
logic

Programmer / tester connects

ECU power-on / reset

PBL executes from ROM

PBL verifies SBL signature

CRC or RSA/ECDSA check

SBL valid?

Halt / error

Yes

PBL jumps to SBL

Control handed off to flash

SBL inits peripherals

CAN / LIN / ETH / UDS stack up

SBL receives UDS 0x10 / 0x27

DiagSession + SecurityAccess

Erase app flash (0x34 / 0xFF)

SBL erases target sectors

Transfer data (0x36)

Chunked transfer · CRC per block

SBL verifies app image

CRC / signature check (0x37)

Reset — PBL boots SBL boots App

Scenario A

When to choose PBL-only

Resource-constrained MCUs where flash memory is tight — no room for a separate SBL partition
Development boards and prototypes where boot security is not a hard requirement
Single-core ECUs where IPCF multi-core flashing is not needed
Lab / bench environments where the update path is trusted (JTAG, SWD, known host)
Lowest cost path — single binary, fastest bring-up, simpler validation scope

Scenario B

When to choose PBL + SBL

Production ECUs where firmware authenticity must be verified before any flash operation
Multi-core (IPCF) architectures where each core needs coordinated flashing through a central SBL
OTA / field update scenarios where the update channel is untrusted (CAN, LIN, ETH)
ISO 26262 / EVITA projects where a chain-of-trust from ROM to application is a compliance requirement
Dual-bank flashing where PBL must remain immutable while the active partition is being updated

Trade-offs

Key advantages of each approach

PBL-only — Simplicity

Smallest possible ROM footprint — no SBL partition needed
Faster boot time — no signature verification step
Simpler validation — one binary, one test scope
Lower cost — no key management infrastructure required

PBL + SBL — Security

Cryptographic chain-of-trust from immutable ROM to application
SBL is field-updatable; PBL stays locked in ROM permanently
Full UDS diagnostic session support (0x10, 0x27, 0x34–0x37)
Supports multi-core IPCF flashing and dual-bank OTA updates

Trade-offs to consider

SBL adds ~10–30 KB flash overhead depending on feature set
Key provisioning and certificate management adds project complexity
PBL-only has no protection against unsigned firmware injection
Both require separate test scopes — PBL and SBL must each be validated independently

Architecture

VxBoot vs VxDiag — purpose-built, not bundled

Both are ISO 14229 UDS stacks. Both run on the same ECU. They share 4 services — and that’s exactly where the overlap ends.

VxBoot

UDS Bootloader

Flash programming · Secure download pipeline

0x10 DiagnosticSessionControlshared

0x11 ECUResetshared

0x28 CommunicationControl

0x27 SecurityAccessshared

0x31 RoutineControl (Erase)

0x34 RequestDownload

0x36 TransferData

0x37 RequestTransferExit

0x3E TesterPresentshared

4 shared
services

VxDiag

Diagnostic Application

Runtime · Calibration · DTC management

0x10 DiagnosticSessionControlshared

0x11 ECUResetshared

0x14 ClearDTCInformation

0x19 ReadDTCInformation

0x22 ReadDataByIdentifier

0x27 SecurityAccessshared

0x2E WriteDataByIdentifier

0x2F InputOutputControl

0x31 RoutineControl

0x3E TesterPresentshared

0x85 ControlDTCSetting

Need VxDiag for your diagnostic layer? Learn about VxDiag →

FAQ

Common Questions

Why two products if they’re based on the same standard?

Same standard, different purpose. ISO 14229 defines the full UDS vocabulary — 26+ services. VxBoot implements only the flash programming subset: download session, memory erase, data transfer, transfer exit. VxDiag implements the diagnostic subset: DTC management, calibration, I/O control.

They share only 4 services out of the full spec. Bundling them would mean every ECU ships with flash-programming capability exposed at the diagnostic layer — that’s a security vulnerability, not a convenience feature.

If I buy VxBoot, does VxDiag come with it?

No — and that’s by design. VxBoot is purpose-built for flash programming sessions — no DTC context, no calibration, no I/O control. VxDiag is purpose-built for field diagnostics — no flash memory access at all.

Think scalpel, not Swiss Army knife. That said, we do offer a bundled license for teams that need both stacks on the same ECU — enquire here.

Can VxBoot and VxDiag run on the same ECU at the same time?

Yes — they occupy separate memory regions and separate UDS session contexts. VxBoot lives in reserved flash and activates only during a programming session. VxDiag lives in the application partition and handles all runtime diagnostic requests.

They never run concurrently — the ECU switches sessions via DiagnosticSessionControl (0x10). Both stacks are generated via SmartWheels GenX with memory boundaries set in the configuration.

UDS Secure Bootloader