|ARM Technical Support Knowledge Articles|
The ARMv7-M Architecture does not provide an architected solution for this problem, as this Architecture Profile is not specifically aimed at symmetric multi-processing applications. So any solution will be implementation-specific and should be documented in the chip vendor's user documentation for the SoC product.
It is not usual for more than one Cortex-M processor to share the same boot ROM at address 0x0, as this would tend to imply that more than one processor would boot up with the same initial Main Stack Pointer (MSP) address, which would lead to stack corruption in the event of any stacking operation (including NMI or any Fault exception) occurring during the period before individual processor instances adjusted their stack pointers to point to separate memory spaces.
If the chip designer has already resolved this problem by providing different Initial Main Stack Pointer read values at address 0x0, either by providing unique boot ROM for each processor or by adding logic to intercept the read from address 0x0 and provide unique read data to each processor instance, then this value can be used directly to distinguish between the processors.
If no such distinction exists, other solutions are possible.
These processors are configurable during the chip design stage. If the processor instances are not configured identically, for example if they have different numbers of interrupts, or different interrupt priority bit widths implemented, or can be uniquely identified by the choice of optional hardware blocks such as MPU, then each instance can be identified by software testing for the presence or absence of these features.
For identical instances, a small APB slave device could be added at a vacant address on the External PPB of each processor, which returns a parameterized unique instance ID value to its local processor. Privileged software could read from this address to identify the instance.
If a debug capability is implemented, then any difference in the debug and trace components listed in the respective CoreSight Debug ROM Tables could be used by privileged software as a discriminator to identify the unique instances. Alternatively, if the chip designer is providing their own company ID and Part Number in the ROM Table, they could assign different part numbers for each instance; or they could add a unique instance ID value into each ROM Table located at an address after the "End of Table" entry.
If the Auxiliary Fault Status Register (AFSR) functionality is not required in the application, then the external AUXFAULT input pins of each processor instance could be tied to a different value, allowing the AFSR to be read as a de facto processor instance ID. This has the potential downside of a debugger perhaps reading the AFSR and reporting status information which may appear confusing to end users.
If the shared memory system is based around an AHB Bus Matrix from AMBA Desgn Kit (ADK) or from Cortex-M System Design Kit (CMSDK), and if that memory system does not make use of the value of the HMASTERx (where 'x' is 'S' or 'D' for System or D-Code buses) to condition slave behavior, then an alternative solution can be designed. The HMASTER inputs to the Bus Matrix can be tied to a unique identification value for each processor instance, and a shared memory-mapped slave could be implemented whose function is to return, as read data, the value of the HMASTER from the requesting slave port on the matrix. This would provide a scalable solution for any practical number of processor instances sharing the AHB memory system, and would not be misinterpreted by tools. This relies on there being only one processor instance connected to each slave interface into the bus matrix, or on using some of those HMASTER input bits to further discriminate between the processors sharing the same slave port on the matrix.
Did you find this article helpful? Yes No
How can we improve this article?