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
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
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
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
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
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!
-----------------------------------------------------------------------------------------------------------------------
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
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!
-----------------------------------------------------------------------------------------------------------------------
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