Quick recap of the idea from Part 1: the components stay exactly as they are, including every Rte_Read and Rte_Call. The generated RTE API headers stay the contract; underneath, a generated shim fulfills that contract with ThreadX primitives. Every mechanism gets a rating:

• Native — ThreadX has a primitive that does the job.
• Shim — a thin layer of your code on top of ThreadX primitives.
• Build — ThreadX has nothing close. You design and implement it, and for safety-relevant parts, you also argue it.

In Part 1, we gave every OS task a thread and a dispatcher loop that wakes up on event flags. Now we fill in what the runnables actually do through their ports. The example project is still the BCU from the foundation series: six Cortex-M7 cores, one ASIL B core, five QM cores.

What’s inside

• Sender-receiver communication, unqueued and queued, on ThreadX primitives
• Implicit vs. explicit communication: when a runnable gets a snapshot and when it sees the writer’s new value
• Client-server, synchronous and asynchronous, and mode management
• Basic software on ThreadX
• The summary table: native, shim or build for every mechanism, and what you lose (and how to win some of it back)

Quick recap of the BCU from the foundation series: Part 1 (requirements), Part 2 (memory map), Part 3 (memory protection) and Part 4 (SWC allocation and tasks). If you haven’t read them, the short version: six Cortex-M7 cores, one simplex ASIL B core for exterior lighting, five QM cores for everything else, an HSM with its own firewalled flash, and no A/B swap.

In foundation Part 3, I hid a side note in the middle of the MPU chapter: safety is not security, that’s a post of its own. Side notes like that are promises. This is me keeping one.

The difference fits in one sentence. Safety protects the car from its own mistakes. Security protects it from somebody who makes mistakes happen on purpose. A bit flip doesn’t read your source code, doesn’t wait for the one millisecond your check is skipped, and doesn’t come back next week with a better tool. An attacker does all three. So everything we built in the foundation series (default-deny, E2E, mailboxes, watchdogs) is a good start, but it was designed against faults that are random and don’t try to get past you.

The good news: if you followed the series, a lot of security is already there, just not labelled as such. The bad news: the rest touches nearly every part of the ECU, from the production line to the scrapyard. So let’s go through it door by door, using our BCU. Every door gets the same three questions: what’s behind it, who wants in, and what keeps them out. There are ten doors, which is too many for one post, so this is a three-part series. This part sets up the threat model and covers the two doors everything else depends on: the root of trust and the boot.

Step zero: the TARA, or “who actually wants in?”

In safety you start with a HARA. In security you start with a TARA (threat analysis and risk assessment), as defined by ISO/SAE 21434. Since UN R155 came in, it’s not optional anymore: no cybersecurity management system, no type approval, no car. That gets a project manager’s attention very quickly.

A TARA works in five steps:

1. Assets. What’s worth protecting, and which property of it: confidentiality, integrity or availability.
2. Damage scenarios. What happens if that property is lost, rated in four impact categories: safety, financial, operational and privacy.
3. Threat scenarios and attack paths. How someone gets there, step by step.
4. Attack feasibility. How hard that is: time, expertise, knowledge of the target, window of opportunity, equipment.
5. Risk and treatment. Impact × feasibility gives a risk value. For each risk you decide: reduce it, accept it, share it (insurance, contracts) or avoid it (drop the feature).

The output is a set of cybersecurity goals, and from those you derive requirements. Without a TARA, every security discussion turns into “but what if the attacker…” and never ends, because an attacker with enough budget can always do one more thing. The TARA is how you decide where to stop. It turns paranoia into a documented, reviewable risk acceptance. Paranoia is cheap, the documented version costs effort.

Here’s a heavily trimmed first TARA for our BCU. As always in this series, the ratings are assumptions with a date on them, not results. If you want the untrimmed version — 14 assets, 13 damage scenarios, 19 threat scenarios with attack-potential ratings, risk treatment and eight cybersecurity goals with their CAL — it’s in the repo as examples/TARA_BCU_example.xlsx. Same idea as the memory map: the source of truth is a YAML file, _data/tara_bcu.yml, and scripts/build_tara.py refuses to generate the workbook if a risk above the acceptance threshold is left untreated.

The first row is my favorite, because it’s not hypothetical. For a while, a popular way to steal cars was to pull out the headlight connector, plug a device into the CAN wires behind it and send “unlock” and “immobilizer OK”. No hacking of the radio, no stolen key. Just the wiring harness, which runs to places on the outside of the car where anyone can reach it. For a BCU, which is the ECU attached to almost every one of those wires, this is the threat model in one picture.

Here’s the whole attack surface of our BCU on one page: every way in from the outside, where it lands, and which door of this series deals with it. Keep it open in a second tab, all three parts refer back to it.

Two more points before we go door by door:

• Security doesn’t replace safety goals, it adds new ones. The brake light row is both a safety topic (HARA, ASIL B, foundation Part 4) and a security topic (TARA, SecOC). They need to agree. A security reaction that turns the brake light off “because the message was tampered with” is unsafe. Write down how the two interact, the same way foundation Part 3 wrote down the QM/ASIL failure behavior.
• The TARA rates attackers with physical access too. Someone who bought the same BCU at a scrapyard has unlimited time, a lab, and no reason to hurry. Whether you defend against them (fault injection, side channels) is a decision the TARA makes, not your gut feeling. Usually the answer is “protect the secrets that are shared across many vehicles, accept the rest”. More on that later.

Door 1: the root of trust — who checks the checker?

Every security mechanism in the ECU eventually rests on the question: who checked that the checker is genuine? At some point that chain has to stop at something you trust because it can’t be changed. That is the root of trust.

In our BCU it’s three things, and foundation Part 2 already gave each of them a place:

• The HSM’s boot ROM. Mask ROM in silicon, burned at the chip factory. It verifies the HSM firmware before the HSM runs it.
• The HSM firmware and its keys in the firewalled HSM Flash (256 KB) and HSM Data Flash (32 KB). No application core can read them, not even the ASIL B one. That’s not the MPU, that’s the hardware firewall, and that’s important: if a QM core gets compromised and runs privileged, the MPU is gone. The firewall isn’t.
• Stage-1, the 64 KB bootloader that’s read-only after production and has no update path. Paired with the HSM, it decides what runs next.

What the HSM is actually for

The HSM is a separate core with its own memory, its own crypto accelerators and its own firewall. The application cores talk to it through a job interface: “compute a CMAC over this buffer with key slot 7” — and they get the result, never the key. The key never leaves the HSM in plaintext. That’s the whole idea: an application compromise must not mean a key compromise. If an attacker gets code running on QM Core 5, they can ask the HSM for MACs as long as they’re in, which is bad. But when they’re out, they don’t take the key with them, and the next update closes the hole. Once a key is extracted, no update helps.

What our HSM provides, and who uses it in the BCU:

The 32 KB “placeholder” in HSM Data Flash from foundation Part 2 now gets a first sizing: around 20 key slots with metadata, a few monotonic counters (wear-leveled, because counters that increment on every update or every ignition cycle will wear out a sector), two or three certificates of around 1 KB each, and the lifecycle state. 32 KB is enough, with room to spare. The placeholder just became a decision.

The key inventory

You can’t protect keys you didn’t write down. This is the list I’d put into the architecture document, and the moment where most projects discover they have more keys than they thought:

The two rules behind that table:

• No secret is shared across the fleet. If a key is the same in every BCU, one BCU from a scrapyard, one side-channel attack and one weekend give you every car. Per-ECU keys are derived from a master key and the ECU serial number (from the ECU OTP block in foundation Part 2) in the key management backend. The master key never sees an ECU. The only things that are the same in every ECU are public keys, and those only need integrity, not confidentiality.
• Every key has a way out. Algorithms get broken, keys leak, certificates expire. For every key in the table, “how do we replace it in a car that’s already in the field?” needs an answer before production starts. “We’ll do a recall” is an answer, just a very expensive one.

Door 2: boot — secure, authenticated, or just fast?

Foundation Part 1 already warned about this conflict: secure boot that checks megabytes of code before anything starts is great for security and terrible for “the bus expects an answer in 150 ms”. Now we have the memory map, so we can do the math instead of worrying about it.

First, the terms, because people use them interchangeably and they aren’t:

• Secure boot: each stage verifies the next one before it runs. If the check fails, the next stage doesn’t run at all.
• Authenticated boot: the next stage starts immediately, and the check runs in parallel. If it fails, the system loses its privileges: the HSM refuses to hand out keys for this boot cycle, and the event gets reported.
• Measured boot: each stage records a hash of the next one, and someone else (a backend, a remote verifier) decides later whether to trust it. Common on PCs, rare on MCUs. I mention it so you’ve heard of it.

Now the numbers. Let’s assume our HSM computes a CMAC at around 40 MB/s. That’s an illustrative value — check your datasheet, the range across chips is huge. What we’d need to verify, using foundation Part 2’s regions with realistic fill levels (only the image, not the reserved space):

