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

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

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.