"ELF is not in expected HALT mode" error message again

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

"ELF is not in expected HALT mode" error message again

1,945 Views
alexeisa
Contributor I

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

0 Kudos
2 Replies

877 Views
yipingwang
NXP TechSupport
NXP TechSupport

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

0 Kudos

877 Views
alexeisa
Contributor I

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.

0 Kudos