255 ms just for verification, before any core has initialized a single CAN controller. With a 150 ms budget for the first answer on the bus, full secure boot simply doesn’t fit. So here’s what I’d do:

1. The HSM boots first and verifies its own firmware with its ROM. Strict, no exceptions.
2. The HSM verifies Stage-1 before it releases the ASIL B core from reset. Strict secure boot. 1.3 ms, nobody will notice.
3. Stage-2 is verified strictly, but only when we actually enter it (flashing session, or an invalid application). Normal startups don’t pay for it.
4. The applications use authenticated boot. Stage-1 does the fast safety integrity check (more on that in a moment) and starts the cores. The HSM verifies the application images in the background. The SecOC keys, the immobilizer key and the diagnostic identity are bound to the boot result: the HSM only unlocks them for this power cycle after the verification succeeds, typically within 250–300 ms of reset.

What an attacker gets from a manipulated application under this scheme: an ECU that runs, but can’t send a single authenticated message, can’t authorize the engine start and can’t authenticate to a diagnostic tester. For the TARA, that’s the trade-off to argue: for about a quarter of a second after each reset, unverified code runs, but it has no keys. And to get modified code into the flash at all, the attacker must already have defeated Stage-2’s signature check or the debug lock. Those are doors 3 and 7, in Part 2 and Part 3. I’d accept that risk and write down why. If your TARA disagrees (for example, because the application controls an actuator that’s dangerous even in that quarter second), the answer is strict verification for that part and a different startup concept, not “let’s hope nobody tries”.

Two things that make this cheaper than it looks:

• Sign the image, not the region. The 2 MB ASIL B region holds 1.9 MB of code. The signature covers the image length stored in the header, not the padding. Foundation Part 2’s reserves cost memory, but not boot time.
• Asymmetric at update time, symmetric at boot time. Verifying an ECDSA signature takes a few milliseconds no matter the image size. Hashing the image is what costs time. So the update path (Stage-2) verifies the OEM signature once, and then the HSM computes a CMAC with the ECU’s own boot MAC key and stores it. Every following boot checks only this CMAC, which is faster than re-checking the full signature chain and doesn’t need the OEM’s public key at runtime.

Integrity for safety, authenticity for security

Foundation Part 2 left a caveat in the YAML: the check that stops a corrupted ASIL B image from starting is a safety mechanism against random hardware faults and probably needs ASIL B. The HSM’s CMAC is a security mechanism, usually developed as QM.

It’s tempting to say “the CMAC catches every bit flip anyway, so we just need one check”. Technically true, but the safety case then rests on HSM firmware developed to a standard that doesn’t fit. So in our BCU, Stage-1 runs a fast CRC over the ASIL B image, developed to ASIL B, and the HSM runs its CMAC. Two checks over the same bytes for two different reasons. It looks redundant, but it means neither the safety assessor nor the security assessor has to accept evidence from the other team’s process. If you want to merge them, talk to both assessors first. Together, ideally — that’s a meeting worth bringing popcorn to.

Fault injection: the attack on the if

The most efficient attack on secure boot doesn’t break the crypto. It skips the comparison. A short voltage glitch or an electromagnetic pulse at the right moment, and if (result != OK) takes the wrong branch. There’s equipment for this that costs less than a decent oscilloscope.

If the TARA puts this attack in scope (for the immobilizer, it probably does), the code that evaluates the boot result looks a bit paranoid:

#define BOOT_OK    0x3CA5965Au   /* no 0/1: a single glitched bit must not produce "OK" */
#define BOOT_FAIL  0xC35A69A5u

volatile uint32_t res = hsm_boot_status(IMG_APP_ASILB);

if (res != BOOT_OK) { boot_fail(); }
delay_random_cycles();                         /* the attacker has to hit twice, at an unknown time */
if (hsm_boot_status(IMG_APP_ASILB) != BOOT_OK) { boot_fail(); }
if (res != BOOT_OK) { boot_fail(); }            /* re-check: the compiler keeps it because of volatile */
start_core(CORE_ASILB, img_entry(IMG_APP_ASILB));

Non-trivial constants, double checks, random delays, volatile so the compiler doesn’t “optimize” the paranoia away. Plus the hardware: many automotive MCUs have voltage and clock monitors that reset the chip on a glitch, and the HSM runs its own checks with its own countermeasures. It doesn’t make fault injection impossible, it makes it slower and less reliable. Usually that’s enough to make the attack not worth it.

Where this leaves us

Two doors in, we have the base everything else stands on. A TARA tells us what’s worth protecting and where to stop. The HSM keeps every key behind a firewall that even a compromised, privileged core can’t get through. The key inventory says where each key comes from and how it gets replaced. And the boot concept fits into foundation Part 1’s startup budget by making the keys, not the start, depend on the verification.

What we haven’t covered yet is everything that tries to get into the ECU while it’s running: new firmware, frames on the bus and a diagnostic tester asking for more rights than it should have. That’s Part 2. The code itself, the debug port, the immobilizer and noticing an attack follow in Part 3.

Sources and further reading

Standards and specifications

• ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineering — the TARA method used in step zero.
• UN Regulation No. 155 — Cyber security and cyber security management system — Annex 5 lists the threats a type approval expects you to have thought about.
• NIST SP 800-38B: The CMAC Mode for Authentication — the MAC behind fast authenticated boot.
• NIST FIPS 186-5: Digital Signature Standard — ECDSA for signed images.
• NIST SP 800-193: Platform Firmware Resiliency Guidelines — root of trust, protection, detection and recovery.
• AUTOSAR Classic Platform: Crypto Service Manager, R23-11 and Key Manager, R23-11 — how application cores talk to the HSM and keys.
• EVITA project — the research project behind the full/medium/light HSM classes still used today.
• MCUboot and Trusted Firmware-M — open-source references for secure boot and a root of trust on Cortex-M.

Papers

• Hagai Bar-El et al.: The Sorcerer’s Apprentice Guide to Fault Attacks, Proceedings of the IEEE 94(2), 2006 — the classic overview of glitching and why one if is not enough.

Books

• David Ward, Paul Wooderson: Automotive Cybersecurity: An Introduction to ISO/SAE 21434, SAE International, 2021
• Catherine H. Gebotys: Security in Embedded Devices, Springer, 2010
• Jasper van Woudenberg, Colin O’Flynn: The Hardware Hacking Handbook, No Starch Press, 2021 — fault injection and side channels from the attacker’s side.
• Christof Paar, Jan Pelzl: Understanding Cryptography, Springer, 2010 — AES, CMAC and ECC explained for engineers.
• Adam Shostack: Threat Modeling: Designing for Security, Wiley, 2014
• Ross Anderson: Security Engineering, 3rd ed., Wiley, 2020

The animations in this post are rendered with manim from scripts/manim/security_scenes.py.

In Part 1, we built the base: a TARA for the BCU, an HSM that keeps every key behind its firewall, a key inventory, and a boot concept that fits into the 150 ms startup budget because the keys, not the start, depend on the verification. If you skipped it, at least look at the attack surface map there. This part uses its door numbers.

This part covers the three doors that are open while the ECU is running, by design: the update path, which is supposed to put new code into the ECU; the bus, where every ECU is supposed to talk; and diagnostics, which is supposed to give a tester control over the ECU. The question isn’t how to close them. It’s how to make sure only the right people get through.

What’s inside

• Door 3, updates: check before you erase, anti-rollback, and the problem with “immutable”
• Door 4, the bus: SecOC on CAN FD, the brake light with security, LIN, Ethernet and the gateway
• Door 5, diagnostics: the door with a key under the mat

Part 1 built the base: TARA, HSM, keys and boot. Part 2 put locks on the three doors that are open by design: updates, the bus and diagnostics. This last part is about the doors that are easy to forget: the code behind all those locks, the debug port, the immobilizer (where security isn’t a protection, it’s the function), noticing an attack, and the data the BCU collects without anybody asking. At the end, everything comes together in one table: which security mechanism lives where in the BCU, and what it costs.

What’s inside

• Door 6, the code itself: parsers, pointers and other gifts
• Door 7, the debug port and the ECU lifecycle
• Door 8, the immobilizer: security as the actual function
• Door 9, detection and response, and Door 10, privacy
• Where security lives in the BCU: one table for every mechanism, and the process around it

Sooner or later, every embedded architect hears some version of this sentence: “We have all these AUTOSAR components already — can’t we just run them on ThreadX?” Sometimes it’s a QM core that doesn’t justify another AUTOSAR license, sometimes a prototype that has to run next week, sometimes a customer who wants an AUTOSAR architecture but a different OS underneath. The question is always the same: how much of AUTOSAR can you rebuild on a plain RTOS, and what does it cost?

