This is Part 3 of a series on laying the foundation for a new ECU project. Part 1 covered requirements research and the thinking process; Part 2 covered memory mapping and partitioning; this part covers memory protection — MPU, bus masters and peripherals; Part 4 covers SWC allocation, a first CPU budget and a first task setup.

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

Read the full article

The rest of this article is free, but not anonymous: tell me who you are and you get access to all members-only articles on this blog. No newsletter, no spam, no selling your data.