Dear TI team,
unfortunately my original thread (should be linked as related question) was locked before the issue got solved.
It seems that the MCU_PLL0 comes up in idle mode after a warm reset, e.g. after a reset via reset pins, the debugger or via the Sciclient_pmDeviceReset() API.
Please see the original thread for what we discussed before. My questions pretty much remain the same:
WHY doesn't the ROM configure the clocks after a WarmReset the way it configured them after a POR? This looks like a bug in the AM65x ROM? I tried the same with SR2.0 hardware, and I was having the same issue.
Is there a workaround, e.g. something that I can configure BEFORE executing the WarmReset, that ensures that the ROM uses the correct clocking?
Is it "safe" to just re-enable MCU_PLL0 by clearing the IDLE bit? Our setup uses a very small first-stage bootloader that gets loaded by ROM, and then loads the actual SBL or a fallback copy. That small first-stage bootloader could make sure that the IDLE bit gets cleared, thus mitigating the effect of the slow clock. I tried this a few times, and it worked, but I believe the "expected" way to configure PLLs is using the Sciclient.
Regards,
Dominic