Short answer: almost all of it. Long answer: this post and the next one. I went through the AUTOSAR Classic mechanisms one by one — runnables and RTE events, OS tasks and resources, alarms, IOC, partitions, timing protection in this part; sender-receiver in all its flavors, client-server and modes in Part 2 — and mapped each one onto ThreadX. Every mapping gets a rating:

• Native — ThreadX has a primitive that does the job.
• Shim — a thin layer of your code on top of ThreadX primitives.
• Build — ThreadX has nothing close. You design and implement it, and for safety-relevant parts, you also argue it.

The example project is the BCU from the foundation series: six Cortex-M7 cores, one ASIL B core, five QM cores.

The idea: keep the contract, swap the engine

The trick that makes this work is not to port the components. You keep them exactly as they are, including every Rte_Read and Rte_Call, and replace what sits underneath:

The RTE API is the contract between the components and the platform. As long as that contract holds, components don’t care what fulfills it. That’s also the first rule of doing this in practice: generate the shim, don’t write it by hand. An ECU has hundreds of ports. Nobody writes 300 Rte_Read functions by hand and gets all of them right — but a small script that reads your port description (the ARXML you already have, or a YAML file like the memory map from Part 2 of the foundation series) gets them right every time, or fails loudly.

The execution model

Runnables and RTE events

In AUTOSAR, you don’t write tasks. You write runnables, and RTE events decide when they run: every 10 ms, when data arrives, when someone calls an operation. The RTE generator then maps runnables into OS tasks. On ThreadX, the shim does the same with one thread per OS task and one event flag per RTE event:

#define EV_10MS      (1u << 0)   /* TimingEvent 10 ms        */
#define EV_SPEED_RX  (1u << 1)   /* DataReceivedEvent         */
#define EV_SERVE_OP  (1u << 2)   /* OperationInvokedEvent     */

static TX_EVENT_FLAGS_GROUP task10ms_ev;
static TX_TIMER             task10ms_tmr;

static void tick_10ms(ULONG arg)                 /* runs in the ThreadX timer thread */
{
    (void)arg;
    tx_event_flags_set(&task10ms_ev, EV_10MS, TX_OR);
}

static void Task_10ms_entry(ULONG arg)
{
    ULONG ev;
    (void)arg;
    LightCtrl_Init();                                       /* InitEvent */
    for (;;) {
        tx_event_flags_get(&task10ms_ev, EV_10MS | EV_SPEED_RX | EV_SERVE_OP,
                           TX_OR_CLEAR, &ev, TX_WAIT_FOREVER);
        rte_task10ms_copy_in();                             /* implicit inputs, see Part 2 */
        if (ev & EV_10MS)     { R_Control(); }
        if (ev & EV_SPEED_RX) { R_OnSpeed(); }
        if (ev & EV_SERVE_OP) { R_ServeOp(); }
        rte_task10ms_copy_out();                            /* implicit outputs */
    }
}

/* at init, with a 1 ms tick: */
/* tx_timer_create(&task10ms_tmr, "10ms", tick_10ms, 0, 10, 10, TX_AUTO_ACTIVATE); */

Two catches. First, event flags don’t count. If the 10 ms timer fires twice before the thread gets to run, the thread sees one flag, not two — the activation is gone, silently. AUTOSAR basic tasks can count multiple activations and report E_OS_LIMIT when they overflow. If you care (and for anything timing-supervised, you do), use a counting semaphore for the timing event, or at least count overruns in the timer callback. Second, ThreadX timer callbacks run in the timer thread (or in the tick interrupt, depending on configuration), so they set a flag and leave. Nothing else.

The full list of RTE events, what they mean in AUTOSAR, and where they come from on ThreadX:

OS tasks: basic, extended, activation

AUTOSAR OS is OSEK underneath, and OSEK knows two kinds of tasks. Basic tasks run to completion: ActivateTask starts them, they end with TerminateTask. Extended tasks can also wait for events. On ThreadX, both become threads in an endless loop:

• Basic task → thread blocking on a counting semaphore. ActivateTask is tx_semaphore_put, the semaphore count is the number of pending activations, and the shim returns E_OS_LIMIT when it exceeds the configured maximum. TerminateTask and ChainTask become “return to the top of the loop” (plus an activation of the next task for ChainTask). Rating: Shim.
• Extended task → thread with an event flag group. SetEvent, WaitEvent, ClearEvent and GetEvent map almost one to one onto tx_event_flags_set and tx_event_flags_get, with 32 flags per group. Rating: Native.
• Priorities → careful: in OSEK, a higher number means a higher priority. In ThreadX, 0 is the highest. The shim generator inverts the numbers exactly once, in one place, and nobody ever touches priorities by hand again. This is not a hypothetical bug. It is the bug.
• Non-preemptive tasks and internal resources → ThreadX’s preemption-threshold. A thread with priority 10 and a preemption threshold of 5 can only be preempted by threads above priority 5 — exactly the “group of tasks that don’t preempt each other” that OSEK builds with internal resources. Rating: Native, and one of the nicest matches in this whole post.
• Schedule() (a non-preemptive task offering a rescheduling point) → temporarily lowering the preemption threshold. tx_thread_relinquish only yields to threads of the same priority, so it is not the same thing. Rating: Shim.

Resources and exclusive areas

OSEK resources use the immediate priority ceiling protocol: when a task takes a resource, it immediately runs at the highest priority of all tasks that use that resource. Nobody else who needs the resource can run, so nobody can block on it, and deadlocks are impossible by design. ThreadX mutexes use priority inheritance instead: the holder is boosted only once a higher-priority thread actually blocks. Both bound the blocking time, but they behave differently:

The good news: preemption-threshold gives you the ceiling protocol on ThreadX almost for free.

/* GetResource(RES_SPEED) -- ceiling = highest-priority user of RES_SPEED */
UINT old;
tx_thread_preemption_change(tx_thread_identify(), CEILING_RES_SPEED, &old);

/* ... critical section ... */

/* ReleaseResource(RES_SPEED) */
tx_thread_preemption_change(tx_thread_identify(), old, &old);

For nested resources, the shim keeps a small stack of old thresholds. For resources shared with interrupts (OSEK allows Category 2 ISRs to use resources), preemption-threshold isn’t enough, because it only affects threads — the shim has to mask the interrupt instead. Rating: Shim.

Exclusive areas (Rte_Enter/Rte_Exit for components, SchM_Enter/SchM_Exit for basic software) are the same story with one more twist: AUTOSAR lets you configure how each exclusive area is implemented — interrupt lock, OS resource, or no protection at all if the configuration proves it’s unnecessary. The shim needs the same switch per exclusive area: tx_interrupt_control(TX_INT_DISABLE) for short copies, preemption-threshold for longer sections, a mutex only where you really want inheritance. Rating: Shim.

Alarms, counters and schedule tables

• Alarms (SetRelAlarm, SetAbsAlarm, CancelAlarm, with the actions “activate task”, “set event” or “callback”) → tx_timer with an expiration function that performs the action. Rating: Native.
• Counters → the ThreadX tick (tx_time_get) covers the system counter. Additional counters driven by hardware (an angle counter, a second time base) are yours. Rating: Shim.
• Schedule tables (expiry points that activate tasks and set events at fixed offsets, optionally synchronized to a global time) → a table plus one timer that walks through the expiry points is easy. Synchronization to an external time base, with drift correction, is not. Rating: Shim without synchronization, Build with it.

Interrupts

• Category 1 vs. Category 2 ISRs → ThreadX doesn’t make that distinction; on the Cortex-M ports, an ISR can call the ThreadX services that are allowed from interrupt context (with TX_NO_WAIT). “This ISR never calls the OS” is a rule you enforce in reviews. Rating: Shim (a naming convention and a review rule).
• DisableAllInterrupts, SuspendAllInterrupts → tx_interrupt_control(TX_INT_DISABLE) and restore. Nesting counters for Suspend/Resume are a few lines in the shim. Rating: Native.
• SuspendOSInterrupts (block only interrupts that may call the OS, let the fast Category 1 ISRs through) → on Cortex-M that’s a BASEPRI-based lock instead of PRIMASK. Check whether your ThreadX port can be configured that way; if not, it’s a port change. Rating: Shim or Build.

Hooks and error handling

• StartupHook, ShutdownHook → tx_application_define and your own shutdown path. Rating: Native.
• ErrorHook → ThreadX returns error codes from every service (with error checking enabled). The shim wraps the calls and funnels errors into one handler. Rating: Shim.
• Stack monitoring → tx_thread_stack_error_notify, with stack checking enabled. Rating: Native.
• ProtectionHook → the MemManage fault handler, plus the module manager’s fault handling if you use ThreadX Modules. Rating: Shim.

Multicore and partitioning

Cross-core communication

AUTOSAR OS generates the IOC (Inter-OS-Application Communicator) for anything that crosses cores or partitions: IocWrite/IocRead for last-is-best, IocSend/IocReceive for queued data. Cross-core ActivateTask and SetEvent work too.

