|ARM Technical Support Knowledge Articles|
Applies to: Cortex-M3
The processor-only reset provides a useful capability to reset the processor functionally, without resetting the debug components in the Cortex-M3 subsystem. This allows debug and trace of the reset sequence itself.
It is possible that a processor-only reset can be requested at a moment when the processor has a write in progress to a destination outside of the processor's reset domain. This write can potentially be corrupted in a number of ways:
- the processor reset is defined to be asynchronously asserted, synchronously de-asserted; therefore the processor can potentially transition into its reset state at any point in the bus cycles forming the write
- even if the processor reset is externally synchronized or via the (synchronous) reset request available in the NVIC, there is possibly an untimed path in the logic, from the synchronizer flop, through the CLR -> Q path of the flop in the reset domain, to the D of the flop in the non-reset domain.
- even if no timing violation is present, a reset occurring between the address phase and data phase of the write may cause the slave to see a valid address cycle followed by a suppressed data value.
In most cases, any write outside of the processor's reset domain corrupted in this way is expected to be harmless. However, there may be cases where such a write causes an incorrect setting which will persist after the reset cycle of the processor and cause incorrect behaviour.
Any such cases resulting from writes to a destination in the SoC logic outside of Cortex-M3 should be analyzed by the licensee/designer. Where a risk is found to exist, workarounds may be required. At a hardware level, full reset including the destination register could be used for externally signaled resets. This logic could be conditioned by the presence or absence of a debugger, to allow processor-only reset only when the debugger is connected. Software-requested resets via the NVIC should be structured to avoid issuing such a request while a write is in progress.
One vulnerability identified inside of the Cortex-M3 subsystem is writes used to configure the Flash Patch and Breakpoint (FBP) unit (if present). While the FPB is normally used by the debugger for breakpointing or patching ROM code, there exists a possible functional usage of this feature as a method of in-the-field firmware patching.
A write to an individual comparator register (setting the enable bit for that comparator and setting the address to be compared) could be corrupted, resulting in the wrong address being remapped by the FPB. This could, for example, corrupt the initial stack pointer or the reset vector, causing immediate incorrect operation out of reset.
The problem does not arise if the FPB is not used in 'functional' mode. If the FPB is used in functional mode, a software workaround is to ensure that the FPB is globally disabled before programming any comparators. This is the default at reset. If code exists which will program the FPB other than at reset, the software workaround should include:
- disable the FPB
- program the individual comparators required
- explicitly disable the individual comparators not required
- re-enable the FPB
Following this sequence will prevent any corruptly programmed FPB comparators from being activated.
Note that using the FPB in this 'functional' mode may conflict with use of the FPB by debuggers.
Did you find this article helpful? Yes No
How can we improve this article?