MPC 8313 e300 Core is Not initializing in UBOOT

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

MPC 8313 e300 Core is Not initializing in UBOOT

1,367 Views
rama_krishna
Contributor II

Dear All,

              I am Newbie to the MPC world and facing a different issue while bring up the New custom board based on MPC8313E.Our custom board has the NAND flash for booting purpose. For flashing of uboot image to nand, we follow the procedure listed below. We take MPC8313RDB as a reference.

1.Build the Uboot with minimal configurations(only nand flashing) that should be loading to the target via JTAG.

2.Connect the JTAG ( USB TAP) to the target.

3.Initialize the DDR by using Cfg file.

4.load the uboot image to DDR (adddress 0x100000)by using JTAG.

5. Change the Program counter value to the specified location(in our case 0x100110:init API).    

6.Click on RUN in the configuration terminal.

If the Above procedure is successful, then the uboot prompt will come in the debug port, After that by using NAND flashing commands we can flash the UBOOT image to the NAND.

We have multiple custom boards (same configuration and same chip)based on MPC8313E,The above procedure is working for all boards except one.

The Problem is Core is not getting initialized and processor is going to undefined state(Not known for JTAG). I am trying to STOP the process by using JTAG, it shows the error as

"Failed to Stop the Process. Cannot Put the target into STOP Mode". The last instruction executed is at address 0x103178. I have check in the uboot.map file , the API is init_e300_core.

In the API some initialization sequence is happening (MSR register is updating).

1. Is the Processor is Not responding to some instructions ?

2. Processor is Connecting to the JTAG Well, but during init of core going to exception, is the Processor is misbehaving due to some internal corruption?

I would like to know the reason for misbehaving of processor?

Please help me to sort out the problem .Please give some insights for debugging of board.

Thanks & Regards

Rama Krishna

Message was edited by: rama krishna vishnumolakala

0 Kudos
8 Replies

1,017 Views
sinanakman
Senior Contributor III

Hi Rama

If you are seeing core initialization errors, it is possible that your SoC is

not reading  valid RCW values. From the reference manual :

"The reset configuration words are loaded from NOR Flash,

NAND Flash, or the I2C interfaces or from hard-coded values

during the power-on or hard reset flows."

So please take a deeper look at your design to find

out where the RCW values are loaded from. It is

possible that on that one board where you are seeing

the problem that particular RCW source interface is

not working.

I am not sure what JTAG debugger you are using but

most JTAG debuggers would also allow you to provide

RCW override values via JTAG. If you find out that

there is an issue reading the RCW values you might

be able to provide hard coded RCWs or overrides using

your JTAG probe.

Hope this helps

Sinan Akman

0 Kudos

1,017 Views
rama_krishna
Contributor II

Hello Akram,

                    Thanks for your response.

I am using code warrior USB TAP as a JTAG Debugger. The Source for HRCW is CPLD(acts as like NOR flash). I have check the HRCW registers by using JTAG and comapre with our values,both are same. I have check the Read & Write of DDR, there is no data mismatch. 

Is there any chance of chip may corrupt?

Please let me know to find out the corruptness of chip?

Regards

Rama Krishna

0 Kudos

1,017 Views
sinanakman
Senior Contributor III

Hi Rama

If you like to eliminate the possibility of reading corrupt

values from your CPLD then please use your CW TAP

to supply the RCW values instead of reading them from

CPLD. How it is done in your CW config files is probably

explained in CW manual.

Having said this, I see that Alexander is helping you

out with debugging the code that potentially causes

a checkstop so I suggest you continue debugging as

per his instructions but you can try out feeding RCW

values via JTAG to make sure this is not part of the

problem.

Hope this helps

Regards

Sinan Akman

0 Kudos

1,018 Views
rama_krishna
Contributor II

Hello Akman & Alexander,

                      I check the board with HRCW values from JTAG, but still no luck.The Problem is same and not get solved.

Alexander:

Can u please provide some insights to solve the problem?

Thanks & Regards

Rama Krishna

0 Kudos

1,018 Views
alexander_yakov
NXP Employee
NXP Employee

The debugger can take control over the core only if the core is not in checkstop state.

The core may enter to checkstop state as a result of attempt to execute invalid command or access to invalid memory location (memory location not assigned to any memory controller). When the core goes to checkstop state, the debugger can not take control over the core.

As per my understanding of your problem description, this is the most probable reason of the problem you observing.

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

1,018 Views
rama_krishna
Contributor II

Hello Alexander,

                           Thanks for quick response. I check the Memory Contents(read from DDR by using JTAG:Save Memory) with the original file(uboot.bin). The contents are same.

From the above observation can we say that there is no invalid instruction(because same code working on other board with MPC8313E)?

Can u please give some debug steps to find out the check stop state of processor(which memory location going to invalid state)?

Is HRCW read failure will make this kind of behaviour?

Regards

Rama Krishna

0 Kudos

1,018 Views
alexander_yakov
NXP Employee
NXP Employee

rama krishna vishnumolakala wrote:

The last instruction executed is at address 0x103178. I have check in the uboot.map file , the API is init_e300_core.

In the API some initialization sequence is happening (MSR register is updating).

As a next step of debugging, I suggest looking which particular instruction is causes the processor to go undefined state, and what this instruction is exactly doing. If you say this instruction updates MSR register than please check which MSR bits exactly.

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,018 Views
rama_krishna
Contributor II

Hello Alexander,

The instructions executed is

rlwimi R3,R5,0,25,25

sync

mtmsr R3

R5 Has the Contents of Original MSR

Value of MSR (R5)is 0x2000 -->Floating point execution enable

Value of R3 is 0x3002

After the rlwimi Instruction executed, core is not responding. 

Is there any chance of chip may corrupt?

Please help me to sort out this problem.

Regards

Rama Krishna

0 Kudos