ThreadX on a multicore microcontroller like ours usually runs as one independent instance per core (AMP). There is no shared kernel, so no queue, flag or semaphore spans two cores. The bridge is shared memory and a protocol you define:

typedef struct { volatile uint32_t seq; Speed_T data; } mbox_speed_t;
extern mbox_speed_t mbox_speed;                 /* shared SRAM, mapped non-cacheable */

void mbox_speed_write(Speed_T v)                /* the single writer, Core 1 */
{
    mbox_speed.seq++;  __DMB();                 /* odd: writing */
    mbox_speed.data = v;
    __DMB();  mbox_speed.seq++;                 /* even: done */
}

bool mbox_speed_read(Speed_T *out)              /* reader, Core 0: bounded, never waits on the writer */
{
    for (int tries = 0; tries < 3; tries++) {
        uint32_t s1 = mbox_speed.seq;  __DMB();
        *out = mbox_speed.data;        __DMB();
        if ((s1 == mbox_speed.seq) && ((s1 & 1u) == 0u)) { return true; }
    }
    return false;                               /* stale: use the fallback */
}

Three things carry this, and the IOC would have handled every one of them:

• Caches. A Cortex-M7 has a data cache, and the caches of different cores are not coherent. Shared data lives in a region the MPU marks non-cacheable, or both sides do explicit cache maintenance. Forget this and the reader processes a value that’s been stale for minutes, with a perfectly consistent sequence counter.
• Bounded retries. An unbounded seqlock loop lets a misbehaving QM writer stall the ASIL reader — interference through time.
• One writer per mailbox. Two writers need two mailboxes.

For queued data, the same idea becomes a single-producer, single-consumer ring buffer, plus an inter-core interrupt so the receiving core can wake its thread with tx_semaphore_put instead of polling. Cross-core ActivateTask/SetEvent work the same way: an inter-core interrupt, and a handler on the target core that sets the flag. Rating: Build.

Spinlocks

GetSpinlock/ReleaseSpinlock protect data that several cores modify. On ThreadX, you build them from the chip’s hardware semaphore unit if it has one, or from exclusive load/store instructions — but only if the interconnect actually supports exclusive accesses to the shared SRAM across cores. Many don’t, and an LDREX/STREX spinlock on memory without a global exclusive monitor locks nothing at all. Check the reference manual before you trust it. And the rule from Part 4 of the foundation series still applies: no spinlock is ever shared between ASIL and QM. Rating: Build.

OS-Applications, memory protection and trusted functions

AUTOSAR groups tasks, ISRs and data into OS-Applications, marks them trusted or non-trusted, and generates the MPU configuration per partition. On ThreadX, the closest thing is ThreadX Modules: separately linked application modules that the module manager loads, starts and stops, each running unprivileged in its own MPU-protected memory. It’s a different model — modules are separate binaries — but the result is the same: QM code that can’t touch ASIL memory.

• Partitioning and the MPU → ThreadX Modules, or a hand-made scheme that reprograms the MPU on every context switch. Rating: Shim with Modules, Build without.
• CallTrustedFunction (a QM partition asks the ASIL partition for a service) → a request queue to a thread inside the ASIL partition, exactly like a client-server call. Rating: Shim.
• CallNonTrustedFunction (the call gate from the ASIL partition into QM code) → a request to a thread in the QM partition, with a timeout, and validation of the result. Rating: Shim.
• Terminating and restarting a partition (TerminateApplication) → the module manager can stop and restart a module. Rating: Native with Modules.

Timing protection

AUTOSAR OS can monitor an execution budget per task, a time frame between activations, and lock budgets for resources and interrupt locks. When a task exceeds them, the ProtectionHook decides what happens. ThreadX has nothing equivalent built in. Its execution profiling can measure how long threads run, and from there you build a monitor: per-activation runtime accounting in the dispatcher, a deadline check, and a watchdog supervisor that escalates. For ASIL software, that monitor is a safety mechanism — and has to be developed and argued like one. Rating: Build.

Service protection

AUTOSAR OS rejects calls from the wrong context (WaitEvent from an ISR, TerminateTask with a resource still held). ThreadX’s error checking catches the first kind (TX_CALLER_ERROR); the second kind is the shim’s job. Rating: Native plus Shim.

The summary table, part 1

The OS side holds up well: most of OSEK maps onto ThreadX natively or with a thin shim, and preemption-threshold turns out to be the secret weapon for internal resources and the priority ceiling. What’s left — cross-core communication, spinlocks, timing protection — is exactly the part that’s hard everywhere.

Next up

So far, the components have a place to run and a reason to wake up. What they don’t have yet is anybody to talk to. Part 2 builds the RTE communication on top of this execution model — sender-receiver, implicit access, client-server, modes — brings in the basic software, and ends with the honest bill: what you lose without the AUTOSAR toolchain, and how to win some of it back.

Sources and further reading

Standards and specifications

• AUTOSAR Classic Platform: Specification of Operating System, R23-11 — tasks, resources, alarms, schedule tables, spinlocks, OS-Applications, timing and service protection: the contract this post rebuilds.
• AUTOSAR Classic Platform: Specification of RTE, R23-11 — runnables, RTE events and exclusive areas.
• ISO 17356-3:2005 — Road vehicles — Open interface for embedded automotive applications — Part 3: OSEK/VDX Operating System — the OSEK base AUTOSAR OS is built on.
• Eclipse ThreadX source code and ThreadX documentation — the API (threads, event flags, mutexes with priority inheritance, timers) used for the mapping.

Books

• Edward L. Lamie: Real-Time Embedded Multithreading Using ThreadX, 2nd ed., Newnes, 2009 — the ThreadX book, written by the people who built it.
• Edward Row: Mastering Modern RTOS: Zephyr and ThreadX Internals, APIs, and Advanced Development — ThreadX next to Zephyr, good for seeing which design choices are ThreadX-specific.
• Olaf Kindel, Mario Friedrich: Softwareentwicklung mit AUTOSAR, dpunkt.verlag, 2009 (German) — a practical walkthrough of the AUTOSAR OS and RTE concepts.
• Giorgio C. Buttazzo: Hard Real-Time Computing Systems, 3rd ed., Springer, 2011 — priority ceiling and priority inheritance, the theory behind resources and mutexes.

The animations in this post are rendered with manim from scripts/manim/autosar_threadx_scenes.py.

So far, our BCU has a memory map the hardware can actually enforce and a protection concept that keeps QM away from ASIL B — cores, DMA, peripherals and all. What it doesn’t have yet is software in it. One simplex ASIL B core and five QM cores, all of them empty, all of them waiting for somebody to decide what goes where — and, just as important, when it runs.

That’s three decisions: which software component lives on which core, whether the CPU can actually carry it, and how each core’s work is cut into tasks. Let’s make all three, at least as a first draft you can defend in a review.

SWC allocation: deciding what actually lives where

With the regions protected, the next question is which software component (SWC, in AUTOSAR terms) actually runs on which core, in which memory partition. This is a genuinely separate decision from the memory map — the map tells you what’s possible, allocation tells you what you’re actually doing.

The criteria I use, roughly in this order:

1. ASIL classification first. An ASIL B SWC goes on the ASIL B core, full stop. This isn’t negotiable, and it’s the one criterion that overrides all the others below.
2. Communication locality second. SWCs that talk to each other constantly are cheaper to run on the same core (or at least the same trust domain) than SWCs that rarely interact — every cross-core call through the shared region has overhead, and every one of them is a chance to hit the MPU boundary we spent a whole part locking down. This applies within QM too: two QM SWCs that chat constantly are still cheaper on the same QM core than split across two different QM cores, even though there’s no MPU boundary between them — the inter-core overhead doesn’t care whether both sides are QM.
3. Timing criticality third. A SWC with a hard real-time deadline benefits from sharing a core with as few other time-sensitive SWCs as possible, to keep scheduling analysis tractable. Mixing five different periodic tasks with tight deadlines onto the same core “because there’s room” is how you end up debugging priority inversion at 2am.
4. Load balancing last, not first — but now it’s a real decision, not a formality. With a single ASIL B core, there was never a choice about where ASIL work goes. With five QM cores, there genuinely is a choice about how QM work splits across Core 1 through Core 5, and that choice is worth making deliberately. Resist flattening load evenly before the first three criteria are satisfied — a perfectly balanced allocation that violates ASIL separation, or splits a tightly coupled QM communication chain across two QM cores for no reason other than a nicer-looking spreadsheet, is not actually a good allocation.

Write the allocation down as an actual table (SWC, ASIL level, core, rationale) rather than keeping it as tribal knowledge. You will revisit it more times than you expect, and “why is this here” is a much better question to answer from a table than from git blame on a config file from fourteen months ago.

A first allocation for our BCU

