LS1028: DDR configuration endianness issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LS1028: DDR configuration endianness issue

Jump to solution
1,487 Views
kumar_086
Contributor IV

Dear Experts,

We have a custom LS1028A board, having xspi flash connected with DDR4 memory. We have powered on the processor with CFG_RCW_SRC[0:3] with '0000' and loaded the LS1028RDB DDR configurations by changing the 4GB to 2GB and Bank Group bits from 2 to 1.

When we run the DDR validation test it is observed that the tool is reporting an endianness issue.

Attached the DDR configs read from RDB, please help if any more configurations to be modified.

Thanks

0 Kudos
1 Solution
1,413 Views
kumar_086
Contributor IV

Yes the HRESET is getting asserted.

The CodeWarrior DDR validation tool is running now and the following are the key take aways from it,
1. The flash programming steps as described in 'CodeWarriortool_CWARMv8TM' section 7 and changed the QDS init file with USE_SAFE_RCW as True, we were able to detect and program the xspi flash with the pbl (RCW+BL2), during this time the boot signals driven are '0000'
2. Changed the boot signals to load processor RCW from flash by choosing '1111', observed that UART fail prints were coming and PORRESET, HRESET signals were high
3. When we connect the code warrior with debugger along with updated DDR parameters as per datasheet and ran the DDR validation tool. The tool resulted in 'error: endianness' even though the DQS lines are correct
4. When we repeated step 1 with USE_SAFE_RCW as False, observed the error 'Target reset failed'
5. We got a suspect on the debugger TRST signal and there was a situation where the debugger was unable to reset the processor, then corrected the power sequencing logic to make the processor TRST reset sequence proper
6. Then the Target reset failed error is not observed and DDR validation ran successfully

Thanks, yipingwang & NXP forum support, and for making this happen!

PS: Marking this thread as closed

View solution in original post

0 Kudos
8 Replies
1,482 Views
yipingwang
NXP TechSupport
NXP TechSupport

1. Hard-coded RCW is not recommended to use when do DDR validation, please create RCW image for your custom board based on LS1028ARDB, then deploy the RCW image on your custom board.

2. For DDR validation initial parameters configuration, if there is DDR SPD on the target board, you could create a DDR project with reading from SPD method. If no SPD, you need to create a project with default configuration, then modify "Properties" panel according to your DDR datasheet, please refer to "1.1.1.2 Configure DDR controller" in the attached user manual.

3. Please open CCS console, type "log v", connect DDRv tool to the target board again, the low level CC log will be printed out, would you please send the CCS log to me to do more investigation?

0 Kudos
1,476 Views
kumar_086
Contributor IV

Dear @yipingwang.,

1. We have programmed the custom RCW (+bl2) based on the board requirements (as attached) and driving '1111' on CFG_RCW_SRC[0:3] pins.

2. We don't have any SPD on board and tried following the steps given in the document (tCL, tRCD, tRP, tRAS), the clk to DQS skew,  and DQ mapping lines all 32 pins connected from processor to DDR in the same pin sequence (pin 0 of DDR to pin 0 of processor, likewise for all 32 bits). Our DDR part: MT40A1G16KH-062E. 

As there are different other parameters that lead to the 'endianness' error of the Codewarrior tool?

3. Unable to find the CCS console

4. Also, ran the cwflash.py with QDS default DDR options and it gives an error,

DDR: timeout while waiting for D_INIT

DDR: initialization failed (ERR_DETECT = 0x80000088)

Could you please help with enabling the DDR configurations?

Thanks

0 Kudos
1,458 Views
yipingwang
NXP TechSupport
NXP TechSupport

If there is no SPD, please fill properties panel according to your DDR Datasheet, then save the configuration and click Project->Generate Processor Expert Code. 

Open "Validation" panel, select validation scenarios, then click "Start Validation", CodeWarrior Connection Server(CCS)  will be popped up at the right bottom of the Windows task bar, please open CCS console, type "log v" and click "Start Validation" again, the low level CCS console log will be printed in CCS console, please capture the CCS log to me to do more investigation.

0 Kudos
1,454 Views
kumar_086
Contributor IV

Thanks for the steps.

Ran the DDR validation tool after DDR configurations updated as required and ran the CCS server with 'log v' command. Attached the screenshot of the same the Codewarrior shows 'endianness' error and no prints observed at CCS server.

Regards

0 Kudos
1,450 Views
yipingwang
NXP TechSupport
NXP TechSupport

Do you have LS1028ARDB?

If yes, please connect the current QCVS DDR project to LS1028ARDB to check whether there is endianness issue report.

0 Kudos
1,446 Views
kumar_086
Contributor IV

Yes, we have LS1028ARDB.

The error 'endianness' is not observed in it.

Unfortunately when we run with boot mode '1111' - XSPI Flash, then HRESET signal is not getting asserted. Attached the RCW in above post - are we missing any in RCW?

0 Kudos
1,425 Views
yipingwang
NXP TechSupport
NXP TechSupport

When configuring your target board as hard-coded RCW, HRESET signal is getting asserted normally, right?

I assume that you are using LSDK 21.08.

Please modify components/firmware/rcw/ls1028ardb/R_SQPP_0x85bb/rcw_1500_gpu600.rcw according to your custom board.

1,414 Views
kumar_086
Contributor IV

Yes the HRESET is getting asserted.

The CodeWarrior DDR validation tool is running now and the following are the key take aways from it,
1. The flash programming steps as described in 'CodeWarriortool_CWARMv8TM' section 7 and changed the QDS init file with USE_SAFE_RCW as True, we were able to detect and program the xspi flash with the pbl (RCW+BL2), during this time the boot signals driven are '0000'
2. Changed the boot signals to load processor RCW from flash by choosing '1111', observed that UART fail prints were coming and PORRESET, HRESET signals were high
3. When we connect the code warrior with debugger along with updated DDR parameters as per datasheet and ran the DDR validation tool. The tool resulted in 'error: endianness' even though the DQS lines are correct
4. When we repeated step 1 with USE_SAFE_RCW as False, observed the error 'Target reset failed'
5. We got a suspect on the debugger TRST signal and there was a situation where the debugger was unable to reset the processor, then corrected the power sequencing logic to make the processor TRST reset sequence proper
6. Then the Target reset failed error is not observed and DDR validation ran successfully

Thanks, yipingwang & NXP forum support, and for making this happen!

PS: Marking this thread as closed

0 Kudos