MCU-PLUS-SDK-AM243X: LPDDR4 initialisation dead loop

Hi Tom,

I'm consulting with internal experts on this.

Have you read through the documentation here? https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_02_00_31/exports/docs/api_guide_am243x/DRIVERS_DDR_PAGE.html

Regards,
Frank

Tom, have you used the sysconfig tool at dev.ti.com/sysconfig to generate a DDR register configuration for your specific board and DDR device?  It looks like during initialization, the controller is never requesting a frequency change, which could happen if you have a DDR register config for DDR4 as opposed to LPDDR4.

Regards,

James

Hi Frank and James,

thank's for the quick response.

Yes, I have read the documentation and followed the steps carefully.

Currently I work on a slightly modified "hello_world_am243x-evm_r5fss0-0_nortos" example to test the DDR. So the API should be called corretly. The modification are located after the initialisation of the system/board. I have used the sysconfig tool James, mentioned and wrote all the lpddr4 device specific parameter. Nevertheless, I cannot guarantee not to have made a single mistake in that file. I then have generated the header file and included it to the prject specific syscfg.

What function/ register call triggers Bit 7 of CTRLMMR_DDR4_FSP_CLKCHNG_REQ?

From Frank's link: "Ideally DDR should be enabled in the bootloader application and the SDK bootloader by default enables DDR by default."

Does the bootloader differentiate between ddr4 and lpddr4?

Regards,

Tom

Tom, can you send the resulting file from the DDR configuration tool, and the resulting .syscfg file?

The change request comes from the controller itself, so the while loop is waiting for the hardware to request the change.

THe bootloader does differentiate the two DDR types because the initialization procedure is different.  The configuration tool output has this information for the initialization driver.

Regards,

James

Thank you James, I will happily send you the files.

I have nothing changed in the bootloader, hence I am using the original one from the SDK.

Since I still have no Flash received from the market, I am working in RAM only. Bootloader and application is transmitted by UART0. After transmittion, the bootloader most likley does not know about the lpddr4.

How am I going to tell him/ do I need to rebuild the bootloader?

Regards,

Tom

Hi Tom,

The UART SBL calls DDR_init() from System_init().

This is a call graph:

            main()
                System_init()
                    DDR_init()
                        DDR_setClock()
                            DDR_changeFreqAck() // this is the hang location

Please see <SDK>\source\drivers\ddr\v0\ddr.c:DDR_setClock(), it appears the function differentiates between DDR and LPDDR4:

            static int32_t DDR_setClock(DDR_Params *prms)
            {
                int32_t status = SystemP_SUCCESS;
                
                if((HW_RD_REG32(DDR_CTL_REG_BASE) & DDR_TYPE_MASK) == DDR4_MEMORY)
                {
                    /* Type is DDR4*/
                    DDR_setFreq(prms->clk1Freq);       
                }
                else
                {
                    /* Type is LPDDR4. Start Frequency handshake.*/
                    DDR_setFreq(25000000);
                    
                    ClockP_usleep(5000);
                
                    /*trigger the start bit (from PI)*/
                    HW_WR_REG32(DDR_CTL_REG_BASE + DDR_PI_REG_BLOCK_OFFS + DDR_PI_0_SFR_OFFS,   TRIGGER_START_BIT);

                    ClockP_usleep(500);

                    /*trigger the start bit (from CTL)*/
                    HW_WR_REG32(DDR_CTL_REG_BASE + DDR_CTL_0_SFR_OFFS,   TRIGGER_START_BIT);

                    ClockP_usleep(1000);

                    DDR_changeFreqAck(prms);
                    
                    ClockP_usleep(500);

                    /*PI INT STATUS*/        
                    while(((HW_RD_REG32(DDR_CTL_REG_BASE + DDR_PI_REG_BLOCK_OFFS + DDR_PI_83_SFR_OFFS)) & 0x1) != 0x1);
                    /*CTL_342[25] = int status init[1] = 1 - The MC initialization has been completed.*/
                    while((HW_RD_REG32(DDR_CTL_REG_BASE + DDR_CTL_342_SFR_OFFS)&0x02000000)!= 0x02000000);
                }

                return status;
            }

If for some reason you need to rebuild the UART SBL, please see:

• https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_02_00_31/exports/docs/api_guide_am243x/MAKEFILE_BUILD_PAGE.html
• https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_02_00_31/exports/docs/api_guide_am243x/MAKEFILE_BUILD_PAGE.html#MAKEFILE_EXAMPLE_BUILD

The build help (gmake -s help) will display the command required to rebuild the UART SBL:

gmake -s -C examples/drivers/boot/sbl_uart/am243x-evm/r5fss0-0_nortos/ti-arm-clang all

Regards,
Frank

Tom,

Thanks much for the feedback.

I'm not clear why you're using SBL NULL. I gather you updated the SBL NULL Syscfg to use

<SDK>\source\drivers\ddr\v0\soc\am64x_am243x\board_lpddrReginit.h

instead of 

<SDK>\source\drivers\ddr\v0\soc\am64x_am243x\board_ddrReginit.h

and then rebuilt the SBL NULL.

Regards,
Frank

Hi Frank

Yes, I indeed have changed the ddr header file to one suitable to my lpddr4.

I do not have a FLASH assembled yet, because of market shortage. Therfore, I have to work in RAM. To do so, I load the SBL NULL and the application by ROM BL (UART0). The SBL NULL I am using to initialize the SOC. That, at least suggested me lots of references I have read at the sdk documentation to do so.

Sure, I could load my application via JTAG, but than I would have to handle the absourd unhandy loadprocess for CCS.

Regards,

Tom

Tom,

Ok, thanks for the feedback.

Regards,
Frank

Frank, I am sorry, of course I meant the SBL UART!

Regards,

Tom

Tom,

Thanks very much, this makes a lot more sense to me! I thought maybe you had combined the SBL NULL and app images into a single image and had modified SBL NULL to jump to an application entry point.

Regards,
Frank