Time to follow my own advice. Part 1 gave us the function list (immobilizer, lighting, climate & thermal, parking assist and the usual body stuff), four CAN FD channels, eight LIN channels, one Ethernet, diagnostics including OBD, and an update requirement. Let’s assume the HARA left us with exactly one function that needs ASIL B: the exterior lighting that other road users depend on — brake lights, hazard lights and low beam. Everything else is QM. (That’s an assumption, and like every assumption in this series it gets written down with a date. If the HARA comes back with a second ASIL function, this table is the first thing that changes.)

Two things worth pointing out. First, the ASIL B core is deliberately not “the core with the lighting on it”. It also hosts everything that supervises the rest: the safety manager, the watchdog manager and the self-tests from Part 3 (including the periodic readback of the MPU and firewall configuration). Second, the light request still arrives on Core 1, because that’s where the CAN FD stack lives. So the most safety-relevant signal in the whole ECU crosses the ASIL/QM boundary on its way in. We’ll come back to that below, because it decides a lot about the task setup.

CPU load and memory consumption: the reality check nobody scheduled

Remember from Part 1 that hardware sized this microcontroller without knowing the actual CPU load? This is where that comes back to haunt you — or doesn’t, if you plan for it properly.

Before we cut anything into tasks, one sober look at the budget. At this stage you don’t have real measurements, because there’s no running SW yet to measure. What you do have is the ability to make an honest first assumption instead of an optimistic one:

• Base your first CPU budget on comparable past projects, not on this project’s wishful thinking. If a similar BCU generation ran at 60% load with a similar function set, “this one will surely be more efficient” is not a plan, it’s a hope. Start from the closest real data point you have.
• Reserve real headroom, not token headroom. A common rule of thumb is to plan for 30-40% free CPU budget at this early stage, specifically because requirements will grow (they always do) and because interrupt load, communication overhead, and diagnostics tend to be underestimated across the board, not just by you.
• Size stacks from worst-case call depth, not typical call depth. This one is memory, not CPU, but the same discipline applies: a stack sized for the common case and blown by the one deep, rare, interrupt-nested call path is a bug that shows up in the field, not in your unit tests.
• Write the assumption down as an assumption, with a date. “We assumed X% load based on Y” is a sentence you want to be able to find again in six months, when the real measurements come in and either confirm you were reasonable or tell you exactly how wrong you were — and by how much.
• Plan the first real measurement point explicitly. Don’t let “we’ll measure it once bring-up is further along” be the whole plan. Decide now which milestone will produce your first real CPU load number, so the assumption above has a scheduled expiration date instead of quietly becoming permanent.

A first task setup

An allocation tells you where things run. A task setup tells you when, and in which order, and what happens when something takes longer than planned. Get this one wrong and you can build a perfect spatial separation (Part 3) and still have QM interfere with ASIL — just through time instead of memory.

The rules first

Before the tables, the rules the tables follow. These are the part I’d actually put into the architecture document:

• One partition per task, never mixed. A task runs either ASIL B code or QM code, never both. Part 3’s second experiment showed why: the MPU protects per task, not per function, so a QM runnable inside an ASIL task runs with ASIL permissions.
• A small, harmonic set of periods: 1, 5, 10, 20 and 100 ms. Every period divides the next one, which keeps the scheduling analysis simple and lets cross-core data exchange line up on common boundaries. Somebody will ask for 50 ms. Somebody always does. It doesn’t divide 20, so it gets 20 or 100.
• Rate-monotonic priorities. Shorter period, higher priority. The exceptions are event tasks for incoming communication, which sit just above the periodic task that consumes their data.
• ISRs stay short and belong to the partition of their driver. An ISR does the minimum and hands over to a task. QM drivers’ ISRs run on QM cores only. Anything that needs microsecond timing (ultrasonic echoes, PWM edges) belongs in timer-capture hardware plus a short ISR, never in a task, not even a 1 ms one.
• Hot code and stacks go into TCM. Each core’s tasks get their stacks and their most frequently executed code in that core’s own TCM (Part 2): single-cycle access, no crossbar contention, and much easier timing analysis. Shared SRAM is for data that has to be shared, not for convenience.
• Cross-core data moves at task boundaries, without locks. The producer writes at the end of its task, the consumer reads at the start of its own, through the mailbox pattern from Part 3: single writer, sequence counter, CRC. No spinlock is ever shared between an ASIL and a QM task, because a QM task that holds a lock is a QM task that can stall the ASIL core.
• Every task gets an execution budget, and somebody checks it. The OS’s timing protection (or a watchdog manager’s deadline supervision) checks that each ASIL task finishes within its budget and on time. The watchdog manager on Core 0 also watches a heartbeat from each QM core. A dead QM core means degraded function, not a safe state, and that difference is a written-down decision, as Part 3 demanded.
• Load per core stays at or below about 60% for now, interrupts included. That’s the 30–40% headroom from above, applied per core instead of averaged across the chip. Averaging is how you hide one overloaded core behind five relaxed ones. The budgets in the tables below are for task bodies, so the interrupt load (CAN FD receive interrupts on Core 1 can be a lot) has to fit into the gap between the table total and 60%.
• Utilization isn’t schedulability. 60% load says nothing about whether the 5 ms task still makes its deadline when everything above it fires at once. Once real execution times exist, a worst-case response-time analysis per core replaces the percentages. Until then, the percentages are a sanity check, not a proof.

Core 0 — ASIL B

Core 1 — Communication (QM)

Cores 2 to 5 — the other QM cores

Planned load, Core 2: 45%. Core 3: 35%. Core 4: 45%. Core 5: 45%. Every number in these tables is an assumption from comparable projects, not a measurement — exactly the kind the CPU budget section asked you to write down with a date, so it can be proven wrong on schedule.

One signal, end to end: the brake light

Tables are nice, but a task setup only proves itself on a real signal path. Take the brake light. The request arrives from another ECU over CAN FD, and the lamp has to be on within (let’s assume) 50 ms of it. On top of that, the BCU reads the brake pedal switch directly, through a hardwired input on the ASIL B core. That second source isn’t decoration: it’s diverse (different sensor, different path, no software from another ECU involved) and it never crosses the ASIL/QM boundary at all.

1. Core 1, Task_ComRx: the frame arrives, SecOC verifies it, and the signal is written into the shared workspace in SRAM Block 0, together with its E2E protection (sequence counter and CRC from the sending ECU). This is QM software writing data that ASIL will use — the amber cell from Part 3.
2. Core 0, Task_Asil_5ms: at the start of its next cycle, the ASIL task copies the signal, then checks the copy: E2E CRC, sequence counter, timeout. Only a valid copy goes into the light arbitration. An invalid or stale one is simply ignored, and the lamp follows the hardwired brake switch alone. Only if both sources are lost does the defined fallback kick in (for brake lights: assume braking, i.e. lamp on, which is the safe direction — and a DTC, so somebody actually finds out).
3. Core 0, Task_Asil_5ms: arbitration decides, and the output driver switches the lamp.
4. Core 0, Task_Asil_1ms: current monitoring confirms the lamp is actually on, or reports a defect.

Worst case from “frame received” to “lamp commanded”: the Rx task’s response time, plus up to one 5 ms period of waiting for Core 0’s next cycle, plus the 5 ms task’s own execution — call it about 10 ms on the ECU, well inside the 50 ms. More importantly, the latency is bounded by design: it depends on two task periods, not on how busy the QM cores happen to be. If Core 1 hangs completely, the ASIL side doesn’t wait for it. It sees the timeout, keeps following the brake switch, and the watchdog manager reports the missing heartbeat. The car behind you never notices that half of your BCU just died, which is exactly the point.

That’s what the rules above buy you. The safety-relevant path crosses the ASIL/QM boundary exactly once, at a fixed point in time, through a buffer slot only Core 1 writes, and the ASIL side validates everything it reads. And for the one function that really matters, there’s a second path that doesn’t cross the boundary at all.

What this setup deliberately leaves open

A first draft that pretends to be final is worse than one that admits its gaps. Open for now:

• Real execution times. Every budget above is an estimate until the first measurement milestone from the CPU budget section.
• Shared hardware. The flash controller, the DMA controllers and the crossbar are shared by all six cores. Their contention shows up as timing jitter, not as a fault, and it needs measuring, not guessing.
• Startup order. Which core comes up first, who waits for whom, and how the ASIL core behaves while Core 1 is still initializing its communication stack. That deserves its own post.
• The degradation concept. What exactly happens to each function when a QM core is lost. The table of “dead core X → what still works” is a safety and a product decision, not just an architecture one.

Closing out the foundation

Four parts ago, we started with nothing but a BCU, an ASIL B requirement, and a microcontroller whose CPU budget was decided by hardware without asking anyone. We turned that into a set of researched requirements, a memory map that traces back to every one of those requirements, an enforced protection scheme, a documented SWC allocation, an honest (if uncomfortable) first CPU budget, and a first task setup with one signal path traced end to end.

