AM2434: Invalid LPSC state transition for EMIF_CFG_0 Module (DDR Turn On)

I should mention this is occurring on the AM243x EVM board, not a custom pcb.

Hi Brandon,

i would agree that is strange, not sure what is going on .  Ensure the you have the DDR PLL (PLL12) enabled and locked before you try to enabled the LPSCs for the DDR.  

I assume you have translated the GEL scripts into some C code to run on the processor.  So are you booting with this custom SBL? Or somehow downloading binaries to the processor?  Just trying to understand the full environment from powering on the board to the failure.

Maybe one test:  are you able to run the GELs after your code fails to configure EMIF_CFG_0?  Maybe there is something different in its execution which may give you a clue.

Regards,

James

I can confirm PLLCTRL0 and PLL12 is enabled and locked when I try to enable the DDR LPSC modules.

Yes, I was using the GEL scripts, the SDK drivers, and two other company products utilizing the J7 and AM64x series chips as my references. Their LPCS drivers seemed extremely similar, if not identical. I saw the exact same 0x1A0D behavior when I tried to enable the LPSC_ADC domain without first enabling all the necessary clocks, however the PLL12 and MAIN_SYSCLK0 (via PLLCTRL0_PLLSTAT) dependencies are both locked. I'm pretty puzzled since the behavior implies I'm missing a PLL clock somewhere.

I'm unable to run the GEL files after my code fails due to my development environment being entirely within VSCode + Trace32. I got my software into a while(1), detached T32, and switched over to CCS, however attaching seems to reset my board and destroy the configurations I had loaded.

Is there an example project that directly configures DDR from DEV_BOOT mode? I was looking around for one to use with CCS, but I may have missed it.

As far as my boot process goes, I've got a T32 script that places the chip into reset, then releases the DMSC to execute for a few seconds to initialize the device, halts the chip and loads my SBL directly into SRAM and continues execution from SRAM. The first thing I do is configure my MPU, then load the SYSFW (v11.0.0.15) and the EVM board default config hex header files (which succeeds), and then I proceed to perform the Secure Handover (also succeeds) and finally continue on to PLL then PSC configuration, at which point I run into the described error.

Hi Brandon,

Are you connecting to the 20-pin cTI connector when you try to switch to CCS?  if so, the JTAG_EMU_RSTn signal might be causing this.  There are couple of things you can try to get around this:

-physically remove the connection.  Not an easy mod to do this on the board from what i can see.  What i have done in the past is physically bend the pin on the JTAG connector out of the way so it doesn't make connection with the pod

-you might be able to establish a connection with CCS before the error occurs, and after connecting to one of the cores, you can put it in Run->Free Run mode, then halt after the failure.  Not sure if any of that will conflict with your T32 connection.  

Another option:

On the Lauterbach website, there are cmm scripts that are essentially translated GEL scripts that will configure PSC/PLL and also the DDR

https://repo.lauterbach.com/cgi-bin/searchscript.pl?form=scripts&Terms=am243&searchresult=Searching+&fper=on&fmen=on&fhardware=on&fkernel=on&fcompiler=on&fflash=on&fmisc=on#hardware-arm~am24xx~am24x-skevm~scripts

With these, you shouldn't need to switch pods for CCS, and then you can run the PSC scripts to see if you can redo the PSC init to see if it works with the script.

You may also try just executing up to the secure handover point, and then from there try the cmm scripts to init the PLL and PSC, and see if you get different behavior.

Regards,

James