Good day!
We have a problem with our custom board. Trying to connect with MPC8536 using CodeWarrior TAP and CodeWarrior Development Studio for Power Architecture (v. 10.5.1) causes the error message: "ELF is not in expected HALT mode". GUI dispays the window message:
"Error launching <...>
CCSProtocolPlugin : Failed to reset the target
[CCS last error: Draco/m HIP8: ELF is not in expected HALT mode ]"
I have found several similar questions in this forum - but those discussions and answers didn't give me the answer.
We have studied Reference manual and Hardware specification for MPC too, paying particular attention to TRST and HRESET signals. And we have watched them on the screen of the oscilloscope. However, we still puzzled with this problem.
We have designed MPC8572 board earlier, and used that experience in designing this board. MPC8572 board works correctly (TAP and Dev. Studio are the same), the connection is established perfectly - but the new one doesn't want to work :smileysad:
I have listed the log below.
Please help us!
Thank you very much.
--------------------
ccs_open
ipaddr = 127.0.0.1
port = 41475
timeout = 20
serverh = 0
ccs_open; ccs_error = 10
Error message: Connection refused
ccs_open
ipaddr = 127.0.0.1
port = 41475
timeout = 20
serverh = 0
ccs_open; ccs_error = 10
Error message: Connection refused
ccs_open
ipaddr = 127.0.0.1
port = 41475
timeout = 20
serverh = 0
ccs_open; ccs_error = 0
ccs_get_connection_count
serverh = 0
count = 1
ccs_get_connection_count; ccs_error = 0
ccs_available_connections
serverh = 0
count = 0
ccs_available_connections; ccs_error = 0
ccs_available_connections
serverh = 0
count = 0
ccs_available_connections; ccs_error = 0
ccs_config_cc
serverh = 0
config_string = cwtap:0
ccs_config_cc; ccs_error = 0
ccs_available_connections
serverh = 0
count = 1
ccs_available_connections; ccs_error = 0
ccs_cc_version
serverh = 0
cc = 0
version.major = 0
version.minor = 0
ccs_cc_version; ccs_error = 0
ccs_set_timeout
serverh = 0
timeout = 20
ccs_set_timeout; ccs_error = 0
ccs_available_connections
serverh = 0
count = 1
ccs_available_connections; ccs_error = 0
ccs_config_server
serverh = 0
cc = 0
server_config = 0
value = 4000
ccs_config_server; ccs_error = 0
ccs_config_chain
serverh = 0
cc = 0
device_list: (size = 1)
device[0]:: core_type=test core(20)
ccs_config_chain; ccs_error = 0
ccs_jtag_lock
serverh = 0
cc = 0
ccs_jtag_lock; ccs_error = 0
JTAG Diagnostics
Starting Power at Probe test ...
Test result: PASSED
Starting IR Scan test ...
Test result: PASSED
Starting Bypass Scan test ...
Test result: PASSED
Starting Arbitrary TAP State Move test ...
Test result: PASSED
Detected JTAG IDCODEs: OK
Device 0 IDCODE: 0x0003F01D
ccs_jtag_unlock
serverh = 0
cc = 0
ccs_jtag_unlock; ccs_error = 0
ccs_config_chain
serverh = 0
cc = 0
device_list: (size = 1)
device[0]:: core_type=Draco/m HIP8(53)
ccs_config_chain; ccs_error = 0
ccs_get_config_chain
serverh = 0
device_list: (size = 1)
ccs_get_config_chain; ccs_error = 0
ccs_get_config_chain
serverh = 0
device_list: (size = 1)
device[0]:: core_type=Draco/m HIP8(53)
ccs_get_config_chain; ccs_error = 0
ccs_send_message
coreh = [serverh:0;cc_index:0;chain_pos:0]
message = 3
ccs_send_message; ccs_error = 0
ccs_stop_core
coreh = [serverh:0;cc_index:0;chain_pos:0]
ccs_stop_core; ccs_error = -2147483635
Error message: ELF is not in expected HALT mode
ccs_read_register
coreh = [serverh:0;cc_index:0;chain_pos:0]
index = 287
count = 1
size = 4
value: (size = 4)
18053C00
ccs_read_register; ccs_error = -2147483634; duration=3 ms
Error message: ELF is not in expected HALT mode
ccs_reset_to_mixed
chain_pos: (size = 1) { 0 (halt) }
ccs_reset_to_mixed; ccs_error = 39; duration=1808 ms
Error message: Draco/m HIP8: ELF is not in expected HALT mode
ccs_get_subcore_error
serverh = 0
cc = 0
error = -2147483635
chain_pos = 0
ccs_get_subcore_error; ccs_error = 0; duration=2 ms
ccs_available_connections
serverh = 0
count = 1
ccs_available_connections; ccs_error = 0
ccs_delete_cc
serverh = 0
count = 0
ccs_delete_cc; ccs_error = 0
ccs_kill_server
serverh = 0
ccs_kill_server; ccs_error = 0
Please refer to page 6 and 7 to check JTAG interface design on your target board.
Please make sure HRESET to the processor exclusive to COP/JTAG header, problems arise when the core is reset and the debugger doesn't know about it, usually the debugger will report the processor cannot be put into STOP mode.
Have a great day,
TIC
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Thank you for your response!
We have already investigated this file, because we searched this forum for the answers to the similar questions and found some of them. Moreover, we have read the notes in this file and tried to see by oscilloscope the wave diagram as it is shown on the page 3 (HRESET* and TRST* Requirements). We saw a similar picture: assertion of HRESET*; then, after delay, assertion and negation of TRST*; finally, a very large “COP halt” interval before negation of HRESET*. It seems that it is sufficiently large for “USB TAP to send several COP commands to the processor before HRESET* is negated” (according to the notes in the file). But the processor doesn’t switch to the STOP mode… We also noticed some serial assertion/negation of TRST* even before assertion fo HRESET*. This odd behavior of USB TAP is not described in the documentation, but we saw the same thing on the previously designed and well-functioning processor board (with MPC8572), so we considered that it does not matter.
Now we think that the main cause of the trouble is the PLL which isn't locked despite of correct (as we suppose) SYSCLK and bootstrap configuration. This is because we have seen similar behavior of the CPU (see the log above) in case we totally disconnect SYSCLK and in case we don’t turn on the PLL by the assertion of the signal POWER_OK.
But we can not understand, why PLL is not working!
Please help us to find the fault or error.
With respects,
Alex.