Is this foundation perfect? No — some of these assumptions will turn out wrong the moment real measurements show up. But it’s a foundation you can explain, defend, and deliberately revise, instead of one that quietly accumulated by accident while everyone was busy getting the first sample to blink an LED. That difference is the whole point of this series.

Sources and further reading

Standards and specifications

• AUTOSAR Classic Platform: Virtual Functional Bus, R23-11 — why SWCs can be allocated to cores late in the project, at least on paper.
• AUTOSAR Classic Platform: Specification of Operating System, R23-11 — tasks, alarms, schedule tables and multicore.
• AUTOSAR Classic Platform: Specification of RTE, R23-11 — runnables and how they are mapped onto tasks.
• ISO 26262-6:2018 — Product development at the software level — freedom from interference in the timing domain.

Papers

• C. L. Liu, James W. Layland: Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment, Journal of the ACM 20(1), 1973 — the origin of rate-monotonic scheduling and its utilization bound.
• M. Joseph, P. Pandya: Finding Response Times in a Real-Time System, The Computer Journal 29(5), 1986 — response-time analysis, the tool to check the task setup against its deadlines.

Books

• Giorgio C. Buttazzo: Hard Real-Time Computing Systems, 3rd ed., Springer, 2011 — the standard textbook for priority assignment, schedulability and resource sharing.
• Jane W. S. Liu: Real-Time Systems, Prentice Hall, 2000
• Hermann Kopetz: Real-Time Systems: Design Principles for Distributed Embedded Applications, 2nd ed., Springer, 2011 — time-triggered thinking, useful for the brake-light path end to end.
• Edward A. Lee, Sanjit A. Seshia: Introduction to Embedded Systems, 2nd ed., MIT Press, 2017 (free online) — scheduling and multitasking chapters.

In Part 2, we drew a memory map for our ASIL B BCU on our ARM Cortex-M7-based automotive MCU: flash split by criticality and update strategy, RAM split across one simplex ASIL B core and five independent QM cores, plus a standby region and a shared region for the things that genuinely need to cross the boundary. A memory map on its own is a diagram. What turns it into something you can actually put your safety case behind is three more decisions: how it’s enforced, whether the hardware can actually carry the load we’re about to put on it, and what runs where. This part covers the first one, and it’s big enough to deserve a part of its own. What runs where, and whether the hardware can carry it, follow in Part 4.

What’s inside

• Who may execute whose code, and who may read and write whose data, as access matrices per core
• A worked example, ASIL B flash vs. the shared SRAM block, down to the MPU registers
• Why you run out of MPU regions faster than you expect, and the AUTOSAR version of the same problem
• Two experiments on an RTOS MPU port
• The doors the MPU doesn’t guard: DMA, other bus masters and peripherals

In Part 1, we picked our microcontroller: an ARM Cortex-M7-based automotive MCU, six cores at around 300 MHz, configured for our ASIL B project as one simplex ASIL B core plus five independent QM cores — instead of burning a core on lockstep redundancy we don’t need. We also gathered security (a root of trust), updateability (independently updatable blocks), communication (a ComStack reachable from multiple components), diagnostics (somewhere persistent to live), low power and startup time (an always-on ECU that has to talk early), and the rules of our memory protection hardware (8 or 16 MPU regions per core, each one a power of two, aligned to its own size) as requirements. None of that is a memory map yet. This is where we turn it into one.

What’s inside

• How the flash gets split: immutable blocks first, then the updatable ones, with OTP, bootloaders, HSM partitions and reserved blocks that only exist so the MPU can do its job
• The full address-based flash map with sector sizes, generated from a YAML file that a script checks before it draws anything
• RAM for one simplex ASIL B core and five QM cores, plus the memory that has to survive a reset
• Where security, diagnostics, communication and startup time from Part 1 ended up in the map
• The requirements nobody writes down, and what’s still open for the next parts

Starting a new ECU project typically begins with compiling code for an A-Sample without much in the way of requirements — usually just the purpose of the ECU (BCU, Gateway, BMS, etc.) and, if you’re lucky, a derived ASIL (the automotive safety integrity level).

The first priority is getting a first commissioning of the individual parts — the microcontroller, the safety companion chip, sensors and actuators — via IO testing to confirm the PCB wiring is correct, setting up a test environment like a HIL, and taking first measurements on how the sensors and actuators behave in real life.

This means the top priority goes to hitting those goals, which often means neglecting the vital parts — memory layout, partitioning, and design patterns — that a project actually needs to succeed in the long run. That’s the first step into technical-debt hell: debt that, in reality, never gets paid back, because no customer is going to pay you to fix something they can’t see.

To use an analogy: imagine someone building a house without a detailed plan, knowing only that it will be a house — sometimes without even a stable foundation, just so they can install windows and doors first.

Every homeowner would go after the architect and construction company with a shovel if their house were built that way.

Especially in these modern days, where AI is spitting out more code than a human can read in a day!

So a solid foundation — even when the requirements aren’t 100% ready — might not be such a bad idea after all.

In most of the projects I’ve had the luck of contributing to, the SW stack was customizable, or built around something called a “platform”, so you were already able to start from a “solid” foundation. You take a project you (hopefully) already pushed somewhere safe, and start by forking or branching it for the upcoming project.

You start by removing everything that’s no longer needed and aligning the old project to the new hardware.

Modify the bring-up, change some IOs, remove the unwanted runnables, deactivate most of the safety features, and so on.

This approach speeds up getting a running SW on the new sample — as long as the foundation is robust and the architecture actually lets you do it (a topic for another post: clean architecture :)). The memory mapping usually gets adapted slightly, while the key principles behind the partitioning and memory protection concept get carried over as-is.

Wait a minute — didn’t I just say technical debt never gets paid back? Right. So yes, that debt is about to become part of your new architecture too. Yippee-ki-yay, brothertrucker, if you know what I mean.

Writing all this down, I’m starting to think SW projects work a lot like the real-world financial system :O.

So let’s forget that approach for the rest of this series, since not everyone has the luxury of just copying a disastrous project and trying to make it work :D. Let’s build one from scratch instead — properly, starting with the thinking, not the flashing.

Lay out the foundation

Let’s assume you’re lucky enough to be the SW architect for a BCU (Body Control Unit) on an A-Sample, with a safety requirement to support ASIL B.

Typical functions include things like immobilizer, lighting, climate & thermal, parking assist, and so on.

It’s an ARM Cortex-M7-based automotive MCU, in the same vein as the safety-oriented multi-core families several vendors now offer: six Cortex-M7 cores running at around 300 MHz, with a chip-level safety story that supports ISO 26262 up to ASIL D — if you pair two of the cores up in lockstep. That pairing isn’t fixed in silicon, it’s a configuration choice: you decide whether to sacrifice cores in pairs to buy hardware-checked redundancy, or run all six independently for more raw compute.

Our project only needs ASIL B. Lockstep buys you ASIL D-grade confidence at the cost of a whole core’s worth of throughput — and for ASIL B, that’s usually more insurance than you need. So the plan for this project is: one core runs simplex as our ASIL B core (software-diagnosed — periodic self-tests, ECC-protected memory, the usual toolbox — instead of a hardware-compared twin), and the other five run as independent QM cores. Same chip that could give us one ASIL-D-grade core and four spare, now gives us one ASIL-B-grade core and five QM cores instead. Over-qualified hardware for the software requirement, deliberately spent on throughput instead of on safety margin we don’t need — which, again, is a very normal, very common outcome of hardware being locked in before requirements are.

One warning before you celebrate the extra throughput: “simplex ASIL B with software diagnostics” is a much bigger decision than it sounds. ASIL B still demands real fault coverage for the CPU itself, and on a core without a lockstep twin, that coverage comes from a software test library that periodically exercises the core and costs CPU time on exactly the core you care most about. Worse, many MCU safety manuals simply assume lockstep for any ASIL use. So the first document to read isn’t the datasheet, it’s the chip’s safety manual and its assumptions of use: does the vendor support ASIL B on a simplex core at all, with which test library, and at what CPU cost? If the answer is “no”, your architecture just changed before it started.

Projected memory usage is sufficient, so no bottleneck there. Projected CPU load, however, is unknown — hardware, system or most likely the customer’s purchasing department made that decision on its own, without knowing the actual load (and let me assure you, that happens a lot more often than you’d think — we’ll come back to that particular gift later in this series).

Besides ASIL B as a safety goal, you have the usual standard requirements: security, communication (let’s assume for the sake of the example: four CAN FD, eight LIN and one Ethernet channel), OBD relevance, updateability, and some diagnostics. Nothing fancy, but still painful if you don’t consider it in the foundation.

Any further discussion about hardware changes is pointless — the schematic is frozen, the B-Sample is already in the making. That’s automotive for you.

So what’s the first thing you need to do, besides cancelling all vacation for the next three years, since “taskforce” is written all over this project?

