For M55 the single AIRCR.SYSRESETREQ write in NVIC_SystemReset may not be sufficient

[kjbracey]

On M55, and possibly other recent processors, a single write to AIRCR.SYSRESETREQ may not achieve a reset.

If the reset is co-ordinated via a PPU using WARM_RST P-channel signalling, as recommended in the TRM, and someone other than the M55 denies the transition, AIRCR.SYSRESETREQ is cleared without a reset.

Behaviour is documented in the M55 TRM, but the consequences are not spelled out:

The processor ensures that all the outputs of the PDCORE domain are set to their reset values. Therefore, when nSYSRESET is asserted these values do not change, which helps to prevent reset domain crossing issues.

In particular, the AIRCR.SYSRESETREQ is cleared on entry to WARM_RST, so that the SYSRESETREQ output signal is driven to 0 matching the reset condition.

When someone in the system denies the WARM_RST transition at the same time or after the M55 agrees to the WARM_RST, the PPU takes the M55 back out of WARM_RST state without the actual reset occurring, and with AIRCR.SYSRESETREQ cleared the WARM_RST transition will not be re-attempted until software sets AIRCR.SYSRESETREQ again. Such denials usually come from transient bus activity conditions, so continuous retry until the bus is idle and it's not denied is what we want.

I believe this is a flaw in the M55 - extremely unexpected behaviour, if not architecturally wrong. To achieve the stated aim of signal stability at reset it would be better to have the SYSRESETREQ signal be AIRCR.SYSRESETREQ &~ WARM_RST_state , and not have the register bit cleared, so the SYSRESETREQ signal goes back high and reset is re-attempted without software intervention. Raised that as an Arm support case (03486993).

But anyway, that's the way current production M55s are, so I think CMSIS needs to put the AIRCR write inside the loop.

[JonatanAntoni]

Hi @kjbracey,

Thanks for pointing this out. Would you be able to provide a suggestion in terms of a Pull-request? Any chance to create a test case running with Fast Models?

Cheers,
Jonatan

[kjbracey]

I don't believe any Fast Models system would emulate down to the level required to show this - incorporating the P-channel and a PPU. At their higher level, I'd bet a single AIRCR write is always sufficient.

I'll can prepare a PR, but won't be able to do it immediately.