Hello!
We have had problems with properly resetting the sharcs from the ARM core. Also, we see what appears lika a side effect that the ARM watchdog is inhibited from doing a system reset once it has elapsed, if we have started the sharcs.
What sticks out when troubleshooting, is the documentation of the RCU_SIDIS register in the HRM, bits 2:0 are documented as:
2:0 (R/W) SI[n] System Interface Disable Request [2:0].
Each RCU_SIDIS.SI[n] bit corresponds to a functional unit in the processor that supports the system interface disable request-acknowledge protocol.
0 RCU_SI_DISABLE_REQ[2:0] deasserted
1 RCU_SI_DISABLE_REQ[0] system interface disable request to M33 asserted
2 RCU_SI_DISABLE_REQ[1] system interface disable request to SHARC1 asserted
4 Reserved 7 RCU_SI_DISABLE_REQ[2:0] asserted
The value meaning of bits 0:2 are unclear. For instance "1: ...disable request to M33 asserted", does that refer to the ARM core? If so it is still strange, it is not an Cortex-M33 in the sc598, it's a Cortex-A55.
Also for value "2...disable request to SHARC1 asserted"
Does this mean sharc core #1 (or actually SHARC0), and where in such case is the value for disable request for asserting sharc core #2 ?
This almost leads me to believe that value 4: Reserved actually is sharc core #2 and NOT reserved.
Grateful if the bit value meanings here can be clarified, because the interpretation is crucial to how we go about with resetting the sharc cores.
Best Regards,
Lars