You start by trying to get as much information as possible about further requirements, or details on the ones that already exist — but don’t waste time just waiting for answers.

You need to be bold: assume requirements where you have to, or just decide to design the project the way you think is right. I know that’s easier said than done, and experience helps, but if you don’t decide, deadlines will decide for you. I can assure you deadlines and technical debt are siblings in the project world.

So: gather as much information as you can within a defined time window, and then set the foundation. There’s usually no truly wrong decision, though of course some solutions work better than others. Either way, your team and your customer will thank you for it — and honestly, it’s also just your job!

Let’s take a closer look at what you actually need to research and decide before you can draw a single line of your memory map — because every one of these decisions ends up carved into it.

Security — secure as Fort Knox, but slow and resource-hungry

Security is important, and every ECU has security goals. Clarify which security mechanisms you actually need to implement. Secure boot and authenticated boot have completely different impacts on startup behavior. Secure boot requires a root of trust, which means a handshake between the boot manager (or first-stage bootloader) and the security module. Think carefully about what’s really needed — the impact on your foundation can be severe, affecting memory mapping and startup time, just to name a couple.

Communication — the first “hello world” that actually matters

Communication is crucial for an ECU — without it, it’s just a piece of electronics. Clarify the security and safety requirements on your communication channels. SecOC and E2E protection are standard by now, so you already need to think about where to allocate your ComStack. You should also consider whether it’s worth splitting up your Com main functions to reduce CPU load. Keep in mind that you’ll need to route received signals into various components, so your memory protection scheme needs to be capable of handling that. Most ECUs need communication up and running very early during startup, so plan for that in your init sequence.

Updateability — OTA as your life insurance

Let me start with the most important point: you need a solid plan for updating your SW throughout the development lifecycle. This is one of the biggest lessons I’ve taken away from the last few years. Of course, OTA isn’t the only way to update your SW, especially not in the early phase — but at some point, and usually earlier than you’d think, you’ll need to be updateable through the official update tools: OTA, an offboard tester, or similar. At the very beginning you might get away with a debugger, or maybe XCP or something proprietary — but plan this thoroughly, or you’ll be in real trouble. Cars are meant to drive, and once they’re driving, nobody wants to carry a debugger around just to update them.

Furthermore, updateability has a huge impact on your SW architecture. You need to consider integrity and authenticity mechanisms in the memory layout — a CRC check for integrity, or a proper signature for authenticity, which are two different things (a CRC won’t catch someone intentionally handing you the wrong image). You also have to consider which targets need to be updateable, like the application and the flash bootloader. If the application contains calibration data — which it usually does — you might need to split code from calibration. One hint I’ll already give you: think about how to divide your targets into updateable blocks. Depending on the microcontroller’s memory architecture, it can make sense to have more than two blocks that can be updated separately — just be aware that each block adds the overhead of being validated, and the risk of failing during the update.

And first and foremost, check whether you need to support an A/B swap mechanism, because that’s a completely different approach from simply invalidating the application and flashing the new one over the old one.

Diagnostics — your debugger once the hardware is out in the wild

By diagnostics I mean both the OBD standard — determined by the legislation of whichever countries the car is sold in — and sensor or general ECU diagnostics that determine the system’s specific state. OBD can be quite CPU- and memory-intensive depending on the used OBD fault classes, since it demands a lot of features to be implemented. So always find out whether you really need OBD, which OBD fault classes you need to implement, or whether you have room to negotiate the requirements down. Sensor diagnostics, and especially general diagnostics, can be a lifesaver once you have problems in the field. Always consider diagnostic services, or at least DTCs, that let you capture important information about the ECU’s internal state before the problem occurred — you’ll need them if the problem is a sporadic one. OBD lets you define your own trouble codes, stored in a format that helps you pinpoint the error source. Clarify how you want to recover from diagnostic abnormalities — this is often already defined by the customer, but it’s still worth considering early, while you’re designing your internal state machine.

Low power and startup time — the always-on ECU

A BCU is the ECU that never really sleeps. It has to wake up on a door handle, a key fob or a CAN message, it has to stay within a quiescent current budget measured in milliamps (sometimes less) while the car is parked for weeks, and it usually has to be talking on the bus within a few hundred milliseconds of waking up. Clarify early which wake sources you need, what has to survive a sleep (wake reason, reset reason, the last DTC), which core wakes up first, and whether partial networking is required. And put the startup time next to the security requirement: secure boot that verifies megabytes of application code before anything runs is great for security and terrible for “the bus expects an answer in 150 ms”. You want to discover that conflict on paper, not on the first wake-up measurement.

Memory protection hardware — the requirement hiding in the datasheet

This one is on nobody’s requirement list, which is exactly why it belongs on yours. Every other topic above eventually ends up as a region in your memory map, and every one of those regions will eventually need to be enforced — by the MPU (or MMU) of each core that can reach it. So before you draw a single line, find out what shape of region your protection hardware actually accepts:

• How many regions per core? A Cortex-M7 typically gives you 8 or 16 MPU regions per core. That’s not per memory type, that’s total — flash, TCM, SRAM, standby RAM and peripherals all come out of the same handful of slots.
• What does a region have to look like? On the classic ARMv7-M MPU — the one a Cortex-M7 has — a region’s size must be a power of two, and its base address must be aligned to that size. A 2 MB region can start at 0x01200000, but not at 0x01098000. A 1984 KB block is not one region at all; at an unlucky address it’s six. (The newer Armv8-M MPU uses base/limit registers with 32-byte granularity and is far more forgiving — know which one you’ve got before you plan around either.)
• What doesn’t the MPU see? A core’s MPU only checks that core’s own loads, stores and instruction fetches. DMA controllers, the HSM and other bus masters go around it, so those boundaries need a firewall at the crossbar or memory-controller level instead. Find out whether your chip has one, which masters it can tell apart (per DMA channel or only per DMA controller?), and its own granularity, alignment rules and number of rule slots, which are often coarser and fewer than the MPU’s.
• What are the flash sector sizes, and which flash blocks can work in parallel? A boundary that doesn’t sit on a sector boundary can’t be erased on its own, and that breaks the independently updatable blocks you just asked for under updateability. One level up, check read-while-write: most flash can only be erased or programmed while you execute from a different physical block. If you want to update in the background while the car keeps working, your memory map has to follow those block boundaries too.

These are cheap constraints to respect while the memory map is still a blank page, and very expensive ones to retrofit: once the first software is out in the field, moving a region boundary means breaking compatibility with every update that’s already out there. Put them on your list now, next to security and updateability, and treat them as requirements like everything else here.

These are only some of the considerations worth thinking about. A real ECU project is, of course, far more complex — I just wanted to share some thoughts based on what I’ve experienced so far.

Where this leaves us

By now you should have a rough, honestly-assumed-where-necessary picture of your security approach, your communication needs, your updateability strategy, your diagnostic requirements, your power and startup budget, and the rules your memory protection hardware plays by. That’s the input. None of it is memory layout yet — but every one of those six topics is about to become a constraint on it: security wants a protected root of trust region, updateability wants your flash split into independently updatable blocks, communication wants buffer space it can reach from multiple components, diagnostics wants somewhere persistent to write down what went wrong, low power wants memory that survives a sleep and a boot path short enough to wake up fast, and the MPU wants every region it will ever enforce to be a power of two, aligned to its own size.

In Part 2, we’ll take exactly this BCU example and actually draw the memory map — flash layout, RAM partitioning across the ASIL B core and the five QM cores, and the reasoning behind where each of today’s requirements ends up living.

Meanwhile, your colleagues are already fighting their first battles with bring-up SW — because getting the chance to debug on real hardware is a game changer, and nobody’s going to wait for your memory map to be perfect before they start.

Sources and further reading

Standards and specifications

• ISO 26262-1:2018 — Road vehicles — Functional safety — Part 1: Vocabulary — where ASIL, QM and “freedom from interference” are defined.
• ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineering — the frame for the security requirements and the TARA.
• UN Regulation No. 156 — Software update and software update management system — why updateability is no longer optional.
• ISO 14229-1:2020 — Unified diagnostic services (UDS) — the diagnostic protocol behind the “debugger in the wild”.
• AUTOSAR Classic Platform: Layered Software Architecture, R23-11 — a good map of which basic software module ends up owning which of the requirements above.
• Arm: Armv7-M Architecture Reference Manual (DDI 0403) and Armv8-M Architecture Reference Manual (DDI 0553) — the MPU rules that become memory-map requirements.
• Arm: Cortex-M7 Technical Reference Manual (DDI 0489)

Books

• Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, 4th ed., Addison-Wesley, 2021 — quality attributes and how to turn vague wishes into requirements you can design against.
• Jörg Schäuffele, Thomas Zurawka: Automotive Software Engineering, 2nd ed., Springer Vieweg, 2016 — the automotive development process from requirements to series production.
• Hans-Leo Ross: Functional Safety for Road Vehicles, Springer, 2016 — ISO 26262 explained by someone who has to apply it.
• Joseph Yiu: The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors, 3rd ed., Newnes, 2013 — the most readable introduction to the Cortex-M MPU, exceptions and low-power modes.
• Elecia White: Making Embedded Systems, 2nd ed., O’Reilly, 2024

Garbage collection or in short GC is a mechanism that takes care of “cleaning up” old, invalidated flash data so new data can be written. Before garbage collection can step into action, I need to explain why we need this clean-up at all.

A car stores values like operating-hour counters, mileage, or calibration offsets for sensors inside its data flash. Over the lifecycle of the car, these values change from time to time — due to firmware updates or the recalibration of sensor data. They are typically required to be non-volatile, meaning they need to survive the ECU going into a power-down.

RAM cells normally lose their content once power is removed, while flash is able to retain it even after the whole microcontroller is without supply. There are several types of non-volatile memory, but I’ll focus on NOR flash here, since it’s the type most commonly built directly into automotive microcontrollers — as opposed to NAND flash, which you’ll more commonly find in mass-storage devices like SD cards or SSDs.

To change a value in flash, you can’t just overwrite it: you always have to erase the content first and then write the actual value. Erasing happens at the granularity of a whole sector, not a single byte, and it’s this erase-before-write property that causes most of the fun described below.

Repeated erase/write cycles wear a flash cell out over time — every cell has a limited number of program/erase cycles it can survive (its endurance) before it becomes unreliable, which in turn affects how long it can still reliably hold data (its data retention). To keep this wear evenly distributed across the memory, software needs to make sure each cell is written roughly the same number of times. This is called wear leveling, and it’s typically done by not always overwriting the same cell but instead writing consecutively into the next available cells.

Since this strategy leaves behind a trail of stale, invalidated data every time it writes to a new cell, someone eventually needs to clean up that mess. That someone is garbage collection: it waits until the amount of garbage reaches a certain threshold, and then reclaims space by copying the still-valid content into a new, clean sector before erasing the old one.

Figure 1: A garbage collection pass doesn’t clean a sector in place — it copies the still-valid data into the clean standby sector, flips which sector is “active,” and only then erases the old one.

And just like cleaning up your own room, garbage collection takes time — and needs to be scheduled with some sense of priority. You also really don’t want to get interrupted in the middle of that cleaning process, since an interruption during an erase can leave you with neither a valid old copy nor a complete new one.

Now we know the why, and so far it sounds like a pretty favorable service. So where’s the problem?

Updating software is a crucial part of cars and their ECUs — the same goes for IoT devices, mobile phones, and so on. The problem can occur when you’re in the middle of a flashing sequence and you hit the garbage collection threshold at the same time.

Do you want to wait until garbage collection is finished? Is your system stable enough to deal with that? And aren’t you violating some timing requirement by waiting on garbage collection in the first place?

Now here is where good architecture needs to earn its paycheck.

A concrete example

Imagine an application that’s split into independently updatable blocks — say, one block that’s purely code (functions and constants), and another that holds only the calibration data for those functions. The overall system consists of a boot manager, a flash bootloader, and the application itself. A typical flashing sequence then looks like this:

1. The boot manager notices a pending flash request.
2. It jumps into the flash bootloader.
3. The flash bootloader flashes the application block by block.
4. After each block, it writes a progress marker into NVM — so that if a supply glitch causes a reset mid-sequence, the system knows exactly where it left off instead of guessing.

Figure 2: Every block write ends with a progress marker in NVM — and every one of those writes is a place where garbage collection can decide to join the party.

Every single actor in that chain — boot manager, bootloader, application — can write to NVM, and every one of those writes is a potential GC trigger. Which means the one operation you added specifically to make flashing safer (the progress marker) is also the one most likely to invite the process that can make flashing slower, right when you can least afford it.

What you can actually do about it

“Just suppress GC during flashing” is the answer everybody reaches for first, and it’s not wrong — but it’s not free either. If you defer every GC trigger for the full duration of a flash sequence, the garbage keeps piling up right up until the moment you release the brakes again. Do that often enough, or make your flash sequence long enough, and you can walk straight into the situation GC was invented to prevent: no clean sector left to write into.

A pattern that works better in practice is to give GC a budget instead of a blanket ban. Between block writes — at defined, predictable points in the flash sequence — check how full your garbage backlog is. If you’re comfortably below your threshold, defer and keep flashing. If you’re getting close to running out of clean sectors, spend a bounded amount of time letting GC catch up right there, before it becomes an emergency. That way GC still runs during flashing, just on your terms and inside a time slot you’ve already accounted for in your timing budget — instead of showing up uninvited in the middle of the block you least expected.

Whatever strategy you pick, don’t rely on the happy path holding up in the field. Always keep timeouts and fail-safe mechanisms in place, so that even if GC is allowed to run during flashing and the flashing itself fails, you can still fall back to a safe, previously validated backup image.

The decision, written down properly

Everything above is the reasoning. If you’d rather hand the actual decision to a coding agent instead of re-deriving it from paragraphs — or just want something you can skim in thirty seconds instead of read — I’ve written it up as a compact Architecture Decision Record: ADR-0001: Budget garbage collection during flash sequences. It also answers a question that comes up the moment you’re building this inside a platform instead of a single product: does GC budgeting even belong at the platform level, or is it product-specific plumbing? (Short version: platform — every derivative on the same NVM/FEE stack hits the identical problem, and nothing about the fix is product business logic.) The ADR stays short on purpose — a decision flowchart plus one fenced, structured block (interface, tunables, acceptance criteria) that an AI coding agent can work from directly, instead of paragraphs it would have to reverse-engineer first. Notice what it still doesn’t do: hand you a specific threshold percentage or budget-in-milliseconds as if I’d already decided it for you. Those stay calibration_required: true — they depend on your sector size, your GC cost, and your actual target.

Weak spots to check in your own architecture

If you’re starting a project, these are the questions worth answering before GC and flashing collide on you for real, and not on a whiteboard:

• Timing budget: can you afford a GC run happening during flashing at all, or does it blow your update time budget?
• Field vs. production: field devices need to survive a worst case gracefully, but don’t forget production — the line wants deterministic, repeatable flash timing just as much, if not more.
• Suppression: can you actually suppress garbage collection during flashing, and if so, for how long before the backlog becomes a problem?
• Fallback: do you have timeouts and fail-safe mechanisms so that a failed flash — with or without GC involved — still leaves you on a validated backup image, not a brick?
• Lifecycle: have you planned GC handling early enough to cover different target versions, especially the ones that may no longer be field-updatable after they’ve shipped?

There are many more things to consider, but I hope this gives you some awareness of the dangers — and the potential — of designing your system around the health of your data flash, so you can be bulletproof the day GC decides it wants to compete with your delivery date.

Sources and further reading

Specifications

• AUTOSAR Classic Platform: Specification of Flash EEPROM Emulation (Fee), R23-11 — the module that owns garbage collection in an AUTOSAR stack, and where the “when is GC allowed to run” question officially lives.
• AUTOSAR Classic Platform: Specification of NVRAM Manager (NvM), R23-11 — the layer above Fee: block management, write-all on shutdown, and why your shutdown time suddenly depends on flash.

Articles and papers

A few sources on flash garbage collection, wear leveling, and AUTOSAR’s NVM stack that go deeper into the mechanics touched on above:

• Explained: Garbage Collection — Swissbit
• Fundamentals of NVM in AutoSAR Part-1 — dev.to
• Flash EEPROM Emulation (FEE in AUTOSAR) — embeddedtutor.com
• AURIX MCU: Avoiding GC during FEE boot up in TC3xx MCAL — Infineon Developer Community
• AURIX MCU: Garbage collection in FEE MCAL driver — Infineon Developer Community
• What is Wear Leveling and Garbage Collection in SSDs? — FutureScope
• Garbage collection and wear leveling for flash memory: Past and future — IEEE Xplore
• Eran Gal, Sivan Toledo: Algorithms and Data Structures for Flash Memories, ACM Computing Surveys 37(2), 2005 — the classic survey on log-structured flash storage, wear leveling and reclamation.
• Michael Nygard: Documenting Architecture Decisions, 2011 — the blog post that started the ADR format used for ADR-0001 above. More templates at adr.github.io.

Books

• Rino Micheloni, Luca Crippa, Alessia Marelli: Inside NAND Flash Memories, Springer, 2010 — NAND rather than NOR, but the best explanation of why cells wear out, what retention really means and why erase is so expensive.
• Elecia White: Making Embedded Systems, 2nd ed., O’Reilly, 2024 — has a solid chapter on memory and on designing for updates in the field.
• Jörg Schäuffele, Thomas Zurawka: Automotive Software Engineering, 2nd ed., Springer Vieweg, 2016 — the big picture of where flashing, production and the vehicle lifecycle meet.