RM57 Reset through CPURSTC leaves CPU in bad state

Hi Brian,

  Your understanding is correct that the CPURSTCR will only generate the reset to the CPU and nothing else. The SYSECR is a warm system reset that will pretty much reset the entire device except some few registers and analog components that are only reset by the cold POR. If you look at the HL_sys_startup.c file, the reset routine does try to find out what reset events caused the reset to happen. If you are using the HL_sys_startup.c generated from HalCoGen, the CPU reset event will only reinitialize the stacks and the cpu core registers while a system reset will go through further system initialization in which the PCR2 will be released from peripheral reset.  If the PCR2 and its connected peripherals are not released from peripheral reset, any access to them can cause abort. 

  Non-CPU registers should not be affected when you use CPURSTCR. So your problem description is a bit odd to me. Can you tell me how and where in your code you generate the CPU reset? 

We have our own posixy/linuxy RTOS implementation that we share among many processors, and have added the Hercules. When adding the reboot call (see section 2 in man pages for reboot) we support hard/soft resets, as well as the ability to attempt a WDT reset through this interface, so I was testing using both sys control methods and ran across this issue since it could make for a faster reset to just reset the CPU. During maintenance operations, we use this manual reboot functionality, as well as in certain failure conditions.  

While I understand that in a CPU reset, peripherals are not reconfigured, we have a habit of being pedantic, particularly on startup, ensuring the processor is in a good state. Since we don't know the state when the reset occurred, we try and reset all peripherals, this would include the PCR. The PCR is accessible before the CPU reset, but not after, so it is very confusing since the PCR should not be reset on a CPU reset (I think). Skipping some init (as the halcogen source does) is fine as a workaround for init, but leaving the PCR inaccessible is concerning as the PCR may need to be accessed outside of the initialization code in the future.  This is exactly the type of issue we try to avoid by skipping aspects of initialization.

Using ECR meets our needs, so I'm not really looking for a solution, more trying to identify that there may be an issue with the reset that should be called out in the errata. If that is just to say adding a note to not use the CPURSTCR for a soft reset as it may leave peripherals in an unknown state, recommend using ECR, it might save people some time (since CPURSTC is the first register in the set that mentions reset). 

Thanks

There is no other type of reset occurring at this point. We power up from POR or from external reset. The system boots to the shell. The watchdog is disabled at this point. The reset is manually asserted through a shell command to toggle the reset bit in CPURSTC, the CPU resets from the toggle and then data aborts when accessing the PCR on the subsequent boot. I've traced the code through the debugger, and everything works exactly as expected except that the PCR is not accessible. When asserting through ECR, it works fine, so again, we are covered.

I could put together an application in Halcogen that exploits this, but frankly it just isn't worth the time at this point. If you would like to look into it further for technical documentation, I leave that to you.

Thanks for your help.

Hi Brian,

 I can try to create such an example and confirm your observation tomorrow. If it is not too much trouble to you can you please tell me what the data fault status register and the data fault address register records in the CPU when you get a data abort. The two registers will provide a bit more clues to me.

 I'm just not totally convinced that the CPURSTC will reset the PCR. We might need to update the errata if it is indeed a bug.

This has been solved. The issue was that when resetting using CPURSTC, the MPU state is set to enabled on reset, which, for whatever reason, is limiting access to the PCR sets. Disabling the MPU on reset solved it.