Dear TI team,
unfortunately my original thread (e2e.ti.com/.../900527) AND my second thread (linked as original question) regarding this topic were locked before the issue got solved. This is issue has become critical for us, since devices will be produced within a few weeks that would need to employ our current workaround.
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
